应用数据库模型

我见过一对夫妇的项目，到目前为止，并意识到，这儿有项目，让没有使用外键（表因此不链接），而这儿有项目，其中表确实是联系在一起的。应用数据库模型

我正在开发使用SQLITE3iOS的应用程序，并哪一个是最好的做法，当涉及到开发一个应用程序？

来源

2013-02-25 andrefurquin

有FKS是有点像其托管内存 - 系统本身永远不会让你做一个“悬摆指针”，无论您在应用程序的执行犯错怎么重视。

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

声明：这使得他们“明显的”，更自我记录比埋在应用程序的执行深处的命令性代码。
乐百氏：仅仅一个车应用可能会破坏数据，所以它的关键是有强制执行数据的完整性是不能规避由应用程序的中央机制。
可扩展：在并发环境，实施正确地FKS需要适当的并发控制（例如锁定），其通常可以在DBMS更有效地完成比它在应用级是可能的。

诚然，这在嵌入式数据库（如SQLite）中并不重要，因为它在“大型”客户端服务器数据库中，其中多个客户端应用程序经常访问同一个数据库。但是，在嵌入式环境中使用FK没有任何缺点，因此，只要您不受历史原因限制，就应该这样做。

来源

2013-02-25 21:51:09

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

来源

2013-02-25 19:10:12 jfin3204

我在大学里总是这样学习，但这不是我在企业看到的...... – periback2 2013-02-25 19:29:04

是的，我知道。就像Gilbert Le Blanc所说的那样，其中一些来自遗留系统，另一些来自开发人员，因为他们很懒，或者在开发过程中他们太严格/繁琐，因此从来没有想过把它们放入 – jfin3204 2013-02-25 19:33:42

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

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

的代码是没有改变的应用程序，开发人员继续保持外键作为应用程序的一部分。

来源

2013-02-25 19:14:19

由于你正在开发一个iOS应用程序，在你的情况下，对象模型设计和数据库（表）设计将交到它手（然后数据管道代码变得很容易，否则你必须调整你的数据管道代码任何时候您在应用程序中进行更改）。据说，无论你在对象中有父母 - 子女关系的船只（一对一还是一对多映射），它们都应该存储在你的外键表中。 '父'对象转到主表。 'Child'对象进入外键表。

如果您的要求相当简单，您还可以考虑将信息存储为XML。那么你不需要担心数据库模式设计。一个有用的链接，你考虑

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

来源

2013-02-25 19:32:36

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

来源

2013-03-24 03:47:21 andrefurquin

应用数据库模型

回答

相关问题