今天和老板争的一个问题,想让大家评评

Question

说的是一个商城的管理系统,在商铺表里  出现 1.出租/未出租  2.经营类型 (如:内衣,袜子等) 等字段说明:目前系统里面就商铺表里面出现了这两个字段,以后可能别的地方会用到.我的意思是.另外在建个表.来保存 他们的类型,用一个字段来和商铺表联系起来.老板的意思事是把类型就写在这个表里面.处于人家是老板我不敢顶(毕竟是人家给开工资),但是我有组织不好语言说服他 ,但是我有不想按他说的做...请大家帮忙 大家 都来说两句.

Answer 1

to lonehare为什么类型少就没必要  ,说明 现在类型不确定..

Answer 2

我倒是觉得跟 类型的数量的多少 没关系..
纯属理念问题,
实际点的说,
如果前台有个类型选择的下拉列表,
该如何选出数据库中的类型进行填充?
不要说 distinct , 
1000000万条也 distinct ?

Answer 3

xml配置也可以,要求开发时间紧不紧?

Answer 4

to kmiaoer(睡苗儿) 执行效率问题，因为联表查询是很伤效率的像你说的   出租/未出租 这种状态就没必要加表，第一它数量少，第二它的基本不会再变动（一旦确定后），这种数据如果再开表的话简直就是对资源的浪费。
而 经营类型 确实有点不同，因为我不知道业务上的逻辑所以不太好说。不过有一点可以确定，如果它也是一经确定后就不再变动的数据，也不推荐再建表。

Answer 5

不要以为老板说的没道理，完全按照范式来做并不是正确的做法。大体上同意无名的意见。
经营类型这种东西，实在看不出分表放有什么好处，用时间换空间好像没什么意义，因为硬盘很便宜，如果你想要查询所有的类别，那么GROUP BY就行了，当然效率差很多，但这个需求使用频率比起查询某个店铺的经营类别来就可以忽略了。
在这种问题里面，分表并不是很好的做法，一个典型的例子就是，在用户管理系统应该用户名来做为用户的标识而不是用户ID。
使用ID会出现什么问题？你做了就知道了。

Answer 6

Ivony说用用户ID做标识不好，为什么啊？用户名作标识不就是省个字段吗？

Answer 7

要根据实际情况来做的，同意lonehare(无名)的说法。不知道楼主有没有注意过qq空间里面文章类别的变化？以前，应该是用一张表来保存用户定义的文章类别的，增加、修改了类别以后，那个类别可以是空的；现在变成了如果增加了类别，而这个类别下没有文章的话，那这个类别将不会被保存——很明显，文章类别现在变成了文章表内的一个文本字段。
qq空间的用户现在是越来越多啊，这样做应该是为了保证查询的速度吧！所以，要怎么做要看具体的需求，就算追求极限速度，也分好几方面的速度的！

Answer 8

想后续更新方便的LZ的方法好多了,Boss....无语~~

Answer 9

是啊..你有必要再建吗?跟个bool 或1/0的字段不就行了吗?
建议不要跟老板挣.越挣他越固执..你也越危险

Answer 10

我不认为分表有任何优势.反而分表会浪费空间,降低性能.对于状态, 经营类型这些 "type" 类型的字段.完全可以用数字来表示状态. 比如1表示袜子,2表示鞋子,等等.以后增加,就是在类中多一个if/case.我不认为楼主你的想法会从性能? 扩展性? 有什么优势.

Answer 11

考虑扩展性... 你可以新建一张表,ShopPropertyEx
考虑字段fieldID, fieldValue,
以后你新增加属性,在这张表中增加一条记录, 然后fieldID和其他表连接就可以了.但是,固定的东西, 不要再多此一举拿出来.除非有一些汇总表之类的考虑.
不然, 盲目拿出来,只会降低性能, 增加维护难度. join操作应该尽量避免.后续的开发人员, 很难明白你为什么会把sex "男/女" 之类的字段, 非得存到一张新表里.

Answer 12

这个我也遇到过，是关于程序架构的 ，想做完美软件的思想暂时放下吧，挺boss的就是了

Answer 13

我觉得多加一个分表，并在主表中把分表的id和name都当字段加上，这样查询时不用连表，只是在分表修改时效率低些，而且如已后有新的需求改起来也方便些。硬盘现在也大了，用空间换时间也还不错吧！

Answer 14

放到另外一个表里，有利于以后扩展，那个表专门存放业务字典。
但如果系统比较简单，时间比较紧，完全可以放到常量里，而商铺表里对应字段只存状态码。这样sql简单，效率也高。如果仅就这个“出租”“未出租”，用个常量就够了。