实体应该映射到它自己的数据库表吗？
我正在使用 Azure 和 Idea Blade DevForce 做一些工作，我想知道将实体映射到数据库表的最佳方法是什么...
实体应该在数据库中拥有自己的表吗？这样做对性能有什么好处/坏处吗？
假设我们有一个“订单”实体、一个“产品”实体、一个“客户”实体和一个“地址”实体；将它们混合在一张表中与将它们全部分开有何优点/缺点？显然，如果我们不分离，数据库就不会处于第三范式，但是在使用 MEF / DevForce 时这有关系吗？
作为第二个（不那么做作的）示例，如果我们有一个“帐户”实体和一个“用户”实体怎么办？一个帐户可以有许多用户，但用户只能属于一个帐户......这样，将它们全部放在一个表中就不会重复任何用户数据，但我（个人）仍然认为这种方法是完全错误的。有什么理由说明它会带来好处吗？
I'm doing some work using Azure and Idea Blade DevForce and I'm wondering what the best approach is in terms of mapping entities to database tables...
Should an entity have its own table in the database? Is there any performance benefit / detriment to doing this?
Say we have an "Order" entity, a "Product" entity, a "Customer" entity and an "Address" entity; what are the pro/cons of mixing these in one table vs. separating them all out? Obviously the db wouldn't be in 3rd normal form if we didn't separate, but does that matter when using MEF / DevForce?
As a second (less-contrived) example, what if we had an "Account" entity and a "User" entity; an account can have many users, but the users can only belong to a single account... That way, putting them all in one table doesn't duplicate any user data, but I (personally) still think this approach is plain wrong. Are there any reasons why it would be a benefit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
取决于您有多喜欢复制数据，以及您是否希望有人认真对待您作为开发人员。将所有内容都扔进堆是我能想到的最糟糕的反模式。
举例来说，您想为 2 个客户创建 4 个订单，每个订单包含 5 个产品。每个客户仅您的客户数据就会重复 10 次。
编辑：我应该注意，我对这个问题的回答是强调“是”。我有兴趣听到替代方案的论点......
Depends on how much you like duplicating data, and whether you want anyone to take you seriously as a developer. Throwing everything into a heap is about the worst anti-pattern I can think of.
Say, for instance, you want to create 4 Orders for 2 Customers, with each Order containing 5 Products. Your Customer data alone is going to get repeated 10 times per Customer.
EDIT: I should note that my answer to the question is an emphatic "yes." I'd be interested in hearing arguments FOR the alternative...