到目前为止，我已经看过几个项目，并意识到有些项目不使用外键（表因此未链接），而有些项目确实链接了表。
我正在开发一个使用 的应用程序iOS，SQLITE3哪一个是开发应用程序的最佳实践？
问问题
106 次
5 回答
1
最佳做法是有外键。就我个人而言，在关系数据库中没有外键的想法对我来说是陌生的。（请原谅双关语）外键有助于加强参照完整性。
于 2013-02-25T19:10:12.373 回答
0
在遥远的过去，应用程序建立在没有外键作为数据库一部分的分层或网络数据库上。外键必须在应用程序中编码。
这些应用程序最终被迁移到关系数据库，经过多次踢腿和尖叫。我正在帮助维护一个在 2011 年从 IDMS 迁移到 DB2 的应用程序。
代码没有改变，开发人员继续维护外键作为应用程序的一部分。
于 2013-02-25T19:14:19.693 回答
0
由于您正在为 iOS 开发应用程序，因此在您的情况下，对象模型设计和数据库（表）设计将顺其自然（然后数据管道代码变得非常容易。否则，您必须在进行更改时随时调整数据管道代码在您的应用程序中）。话虽如此，无论您的对象中有父子关系（一对一或一对多映射），它们都应该存储在您的外键表中。“父”对象转到主表。“子”对象进入外键表。
如果您的要求相当简单，您还可以考虑将信息存储为 XML。那么你就不需要担心数据库模式设计了。一个有用的链接供您考虑
于 2013-02-25T19:32:36.113 回答
0
拥有 FK 有点像拥有托管内存 - 系统本身永远不会让您创建“悬空指针”，无论您在应用程序的实现中犯了多么严重的错误。
外键对于维护数据完整性至关重要。他们是：
- 声明式：这使得它们比埋在应用程序实现深处的命令式代码“显而易见”并且更能自我记录。
- 稳健：只有一个有缺陷的应用程序可能会破坏数据，因此拥有一个中央机制来确保应用程序无法规避的数据完整性至关重要。
- 可扩展性：在并发环境中，正确实现 FK 需要适当的并发控制（例如锁定），这通常可以在 DBMS 中比在应用程序级别更有效地完成。
老实说，这在嵌入式数据库（如 SQLite）中并不像在“大型”客户端-服务器数据库中那样重要，在这种数据库中，多个客户端应用程序经常访问同一个数据库。但是，在嵌入式环境中使用 FK 也没有缺点，因此只要您不受历史原因的限制，就应该这样做。
于 2013-02-25T21:51:09.060 回答
0
我想知道为什么 Rails 框架似乎也没有在数据库上建立这些关系。他使用 Active Record 来处理这些关系。
于 2013-03-24T03:47:21.863 回答