说的是一个商城的管理系统,在商铺表里 出现 1.出租/未出租 2.经营类型 (如:内衣,袜子等) 等字段
说明:目前系统里面就商铺表里面出现了这两个字段,以后可能别的地方会用到.
我的意思是.另外在建个表.来保存 他们的类型,用一个字段来和商铺表联系起来.
老板的意思事是把类型就写在这个表里面.
处于人家是老板我不敢顶(毕竟是人家给开工资),但是我有组织不好语言说服他 ,但是我有不想按他说的做...请大家帮忙 大家 都来说两句.
------解决方案--------------------------------------------------------
老板还操心数据库设计啊!
试着说服他
不行 就按他说的做 人家给钱嘛
------解决方案--------------------------------------------------------
up 你给他钱。。。就可以按你的说法做了。。。 ：—）
------解决方案--------------------------------------------------------
如果类型的数量少，再建一张表确实没什么必要。
------解决方案--------------------------------------------------------
谁出钱多谁对！这才是王道
------解决方案--------------------------------------------------------
呵..
楼主我支持你,
咱俩风格很像呀,
不喜欢 "劣质 "开发..
跟头你可以让他自己摔,
你只要告诉他前面有石头就行了..
世道就是这样..
我算是深有体会了..
------解决方案--------------------------------------------------------
顶
------解决方案--------------------------------------------------------
我倒是觉得跟 类型的数量的多少 没关系..
纯属理念问题,
实际点的说,
如果前台有个类型选择的下拉列表,
该如何选出数据库中的类型进行填充?
不要说 distinct ,
1000000万条也 distinct ?
------解决方案--------------------------------------------------------
jf
------解决方案--------------------------------------------------------
我个人比较赞成你的做法。。。
不过是老板给钱你，你跟他讲明就可以了。讲不通的话。也只有按他说的做了。。
------解决方案--------------------------------------------------------
从设计角度上来说，我觉得lz的想法对
从￥的角度上来说，人家出钱……
------解决方案--------------------------------------------------------
是你的错,不要说你老板的错,
就算是你老板的错,那也是因为你不出来认错,你老板才出错!!!
记住: 老板永远都不会错
------解决方案--------------------------------------------------------
xml配置也可以,要求开发时间紧不紧?
------解决方案--------------------------------------------------------
to kmiaoer(睡苗儿)
执行效率问题，因为联表查询是很伤效率的
像你说的 出租/未出租 这种状态就没必要加表，第一它数量少，第二它的基本不会再变动（一旦确定后），这种数据如果再开表的话简直就是对资源的浪费。
而 经营类型 确实有点不同，因为我不知道业务上的逻辑所以不太好说。不过有一点可以确定，如果它也是一经确定后就不再变动的数据，也不推荐再建表。
------解决方案--------------------------------------------------------
你这样告诉他
你说如果 再建一张表来 存这些类别的话
这样有利于后期项目的开发
包括这个商城的扩展
因为再建一张表 就能把他的类型做成了 动态效果
时间长了 类型增加
这些 都会很方便
不然以后 如果 有一个新增的类型 他有什么新的特权等等
难道 你那时候 再去改代码加判断吗？
做成动态设置的 就能 设置一下 就能解决这些麻烦的事
------解决方案--------------------------------------------------------
有一点想说的是，并不是说建数据库表就一定要按照第三范式建主从表，还是那句话，要根据具体的数据特点来建立数据库结构，因为数据库肯定是性能的瓶颈，能让它省点就省点。
------解决方案--------------------------------------------------------
领导说你不对,你就不对,对也不对
领导说你对,你才对,不对也对
------解决方案--------------------------------------------------------
不要以为老板说的没道理，完全按照范式来做并不是正确的做法。
大体上同意无名的意见。
经营类型这种东西，实在看不出分表放有什么好处，用时间换空间好像没什么意义，因为硬盘很便宜，如果你想要查询所有的类别，那么GROUP BY就行了，当然效率差很多，但这个需求使用频率比起查询某个店铺的经营类别来就可以忽略了。
在这种问题里面，分表并不是很好的做法，一个典型的例子就是，在用户管理系统应该用户名来做为用户的标识而不是用户ID。
使用ID会出现什么问题？你做了就知道了。
------解决方案--------------------------------------------------------
ls说的是什么问题呢
效率上？
------解决方案--------------------------------------------------------
呵呵，不要和老板争！