数据库模型建模是设计复杂的大型企业应用程序的好方法吗？
我们正在开发一个奇怪的大型面向服务的多层应用程序，它必须从头开始设计。 现在我们需要开始编程，并尝试组装第一块积木。
问题是从哪里开始呢？ 有些人建议我们应该从设计持久数据模型开始，这将提供更清晰的视图。这是一个好方法吗？
Suirtimed 编辑
这里没有太多敏捷文化。 这是一个 SOA 风格的项目，使用 WCF、SQL Server、实体框架（使用 POCO 生成域对象）、ASP MVC 和 Workflow Foundation。 我们是一个由4名开发人员组成的团队；相当熟练（但不是专家）。
We're working on a freaky big service-oriented multilayered application, that has to be designed from scratch.
Now we need to start programming, and try to assemble the first bricks.
The question is where to start?
Some are suggesting that we should start by designing the persistent data models, which would provide a clearer view. Is this a good approach?
Edit for Suirtimed
There is not much an Agile culture here.
This is an SOA style project, using WCF, SQL Server, Entity Framework (using POCO generator for Domain Objects), ASP MVC and Workflow Foundation.
We are a team composed of 4 developpers; reasonably skilled (but not experts).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于数据库将是将企业应用程序连接在一起的关键元素，因此首先从数据库开始或至少与应用程序设计同时进行是一个好主意。不要依赖应用程序来确定数据库的结构。您需要针对数据完整性、性能和安全性进行设计，而不是面向对象！从至少符合第三范式的数据库设计开始。
数据模型的设计对于性能和数据完整性至关重要。而后期重新设计则是比较困难的事情。此外，对于企业产品，您将需要一些仅存在于数据库中的东西，例如应该从一开始就设计的记录审核。您可能想知道谁对记录进行了更改、更改内容以及更改来自哪个应用程序。这将极大地帮助回滚错误的数据更改并确定哪些应用程序导致了导致错误更改的问题。
Since the database will be the key element that joins the enterprise application together, yes it is a good idea to start with it first or at least do it simlutaneously with the application designs. Do not rely on the application for how the database should be structured. You need to design for data integrity,performancem and security not object orientation! Start with a database design that is at least inthe 3rd Normal form.
Design of the data model is critical to performance and data integrity. And it is the more difficult thing to redesign later. Further, for an Enterprise product you will want some things that are only in the database such as record auditing which should be designed from the start. Likely you will want to know who made changes to records, what the change was and what application it came from. This will help tremendously in rolling back bad data changes and identifying what application caused a problem that created bad changes.
如果您完全从头开始设计，那么是的，您具有定义数据外观的优势。
我只能说，根据我的经验，预先设计尽可能多的数据结构/业务逻辑是有帮助的。
您对应用程序的了解越深入，如果数据必须更改，重新调整所有内容就会越困难 - 并且无论您准备多少，数据都会更改，您只需要预先最小化这些更改即可。
我个人会说，是的，尽可能多地进行数据设计。不能本末倒置。
If you are designing completely from scratch, then yes, you have the advantage of defining how your data will look.
All I can say is, from my experience, it is helpful to get as much of the data structure / business logic designed up front as possible.
The deeper you get into your application the more difficult it will be to rejigger everything if the data has to change - and the data will change no matter how much you prepare, you just need to minimize these changes up front.
I personally would say, yes, get as much of the data design out of the way as possible. You can't put the cart before the horse.
我们通常从一些用例开始，初始化一些用于存储数据的实体。之后，我们尝试进行一些数据库建模并特别寻找实体之间的关系。
如果基本数据库模型存在，我们将开发一个原型并尝试在原型中包含尽可能多的用例。
We usually get started with some use cases to initialize some of the used entities for storing data. After that we are trying to do some database modeling and looking especially for the relationship between the entities.
If the base db model exists we will developing a prototype and trying to include as much use cases as possible in the prototype.
我始终尝试遵循的总体方法是从设计领域模型开始。这是您的“通用语言”，它将定义业务对象和概念，包含业务逻辑（稍后，当您拥有它时），并且通常是系统各个部分使用的公共语言。
这个想法是每个参与者都应该理解（或至少可以理解）。例如，其他部门的某些经理不一定会了解关系数据库或有关在其中保存其部门数据的任何信息。但他确实了解他所在部门的业务流程。他们的方言、他们的概念、他们的互动等等。无处不在的语言是这些群体共享的共同点。
在此过程中，您应该牢记您的依赖关系。最大的一个通常是数据持久性。有一种金色的梦想，领域模型一般来说是持久性无知的或依赖性无知的，并且为了分离关注点，这是一件好事。然而，真正的依赖无知会让你陷入困境。您可能会遇到一些严重的性能问题或架构问题，需要稍后进行大量重新设计。
因此，偶尔要脱离领域建模来考虑持久性（以及其他外部依赖项，例如需要使用的外部服务或需要集成的第三方应用程序）。当您对域进行建模时，请确保模型仍然可以正常工作并满足其所需的一切。为了适应依赖关系的限制，您可能必须在无处不在的语言上做出一些妥协。
基本上，在设计数据库之前设计领域模型。但在此过程中不要忘记数据库。
The broad overall approach I always try to follow is to begin by designing the domain models. This is your "ubiquitous language" which will define business objects and concepts, contain business logic (later on, when you have it), and generally be the common language used throughout the various parts of the system.
The idea is that it should be understood (or at least understandable) by everyone involved. For example, some manager in some other department isn't necessarily going to understand relational databases or anything about persisting his department's data therein. But he does understand the business process of his department. Their vernacular, their concepts, their interactions, etc. The ubiquitous language is the common ground the groups share.
During this process, you should keep your dependencies in the front of your mind. The biggest one is usually data persistence. There's sort of a golden dream that domain models be persistence-ignorant or dependency-ignorant in general, and for the purpose of separation of concerns that's a good thing. However, true dependency ignorance can paint you into a corner. You may run into some serious performance issues or architectural issues that require a lot of re-design later on.
So break from the domain modeling occasionally to think about persistence (and other external dependencies, such as external services that need to be used or third party applications that need to be integrated). As you model the domain, make sure that model still works properly with everything it needs to. You may have to compromise a little on the ubiquitous language here and there in order to accommodate the limitations of a dependency.
Basically, design the domain model before you design the database. But don't forget about the database during that process.