松耦合数据库设计 - 如何？
我正在使用 silverlight 实现一个基于 Web 的应用程序，并在后端使用 SQL Server 数据库来存储应用程序将显示的所有数据。我想确保应用程序可以轻松扩展，并且我认为这样做的方向是使数据库松散耦合，而不是将所有内容与外键联系起来。我尝试寻找一些例子，但无济于事。
有没有人有任何信息或良好的起点/样本/示例来帮助我开始这个工作？
非常感谢帮助。
亲切的问候，
I'm implementing a web - based application using silverlight with an SQL Server DB on the back end for all the data that the application will display. I want to ensure that the application can be easily scalable and I feel the direction to go in with this is to make the database loosely coupled and not to tie everything up with foreign keys. I've tried searching for some examples but to no avail.
Does anyone have any information or good starting points/samples/examples to help me get off the ground with this?
Help greatly appreciated.
Kind regards,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为你有点混淆了你的术语。 “松散耦合”是指希望软件组件彼此之间的依赖程度不那么高，以至于如果不放在同一个程序中，它们就无法运行，甚至无法编译。我从未见过用于描述同一数据库中表之间关系的术语。
我认为如果您搜索术语“规范化”和“非规范化”，您会得到更好的结果。
I think you're mixing up your terminology a bit. "Loosely coupled" refers to the desirability of having software components that aren't so dependent upon each other that they can't function or even compile without being together in the same program. I've never seen the term used to describe the relationships between tables in the same database.
I think if you search on the terms "normalization" and "denormalization" you'll get better results.
除非您一次执行大量插入（例如数据仓库），否则使用外键。 标准化可以疯狂地扩展，你应该利用这一点。外键速度很快，并且当您一次插入数百万条记录时，约束实际上只会阻碍您。
确保您使用的整数键具有聚集索引。这应该会使连接表变得非常快。如果没有外键，您可能会遇到很多令人沮丧的问题。我整个周末都在这样做，我们有意识地选择不使用外键（尽管我们有 TB 的数据）。
Unless you're doing massive amounts of inserts at a time, like with a data warehouse, use foreign keys. Normalization scales like crazy, and you should take advantage of that. Foreign keys are fast, and the constraint really only holds you back if you're inserting millions upon millions of records at a time.
Make sure that you're using integer keys that have a clustered index on them. This should make joining table very rapid. The issues you can get yourself wrapped around without foreign keys are many and frustrating. I just spent all weekend doing so, and we made a conscious choice to not have foreign keys (we have terabytes of data, though).
在考虑这样的事情之前，您需要考虑数据完整性。存在外键，因此如果记录所基于的主要数据不存在，则无法将记录放入表中。如果您不使用外键，您迟早（可能更快）会得到毫无价值的数据，因为您并不真正知道订单所附加的客户是谁。外键是数据保护，您永远不应该考虑不使用它们。
即使您认为所有数据都来自您的应用程序，但在现实生活中，这根本不是事实。数据从多个应用程序、大量数据的导入、查询窗口进入（想想当有人决定更新所有价格时，他们不会从用户界面一次只更新一个价格）。数据可以从许多来源进入数据库，并且必须在数据库级别受到保护。如果做得少，您的整个应用程序和数据就会面临风险。
Before you even think of such a thing, you need to think about data integrity. Foreign keys exist so that you cannot put records into tables if the primary data they are based on is not there. If you do not use foreign keys, you will sooner or later (probably sooner) end up with worthless data because you don't really know who the customer is that the order is attached to for instance. Foreign keys are data protection, you should never consider not using them.
And even though you think all your data will come from your application, in real life, this is simply not true. Data gets in from multiple applications, from imports of large amounts of data, from the query window (think about when someone decides to update all the prices they aren't going to do that one price at a time from the user interface). Data can get into database from many sources and must be protected at the database level. To do less is to put your entire application and data at risk.
当数据通过数据库脚本等外部源输入时，有关数据库安全性的有趣评论。
Intersting comment about database security when data is input through external sources like database scripts.