在父表格和子表格之间引入一个新表格

问题描述:

如果我有一个填充了数据的父表格和子表格,在它们之间添加一个新表格是否微不足道?在父表格和子表格之间引入一个新表格

例如,之前介绍的关系是:

父 - >儿童

然后:

父 - >新建表 - >儿童

在这种情况下,我指到SQLite3,因此此架构中的子项具有与父表的主键相匹配的外键。

谢谢!

这可能是太明显,但是......

它是如何微不足道的是将取决于有多少代码已经被写入需要与此改变。如果这是一个新的应用程序,只需编写很少的代码,而您刚刚开始着手设计,那么是的,这是微不足道的。如果你有很多函数(不管是外部代码还是DB代码,比如存储过程和视图)访问期望原始关系的表,那么它就变得不那么简单了。

假设您知道足够的SQL来填充新表并设置关系,那么在数据库中更改它应该是相对不重要的。

与所有的开发挑战一样,您只需要看看会受到什么影响,如何以及如何考虑这些变化。

所有这一切都是一种非常冗长的说法,“这取决于你的情况”。

+0

感谢大卫,是的,这是一个新的应用程序,但我很期待并试图创造出最好的设计。我想,未来无法预测应用程序的所有需求或需求。我想远离CoreData,因为我希望用户能够在应用程序本身之外更新数据。 – Boojeboy 2010-10-23 15:38:19

+0

我不确定你一直在开发和设计应用程序有多久,听起来你是相对较新的......其余部分是基于这个假设的,所以我很抱歉如果我错误地认为...男孩你是不是正确预测需求和需求?但是,随着您获得更多经验,您将学习设计数据库的方法,以最大限度地减少变更的影响。由于数据库级的底层设计不良,大部分我必须重新编写的应用程序都会重新编写。所以你在正确的轨道上思考正确的方向。保持! – David 2010-10-23 16:02:43

我并不反对戴维,只是准确地反映了变化的几个方面。

如果您已经实施了合理的标准,那么受影响的唯一代码是代表Child(非New_Table)中更改的列的代码。如果你没有,那么不应该改变的未知数量的代码将不得不改变。

第二个考虑因素是儿童主键的质量。如果您拥有自然关系键,则添加New_Table的影响较小,而不需要更改数据。如果您有IDENTITY类型的键,那么您可能需要重新加载,或者更糟糕的是,“重新分配”键。

最后,介绍New_Table是校正规范化错误,这是一件好事。因此,某些Child.columns将变为New_Table.columns,并且可以从现有数据加载New_Table。您需要正确完整地执行此操作,以便从更正中获得性能收益。这可能意味着改变更多的代码段。

如果你有ANSI SQL,所有的任务都相当直接和简单。