应用数据库模型

Question

到目前为止，我已经看到了几个项目，并且意识到有些项目不使用外键（表格因此没有链接），而有些项目确实链接了哪些表格。

我正在开发一个应用程序iOS使用SQLITE3，哪一个是最佳实践来开发应用程序？

Answer 1

最佳做法是拥有外键。就个人而言，在关系数据库中没有外键的想法对我来说很陌生。 （原谅双关语）外键有助于强制引用完整性。

Answer 2

在遥远的过去，应用程序构建在分层或网络数据库上，该数据库没有外键作为数据库的一部分。外键必须在应用程序中编码。

这些应用程序在经过多次踢和尖叫之后最终被迁移到关系数据库。我正在帮助维护2011年从IDMS迁移到DB2的应用程序。

代码没有改变，开发人员继续将外键作为应用程序的一部分进行维护。

Answer 3

由于您正在为iOS开发应用程序，在您的情况下，对象模型设计和数据库（表）设计将交付（然后数据管道代码变得很容易。否则您必须随时调整您的数据管道代码你在应用程序中进行了更改）。话虽如此，无论您在对象中有父子关系（一对一或多对映射），它们都应存储在您的外键表中。 “父”对象转到主表。 'Child'对象进入外键表。

如果您的要求非常简单，您还可以考虑将信息存储为XML。那么您不必担心数据库架构设计。一个有用的链接供您考虑

http://www.informit.com/articles/article.aspx?p=1019623

Answer 4

拥有FK有点像管理内存 - 无论你在应用程序的实现中多么认真，系统本身都不会让你做出“悬空指针”。

外键对于维护数据完整性至关重要。他们是：

• 陈述性：这使得它们“显而易见”，并且比隐藏在应用程序实现深度的命令性代码更具自我文档。
• 强大：仅仅一个错误的应用程序可能会破坏数据，因此拥有一个强制数据完整性的中央机制至关重要无法规避 >通过申请。
• 可扩展：在并发环境中，正确实现FK需要适当的并发控制（例如锁定），这通常可以在DBMS中比它更有效地完成可以在应用程序级别使用。

老实说，这在SQLite等嵌入式数据库中并不重要，因为它位于“大”客户端 - 服务器数据库中，其中多个客户端应用程序通常访问同一个数据库。但是，在嵌入式环境中使用FK也没有任何缺点，因此，只要您不受历史原因的限制，就应该这样做。

Answer 5

我想知道为什么rails框架似乎也没有在数据库上建立这些关系。他使用Active Record来完成这些关系。