代码之家 › 专栏 › 技术社区 › wishi

可扩展数据库模型的设计

database-design design-patterns model-view-controller

2

wishi · 技术社区 · 15 年前

我主要关心的是,我想应用设计模式(它是一个大学项目),我想通过选择合适的设计模式来改变那些不变的因素——在我的例子中MVC和一组子模式在模型层面。然而,当涉及到DB时,我可能不得不用MVC方法重新设计我的模型,因为我的域模型在稍后的阶段需要一组不同的类来表示DB表。我使用Hibernate作为DB和应用程序之间的抽象层。

你能从一个非常小的数据库开始,仅仅几个表和关系吗?如果我也想要一个高效的数据库呢?我想知道在现实世界中应用了什么策略。例如,当涉及到不断变化的需求时,干系人分析并不是一个充分的计划解决方案。我想-在DB级别-我的设计模式结束了。所以有一个漏洞,我想用一个聪明的策略把它的影响降到最低。

5 回复 | 直到 13 年前

1

2

Jonathas Costa 15 年前

一个简单的答案是:极简主义。

试着找出主要的实体。别担心房子的问题,你以后会补的。然后,创建实体之间的关系。使用您最喜欢的ORM(Hibernate?)创建一个测试应用程序,构建一些单元测试,瞧,您的数据库已经可以运行了

2

4

Anders Abel 15 年前

既然您已经选择了Hibernate来实现DB设计和OO模型的解耦,我认为坚持使用尽可能简单的DB是一个不错的选择。

3

Johannes Rudolph 15 年前

你所描述的几乎每一个项目都是典型的。不过,你可以做一些事情。

我提倡使用敏捷开发过程:现在只实现您需要的,但是在建模之前确保您理解了完整的问题。

在开始破解代码之前,另一件应该检查的事情是您选择的基础设施是否合适。当您想经常更改模式时,使用关系数据库通常是不匹配的。文档数据库没有模式,因此更灵活。我认为您应该评估使用关系数据库是否真的适合您的应用程序。

4

3

Erwin Smout 15 年前

“目前我正在做一个规格不明确的项目”

上下文。

请记住,数据库是一组 事实断言 (有意资本化)。

你将帮助你自己和你的用户首先尝试清除一切不清楚的东西。

5

1

nvogel 15 年前

没有一个项目一开始就有完全已知和固定的需求。对数据库设计使用敏捷的、迭代的方法,这样您就可以在开发过程中适应变化。

所有的数据库设计都是可扩展的,并且在其生命周期内会发生变化。不要试图逃避改变。只要确保你有合适的人员和流程来有效地管理变革。