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

可扩展数据库模型的设计

  •  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
  •  3
  •   Johannes Rudolph    15 年前

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

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

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

        4
  •  3
  •   Erwin Smout    15 年前

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

    上下文。

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

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

        5
  •  1
  •   nvogel    15 年前

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

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