假设您正在设计一个可能增长到亚马逊或谷歌规模的网络应用程序。一开始你只从项目的一个小方面开始，你知道，以敏捷开发的名义，你必须从某个地方开始。例如，您可能会选择创建一个简单的书籍目录，希望您的项目能够起飞，并且有一天您将不仅仅是一个目录，而是一个购买和销售书籍以及各种其他商品的一站式站点。 （这完全是假设。）
您会采用哪些不同类型的建模？一开始你会建模哪些不同的“实体”？您认为建模有多重要，您应该使用哪些信息来确定建模的时间和内容？
在对先前关于 SO 的问题的回答中，提到了“以数据为中心的世界观”与“以流程为中心的世界观”。在开始执行逻辑数据建模和物理数据建模之前，您是否对跨应用程序或网站的信息流进行建模？还是这些短语指的是不同的东西？
您可以使用哪些工具对不同类型的信息进行建模？
【问题讨论】：
标签： data-modeling modeling database-design
我的建模通常是在一张纸上或有时在白板上完成的。我从编写详尽的技术设计走了很长一段路，但我发现根本 提前考虑你希望在几年甚至几个月内拥有的功能是没有用的。您的需求将不断变化，因此您应该针对“现在”进行编程。
也就是说，当涉及到建模时。
当然，您应该考虑如果您的公司发展会发生什么，但不是在功能上，而是在性能上。如果你的访问者是 10 倍，产品是 10 倍，订单是 10 倍，你的应用还能运行吗……这些你需要担心的事情，而不是你打算在 2 年内构建的东西。您无法预见所有事情，所有编写“智能”和“可扩展”代码的尝试都将导致更复杂的系统在两年内定制比您没有考虑过的情况更加困难它根本没有。
只需构建您现在需要的东西，然后精简干净，以便将来扩展、重构或替换。
【讨论】：
模型的未来验证不同于实现的未来验证。
这是我用过的一些模型。
Data models:
Analysis model (conceptual): Entity-Relationship modeling
Design model (logical): Relational Data Model
Implementation model (physical): DBMS specific model
Application models:
Object Model: governs messaging among component objects.
Dynamic Model: governs states, events, and transitions within an object.
Functional Model: governs transformations and computations.
模型对于他们遗漏了什么以及他们留下什么都很重要。不要试图预测一切，但也不要把自己逼到角落里。从他人的经验中学习，然后从自己的经验中学习。
【讨论】：
根据我的经验，从适当的、高度规范化的 Db 设计开始是未来可扩展性的关键。您可以使您的实体越原子，当未知的“未来需求”出现时，您的系统就越容易扩展。为您知道将要添加的东西提前计划是有区别的，但由于时间限制，或者可能（只是可能）已知持续时间的硬件限制，暂时不能。但这与计划“如果我们成为 Google II 会怎样”不同。
在后端，一个强大的、高度规范化的表结构。在前端，干净、松散耦合的类和 n 层设计在可扩展性方面大有帮助。
【讨论】：