在应用程序或数据库中定义数据库模式？

Question

我知道标题可能听起来有些矛盾，但我要问的是关于ORM框架（在这种情况下是SQLAlchemy，但我认为这适用于其中任何一个），它们允许您定义模式在您的申请中。

是否更好地直接更改数据库模式，然后手动更新程序中的列类型，或者更有意义的是在应用程序中定义表，然后使用ORM框架的表生成函数来生成模式和然后为你在数据库端构建表？

Answer 1

请记住，除了最微不足道的情况之外，应用程序和数据库往往存在于M：M关系中。如果您的应用程序完全可能具有与其他系统，报告，数据提取或加载的接口，或者从另一个系统迁移到其上或从其移出的数据，则该数据库具有多个利益相关者。

对应用程序中的其他利益相关者不屑一顾。花点时间并获得正确的架构，并在应用程序的设计中考虑数据质量。密切关注使用该应用程序的任何其他人，并确保在不告诉他们的情况下不要破坏他们依赖的模式。这意味着数据库或多或少具有自己的生命。集成越多，数据库就越独立。

当然，如果没有其他人使用或关心数据，请随意忽略我的建议。

Answer 2

我个人认为你应该根据自己的优点设计数据库。数据库是处理建模域数据的最佳场所。数据库也是应用程序减速的最大来源，让你的ORM设计你的数据库对我来说似乎是一个坏主意。 ：）

当然，我只有几个大项目在我身后。我还在每天学习。 ：）

Answer 3

定义数据库模式的最佳方法是从建模应用程序域开始（域驱动设计任何人？），并根据您定义的域对象查看哪些表格形成。

我认为这是最好的方法，因为实际上数据库只是一个从应用程序中保留信息的地方，它永远不应该引领设计。它不是唯一一个持久保存信息的地方。我们有想要在平面文件或数据库中工作的用户。他们也可以使用XML文件。因此，从您的域对象开始，然后从那里生成表（或平面文件或XML模式或其他）将最终导致更好的设计。

虽然这可能取决于您使用面向对象的语言，但使用像Hibernate / NHibernate，SubSonic等ORM工具可以让您轻松实现这种转换，包括生成数据库创建脚本。

在性能方面，性能应该是您在应用程序中看到的最后一件事，它永远不应该驱动设计。根据您的域获得良好的架构并运行后，您可以随时进行调整以提高其性能。

Answer 4

很多都取决于您将要使用的特定数据库产品的技能水平。把它想象成“手动”和“自动”变速器汽车之间的区别。 ORM为您提供“自动”传输，只需开始设计您的类，并让ORM担心以某种方式将其存储到数据库中。

听起来不错。大多数ORM的问题在于，在他们追求PI“持久性无知”的过程中，他们通常不利用可以为给定任务提供优雅解决方案的特定数据库功能。请注意，我没有说所有ORM，只是大多数。

我的第一步是自己设计概念数据模型。然后，您可以向任一方向，向上朝向应用程序空间，或向下朝向物理数据库。但请记住，只有你知道使用视图而不是表更有利，如果你对表进行规范化或反规范化，那么非聚集索引对于这个表是有意义的，是一个自然或代理键更多适用于此表等...当然，如果您认为这些问题超出您的掌握范围，那么请让ORM帮助您。

还有一件事，你真的需要从数据库设计中分离应用程序设计。它们几乎从不相同。这些数据有多重要？是否可以设计另一个应用程序来使用该数据？重构应用程序要比重构数千个表中包含数十亿行数据的数据库容易得多。

Answer 5

好吧，如果你能逃脱它，在应用程序中执行它可能是最好的方法。因为它是DRY原则的完美范例。

然而，说到这一点，因为你实际上选择放弃大多数数据库特定的优化，所以侥幸逃脱它总是很难实现。 （更重要的是，使用查询，但它仍然适用于模式（索引等））。

你最终可能会手动更改架构，然后你会陷入一个脆弱的数据库架构，这将成为你最糟糕的噩梦的来源：）

My 2 Cents

Answer 6

尽可能根据自己的要求设计每个。试图让它们保持过于严格的同步，这是增加耦合/降低内聚力的一个很好的例证。

考虑到这一点，ORM可以很容易地用于传播耦合（即使它可以在某种程度上避免）。