реляционные базы данных и управление версиями: интервалы ревизий - PullRequest
1 голос
/ 06 мая 2009

Я думал о том, как применить управление версиями данных к моей относительно простой базе данных, и подумал, что мне следует сделать что-то подобное, упомянутое в посте Джима Т , где есть глобальные ревизии # (например, как в Subversion или Mercurial), и каждая запись базы данных имеет интервал действия.

Пример:

Создать человека.

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |NULL|

Обновление № телефона

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |1   |
|Fred|1 april|555-43534|2   |NULL|

Удалить Фреда:

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |1   |
|Fred|1 april|555-43534|2   |2   |

Есть ли недостатки у этого подхода? Это не кажется сложным.

Единственное, о чем я могу думать, - это то, что, похоже, это будет иметь незначительные последствия для первичных ключей, кроме номера автоинкрементной записи, который является независимым и не связан с данными. Например, если у вас были такие данные:

 Person: (primary key = PersonID which is an autoincrementing integer)
 |PersonID|Name|Telephone|
 |1       |Fred|555-2938|
 |2       |Lois|555-2939|
 |3       |Jim |555-1000|

 Home: (primary key = HomeID which is an autoincrementing integer)
 |HomeID|Address       |
 |1     |123 Elm St.   |
 |2     |456 Maple Ave.|

 PersonHome: (primary key = person ID and home ID)
 |PersonID|HomeID|
 |1       |1     |
 |2       |1     |
 |3       |2     |

тогда вы не можете просто добавить поля From и To выше, так как вы разрушаете уникальность первичных ключей. Вместо этого мне, вероятно, придется сделать что-то вроде этого (с соответствующими индексами, добавленными для замены функции предыдущих первичных ключей):

 Person: (primary key = K which is an autoincrementing integer)
 |K|PersonID|Name     |Telephone|From|To  |
 |1|1       |Fred     |555-2938 |1   |NULL|
 |2|2       |Lois     |555-2939 |1   |1   |
 |3|3       |Jim      |555-1000 |1   |NULL|
 |4|4       |Sunshine |555-2000 |1   |2   |
 |5|2       |Lois     |555-1000 |2   |NULL|
 |6|4       |Daisy May|555-2000 |3   |NULL|
 |7|5       |Connor   |         |5   |NULL|

 Home: (primary key = K which is an autoincrementing integer)
 |K|HomeID|Address       |From|To  |
 |1|1     |123 Elm St.   |1   |NULL|
 |2|2     |456 Maple Ave.|1   |NULL|
 |3|3     |789 Vista Dr. |1   |3   |
 |4|3     |104 Vista Dr. |4   |NULL|   

 PersonHome: (primary key = K which is an autoincrementing integer)
 |K|PersonID|HomeID|From|To  |
 |1|1       |1     |1   |NULL|
 |2|2       |1     |1   |1   |
 |3|3       |2     |1   |NULL|
 |4|4       |3     |1   |NULL|
 |5|2       |2     |2   |NULL|
 |6|5       |2     |5   |NULL|

 Revisions: (comments here for illustration)
 |Revision|Comments                                                       |
 |1       |Initial dataset                                                |
 |2       |Lois divorced Fred and moved in with Jim                       |
 |3       |Sunshine changed her name to Daisy May                         |
 |4       |Daisy May's house was renumbered by the fire dept for 911 rules|
 |5       |Lois and Jim had a baby named Connor                           |

1 Ответ

1 голос
/ 07 мая 2009

Сам размышляю над тем же вопросом!

недостаток от | до конструкции заключается в необходимости обновления и вставки, когда вы хотите добавить новую версию записи. Я также обеспокоен тем, что эта конструкция имеет двойное значение, она сообщает вам версию, например, х | null означает самый последний и сообщает вам статус записи, например, х | х означает удаленный.

Историческая мудрость предполагает использование дат http://www.dbforums.com/database-concepts-design/1641734-data-record-versioning-how-implement.html

Работа с датами - это не самое лучшее, что нужно делать, когда вы переносите данные в объектную модель.

В последнее время предпочтение отдается двум таблицам База данных - управление версиями данных

Я тоже не слишком заинтересован в этом из-за необходимости поддерживать дублирующиеся таблицы.

Если бы вы изменили свое решение, добавив в него столбец версии и столбец состояния? Самый высокий номер версии - самый последний, статус записи - в самой последней версии.

Все еще размышляю ...

...