DanilovAnatoly Apr 27 2009 at 08:24

Версионность данных в MySQL

3 min

2.1K

Lumber room

Comments 20

quard Apr 27 2009 at 09:09

реализацию простой вещи усложнили в несколько раз

DanilovAnatoly Apr 27 2009 at 09:15

Может быть. Собственно топик и написан для того, что бы узнать как это сделано у других ;)
Поделитесь знаниями — как сделать проще?

quard Apr 27 2009 at 09:26

черт, начал перечитывать топик и понял что в конце вы пришли к решению, окторое меня устраивает :)

с датой я только не понял, какой у нее тип?

и зачем нужны SET @param? в коде проставлять нельзя было?

LIMIT 0,1 можно сократить до LIMIT 1

P.S. мы оказывается земляки ;)

DanilovAnatoly Apr 27 2009 at 09:36

У даты тип datetime.
«SET @param» использую для наглядности и для удобства(моего)

quard Apr 27 2009 at 09:44

если это datetime, то формат странный :) datetime это '2009-04-27 10:38:10' у вас ближе к timestamp

UFO just landed and posted this here

zw0rk Apr 27 2009 at 09:32

Название сильно отличается от содержания %) Где тут периодические переменные? Это скорее можно обозвать (и обычно и обзывают) «версионность данных».

DanilovAnatoly Apr 27 2009 at 09:39

Спасибо, топик переименовал.

bat Apr 27 2009 at 10:43

Ну и зря.
Версионность в СУБД, это несколько иное. Условно говоря, это организация данных, при которой хранится старая версия записи, необходимая транзакциям, запущенным раньше, чем транзакция изменившая эту запись. Версионность изначально была в Interbase/Firebird, pgsql тоже версионник, вроде как такая фишка появилась в MSSQL.

bat Apr 27 2009 at 10:45

Я собственно и купился на заголовок, подумав, что в MySQL анонсировали версионность.

zw0rk Apr 27 2009 at 10:58

Ну можно назвать «имитация версионности». Суть не меняется. В любом случае, такое название гораздо ближе по смыслу к содержанию, чем «периодические переменные».

> Версионность в СУБД, это несколько иное. Условно говоря, это организация данных,

Это тоже не всегда так. Версионность это поддержка хранения версий объектов. Как она реализована: на уровне СУБД или непосредственно логикой — дело десятое.

Вот в Оракле, возможно, есть версионность на уровне СУБД? А в ПО всем известной конторы CBOSS она реализуется программно.

strib Apr 27 2009 at 11:39

В версиях 9 и 10 оно работает на undo сегменах. Ясно что совсем недолго данные хранятся.
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь

bat Apr 27 2009 at 12:34

В версиях 9 и 10 оно работает на undo сегменах

Оно и в 8-ке так же работает, только при активных изменениях данных легко словить «слишком старый снимок» + достаточно дорогой rollback.

zw0rk Apr 27 2009 at 17:03

Я имел в виду, что то, что в Оракле это есть «из коробки» не остановило ребят из CBOSS сделать это программно. Они не дураки, я думаю, просто так не делали бы.

strib Apr 27 2009 at 18:08

Как раз таки и не было. CBOSSу в этом случае зачет.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.

«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.

romychs Apr 27 2009 at 10:58

Обычно, для таких целей достаточно просто хранить две даты, дату начала и дату конца жизни версии данной записи.
Например fd (from date) и td (to date)

При создании новой записи fd=now(), td=«некая дата в далеком будущем»
При создании новой версии, записи td=now(), у новой записи fd=now(), td=«некая дата в далеком будущем»

И соответственно для получения текущей версии SELECT… FROM… WHERE NOW() BETWEEN fd AND td

Встречал подобную схему в некоторых коммерческих системах биллинга, когда, например, нужно хранить версии тарифных планов и историю их изменения. Списки услуг у абонента и их историю. А «виновников» внесения тех или иных изменений можно хранить в отдельной таблице.

strib Apr 27 2009 at 11:29

Возможно к этому решению стоит добавить булево поле active_version и сделать по нему btree индекс.
Не факт, но может ускорить работу с актуальными версиями.
А так, предложенная схема вполне работоспособна.

UFO just landed and posted this here

DanilovAnatoly Apr 27 2009 at 12:13

Да, понял что даты это не главное и что нужно поле active_version.
Хотя все зависит от контекста задачи.

mgyk Apr 27 2009 at 13:59

Имхо данная штука имитируется прозрачно одним триггером. На Update вешаем вставку данных + перемещение маркера текущей записи.