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