81,092
社区成员
发帖
与我相关
我的任务
分享关于web的数据库设计，请给些建议谢谢。
要写一个小项目，名字叫做，每月一问。
基本流程是，提问（15日前）-回答（20日前）-审核（25日前）-如果通过，资料整理并进行发布，永久保存（本月底前）-如果未通过，将资料放入异常表以年为周期进行删除操作。
人员，包括提问、回答人员、普通管理员、超级管理员。
不需要注册，是一个web项目的部分模块，只是需要进行定义管理员和超级管理员。
我现在建立了几张表，始终有问题，感觉涵盖信息不全，代码写的时候，有的业务逻辑没办法处理。
求高手，在这种情况，我如何培养自己数据库建立的能力，我现在e-r实体模型建立、和对象建立方式都没办法。求高手啊。
基本流程是，提问（15日前）-回答（20日前）-审核（25日前）-如果通过，资料整理并进行发布，永久保存（本月底前）-如果未通过，将资料放入异常表以年为周期进行删除操作。
人员，包括提问、回答人员、普通管理员、超级管理员。
不需要注册，是一个web项目的部分模块，只是需要进行定义管理员和超级管理员。
我现在建立了几张表，始终有问题，感觉涵盖信息不全，代码写的时候，有的业务逻辑没办法处理。
求高手，在这种情况，我如何培养自己数据库建立的能力，我现在e-r实体模型建立、和对象建立方式都没办法。求高手啊。
...全文
请发表友善的回复…
发表回复
MiceRice 2012-05-07
- 打赏
- 举报
别着急结贴，我没做过不代表别人没做过，火龙果等重量级的都还没冒过泡呢。。。
也许运气好的话，会有人刚好做过，可以提些建议或者注意事项。
也许运气好的话，会有人刚好做过，可以提些建议或者注意事项。
lxpandsq 2012-05-07
- 打赏
- 举报
[Quote=引用 5 楼 的回复:]
其实我个人经验来看，设计工作的总时间中，大部分时间消耗在设计验证和设计调整这两者的迭代上。
你说“有的时候流程很复杂，我只好模块化，单独模拟”
这说明之前系统流程梳理就有问题，不过这也是国情决定，国情是大家普遍把系统需求规约当用户需求写。否则流程之类的问题，早就在系统需求分析过程中已经解耦掉了。
这个没招，只能自己磨。相信你以前都看过这种类似说法“面向对象设计，从需求领域就开始了，而不是……
[/Quote]
嗯，多谢，至少明白了，这个问题，不是因为有好的办法而我自己不知道。
其次，关于解决方法，似乎挺的晕乎乎的，但是好像还是很有收获的，我在慢慢想想。
至少不像原来那样懵懂了，谢谢。下午结贴！
其实我个人经验来看，设计工作的总时间中，大部分时间消耗在设计验证和设计调整这两者的迭代上。
你说“有的时候流程很复杂，我只好模块化，单独模拟”
这说明之前系统流程梳理就有问题，不过这也是国情决定，国情是大家普遍把系统需求规约当用户需求写。否则流程之类的问题，早就在系统需求分析过程中已经解耦掉了。
这个没招，只能自己磨。相信你以前都看过这种类似说法“面向对象设计，从需求领域就开始了，而不是……
[/Quote]
嗯，多谢，至少明白了，这个问题，不是因为有好的办法而我自己不知道。
其次，关于解决方法，似乎挺的晕乎乎的，但是好像还是很有收获的，我在慢慢想想。
至少不像原来那样懵懂了，谢谢。下午结贴！
MiceRice 2012-05-07
- 打赏
- 举报
其实我个人经验来看，设计工作的总时间中，大部分时间消耗在设计验证和设计调整这两者的迭代上。
你说“有的时候流程很复杂，我只好模块化，单独模拟”
这说明之前系统流程梳理就有问题，不过这也是国情决定，国情是大家普遍把系统需求规约当用户需求写。否则流程之类的问题，早就在系统需求分析过程中已经解耦掉了。
这个没招，只能自己磨。相信你以前都看过这种类似说法“面向对象设计，从需求领域就开始了，而不是设计领域才开始”，其实基本上都是这样的。
你说“在开发的时候，在修改数据库，有的时候会引起连锁反应”
这就是设计没做好的问题，相当于让开发阶段来完整设计验证，导致迭代这个过程延伸到了开发领域，越往后延，代价越大。
类似的案例是，开发人员自己不做单元测试，全扔给测试人员去做，然后造成软件稳定过程贼长。我见过大把开发人员，写完代码都不运行，就让测试人员去测试，按钮点下去系统直接报错；还理直气壮的说：我只负责开发。cowboy
你说“好像没有，关于数据库模型设计的验证类的资料”
叫做“设计验证”（Design Verification），数据库模型设计也只不过是设计中的一种。不过你不容易找到有价值的教程，都是原则性的介绍而已。
说到底，我也只能给你说说原则、大道理，呵呵。
如果你到了细节的某个模型的设计，也许还能稍微探讨下，全局性的模型，除非做过，否则没啥发言权。
你说“有的时候流程很复杂，我只好模块化，单独模拟”
这说明之前系统流程梳理就有问题，不过这也是国情决定，国情是大家普遍把系统需求规约当用户需求写。否则流程之类的问题，早就在系统需求分析过程中已经解耦掉了。
这个没招，只能自己磨。相信你以前都看过这种类似说法“面向对象设计，从需求领域就开始了，而不是设计领域才开始”，其实基本上都是这样的。
你说“在开发的时候，在修改数据库，有的时候会引起连锁反应”
这就是设计没做好的问题，相当于让开发阶段来完整设计验证，导致迭代这个过程延伸到了开发领域，越往后延，代价越大。
类似的案例是，开发人员自己不做单元测试，全扔给测试人员去做，然后造成软件稳定过程贼长。我见过大把开发人员，写完代码都不运行，就让测试人员去测试，按钮点下去系统直接报错；还理直气壮的说：我只负责开发。cowboy
你说“好像没有，关于数据库模型设计的验证类的资料”
叫做“设计验证”（Design Verification），数据库模型设计也只不过是设计中的一种。不过你不容易找到有价值的教程，都是原则性的介绍而已。
说到底，我也只能给你说说原则、大道理，呵呵。
如果你到了细节的某个模型的设计，也许还能稍微探讨下，全局性的模型，除非做过，否则没啥发言权。
lxpandsq 2012-05-07
- 打赏
- 举报
[Quote=引用 1 楼 的回复:]
但是想指出你某个环节可能缺失了，就是数据模型设计的验证环节。
[/Quote]
我到网上查了，好像没有，关于数据库模型设计的验证类的资料。
你能推荐下，会给个链接吗？
我想学下。
但是想指出你某个环节可能缺失了，就是数据模型设计的验证环节。
[/Quote]
我到网上查了，好像没有，关于数据库模型设计的验证类的资料。
你能推荐下，会给个链接吗？
我想学下。
lxpandsq 2012-05-07
- 打赏
- 举报
[Quote=引用 1 楼 的回复:]
不能直接告诉你结论，因为我没做过，不能随便瞎掰。
但是想指出你某个环节可能缺失了，就是数据模型设计的验证环节。
数据模型设计，你用ER模型没问题；或者有人更直接，用PowerDesigner出逻辑模型也没问题。而且相信都会做这个动作。
但是数据模型验证往往可能会被疏漏，而信息管理系统，数据模型往往是其命脉。
其实这件事情的难度不高，复杂度不高，唯一麻烦的是细心和耐心而已：把……
[/Quote]
你前面指的是设计的方法，这个应该不是问题，我现在头大的是设计逻辑。也就是你的这一句话：
“把系统需求，逐一在数据模型上走一遍，并评估可行性，就这么简单。如果验证过程发现模型存在问题，就与设计过程进行多次迭代，直到形成定稿。”
如何把系统需求，逐一在数据模型上走一遍，我现在是先建立几个表，然后根据各个系统需求，进行模拟流程（自己想，或用笔走走），但是因为有的时候流程很复杂，我只好模块化，单独模拟，这样，还是会有很多流程会漏掉，这样，只好，在开发的时候，在修改数据库，有的时候会引起连锁反应，然后又继续改，如果这样进行处理，那遇到，流程更复杂的情况，我该怎么办了？
不能直接告诉你结论，因为我没做过，不能随便瞎掰。
但是想指出你某个环节可能缺失了，就是数据模型设计的验证环节。
数据模型设计，你用ER模型没问题；或者有人更直接，用PowerDesigner出逻辑模型也没问题。而且相信都会做这个动作。
但是数据模型验证往往可能会被疏漏，而信息管理系统，数据模型往往是其命脉。
其实这件事情的难度不高，复杂度不高，唯一麻烦的是细心和耐心而已：把……
[/Quote]
你前面指的是设计的方法，这个应该不是问题，我现在头大的是设计逻辑。也就是你的这一句话：
“把系统需求，逐一在数据模型上走一遍，并评估可行性，就这么简单。如果验证过程发现模型存在问题，就与设计过程进行多次迭代，直到形成定稿。”
如何把系统需求，逐一在数据模型上走一遍，我现在是先建立几个表，然后根据各个系统需求，进行模拟流程（自己想，或用笔走走），但是因为有的时候流程很复杂，我只好模块化，单独模拟，这样，还是会有很多流程会漏掉，这样，只好，在开发的时候，在修改数据库，有的时候会引起连锁反应，然后又继续改，如果这样进行处理，那遇到，流程更复杂的情况，我该怎么办了？
MiceRice 2012-05-07
- 打赏
- 举报
不能直接告诉你结论，因为我没做过，不能随便瞎掰。
但是想指出你某个环节可能缺失了，就是数据模型设计的验证环节。
数据模型设计，你用ER模型没问题；或者有人更直接，用PowerDesigner出逻辑模型也没问题。而且相信都会做这个动作。
但是数据模型验证往往可能会被疏漏，而信息管理系统，数据模型往往是其命脉。
其实这件事情的难度不高，复杂度不高，唯一麻烦的是细心和耐心而已：把系统需求，逐一在数据模型上走一遍，并评估可行性，就这么简单。
如果验证过程发现模型存在问题，就与设计过程进行多次迭代，直到形成定稿。
然后才能进入开发。
至于“如何培养自己数据库建立的能力”，貌似只有一条：理论联系实践。而且我个人觉得，多做设计验证能更好的提升自己，有点像：日三省吾身 的感觉。
但是想指出你某个环节可能缺失了，就是数据模型设计的验证环节。
数据模型设计，你用ER模型没问题；或者有人更直接，用PowerDesigner出逻辑模型也没问题。而且相信都会做这个动作。
但是数据模型验证往往可能会被疏漏，而信息管理系统，数据模型往往是其命脉。
其实这件事情的难度不高，复杂度不高，唯一麻烦的是细心和耐心而已：把系统需求，逐一在数据模型上走一遍，并评估可行性，就这么简单。
如果验证过程发现模型存在问题，就与设计过程进行多次迭代，直到形成定稿。
然后才能进入开发。
至于“如何培养自己数据库建立的能力”，貌似只有一条：理论联系实践。而且我个人觉得，多做设计验证能更好的提升自己，有点像：日三省吾身 的感觉。
sdojqy1122 2012-05-07
- 打赏
- 举报
先设计 好基本表，这个一般不需要做大改动，根据需求分析来的。
实体表 表的关联不能太多，尽量用中间表转。这样不会照成你那样重改的麻烦。
实体表 表的关联不能太多，尽量用中间表转。这样不会照成你那样重改的麻烦。
MiceRice 2012-05-07
- 打赏
- 举报
[Quote=引用 8 楼 的回复:]
在回答之前，还有一个分配人员，是有普通管理员操作的。
这是我自己写的模型，总感觉不对。
等你有时间，你可以帮我看看。
[/Quote]
建议思路：实体、实体关系、台帐（过程信息） 分离管理。
建议调整：
1、重新分析业务实体，我个人认为这里面基本上就1个主实体1个辅实体；
主业务实体就是：问答；辅业务实体就是：内容（1个问题，1个回答）；
2、状态等信息合并入问答这个业务实体；
3、问题流转过程专表记录。
在回答之前，还有一个分配人员，是有普通管理员操作的。
这是我自己写的模型，总感觉不对。
等你有时间，你可以帮我看看。
[/Quote]
建议思路：实体、实体关系、台帐（过程信息） 分离管理。
建议调整：
1、重新分析业务实体，我个人认为这里面基本上就1个主实体1个辅实体；
主业务实体就是：问答；辅业务实体就是：内容（1个问题，1个回答）；
2、状态等信息合并入问答这个业务实体；
3、问题流转过程专表记录。
cxw3152 2012-05-07
- 打赏
- 举报
我这个不好说 一般都只能说说建表的大道理。 基本上都懂 要根据实地的需要做调整。 。还是建议重小项目慢慢锻炼。 。好好看看关于数据库基础知识
lxpandsq 2012-05-07
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
我想知道你是哪些地方的业务无法实现 还有 你的表是怎样建立的 会不会是少表了 或者是实体间的关系 或者 实体间的对应关系有误
[/Quote]
这里面有附图，你可以看下http://my.csdn.net/lxpandsq/album/detail/1140855
关键是数据库建立的表没有考虑完整，在编写的时候，发现代码写不下去，只好在改数据库。
我想知道你是哪些地方的业务无法实现 还有 你的表是怎样建立的 会不会是少表了 或者是实体间的关系 或者 实体间的对应关系有误
[/Quote]
这里面有附图，你可以看下http://my.csdn.net/lxpandsq/album/detail/1140855
关键是数据库建立的表没有考虑完整，在编写的时候，发现代码写不下去，只好在改数据库。
lyf520llp 2012-05-07
- 打赏
- 举报
我想知道你是哪些地方的业务无法实现 还有 你的表是怎样建立的 会不会是少表了 或者是实体间的关系 或者 实体间的对应关系有误
lxpandsq 2012-05-07
- 打赏
- 举报
[Quote=引用 7 楼 的回复:]
别着急结贴，我没做过不代表别人没做过，火龙果等重量级的都还没冒过泡呢。。。
也许运气好的话，会有人刚好做过，可以提些建议或者注意事项。
[/Quote]
在回答之前，还有一个分配人员，是有普通管理员操作的。
这是我自己写的模型，总感觉不对。
等你有时间，你可以帮我看看。
别着急结贴，我没做过不代表别人没做过，火龙果等重量级的都还没冒过泡呢。。。
也许运气好的话，会有人刚好做过，可以提些建议或者注意事项。
[/Quote]
在回答之前，还有一个分配人员，是有普通管理员操作的。
这是我自己写的模型，总感觉不对。
等你有时间，你可以帮我看看。
