关系表设计问题
如果行发生更改,如何保留历史关系数据?在此示例中,允许用户随时编辑属性表中的行。测试可以具有任意数量的属性。如果他们编辑“属性”表中的“名称”字段,或者在“属性”表中删除一行,则测试行可能不包含测试时的条件。您是否会通过添加属性名称列并删除 TestProperty 映射表来更改 Test 表的设计?属性名称列必须类似于分隔的字符串列表。问题通常如何处理?
3张桌子:
Test:
TestId AUTONUMBER,
Name CHAR,
TestDate DATE
Property:
PropertyId AUTONUMBER,
Name CHAR
TestProperty: (maps properties to tests)
TestId
PropertyId
How do you retain historical relational data if rows are changed? In this example, users are allowed to edit the rows in the Property table at any time. Tests can have any number of properties. If they edit the field 'Name' in the Property table, or drop a row in the Property table, Test rows might not hold conditions at the time of the test. Would you change the design of the Test table by adding a property names column, and dropping the TestProperty mapping table? The property names column would have to be something like a delimited list of strings. How is problem usually handled?
3 tables:
Test:
TestId AUTONUMBER,
Name CHAR,
TestDate DATE
Property:
PropertyId AUTONUMBER,
Name CHAR
TestProperty: (maps properties to tests)
TestId
PropertyId
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为这个问题还没有得到充分回答。
绝对不会。这会无缘无故地增加大量重复。
如果您的要求是在测试时保持数据值(在属性中)的完整性,则正确的(数据库)方法是实现历史表。这应该是源表的精确副本,加上一项:将 TIMESTAMP 或 DATETIME 列添加到 PK。
For this to be meaningful and useable, the Test table needs a timestamp as well, to identify which version of ProperyHistory to reference:
这会破坏基本设计规则以及数据库规范化规则,并阻止您对其执行普通的关系操作。切勿在单个列中存储多个数据值。
删除又是不同的事情。如果它是一个“数据库”,那么它就具有完整性。因此,如果父行在其他表中具有子行,则无法删除该父行(如果它没有子行,则可以将其删除)。这通常被实现为“软删除”,添加诸如
IsObsolete
之类的指标。这在各种 SELECT 中引用以排除该行被使用(以添加新子项),但仍可用作现有子项的父项。I do not think the question has been answered fully.
Definitely not. That would add massive duplication for no purpose.
If your requirement is to maintain the integrity of the data values (in Property) at the time of the Test, the correct (database) method is to implement a History table. That should be an exact copy of the source table, plus one item: a TIMESTAMP or DATETIME column is added to the PK.
For this to be meaningful and useable, the Test table needs a timestamp as well, to identify which version of ProperyHistory to reference:
That would break basic design rules as well as Database Normalisation rules, and prevent you from performing ordinary Relational operations on it. Never store more than one data value in a single column.
Deletion is something different again. If it is a "database" then it has Integrity. Therfore you cannot delete a parent row if it has child rows in some other table (and you can delete it if it does not have children). This is usually implemented as a "soft delete", an Indicator such as
IsObsolete
is added. This is referenced in the various SELECTS to exclude the row from being used (to add new children) but remains available as the parent for existing children.如果你想保留财产关系,即使该财产不存在。使属性不一定被删除,但添加一个标志来指示该属性当前是否处于活动状态。如果属性的名称发生更改,请使用新名称创建新属性并将旧属性设置为非活动状态。
如果您这样做,则必须创建某种垃圾收集方式非活动属性。
我永远不会将单个列放入一个字段中,该字段模仿与逗号表示的列表的一对多关系。 否则,你就达不到关系数据库的目的。
If you want to retain property relations, even if the property doesn't exist. Make it so that Properties aren't necessarily deleted, but add a flag that denotes if the property is currently active. If a property's name is changed, create a new property with the new name and set the old property to inactive.
If you do this, you'll have to create some way of garbage collecting the inactive properties.
I'd never make a single column into a field that imitates a one-to-multi relationship with a comma-denoted list. Otherwise, you defeat the purpose of relational database.
似乎您正在使用
Test
作为测试特定实例的模板以及测试本身。也许每次用户根据Test
中的规范执行测试时,都会在TestRun
中创建一行?这将保留特定的Property
,并且如果Property
中的条目稍后发生更改,则后续的TestRun
将反映新的更改。Seems like you're using
Test
as both a template for a particular instance of a test, as well as the test itself. Maybe every time a user performs a test according to the specification inTest
, create a row in, say,TestRun
? This would preserve the particularProperty
s, and if the entries inProperty
change later, then subsequentTestRun
s would reflect the new changes.