@DanilovAnatoly27 апр 2009 в 04:24

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

3 мин

2.3K

Чулан

Комментарии 20

@quard 27 апр 2009 в 05:09

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

@DanilovAnatoly 27 апр 2009 в 05:15

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

@quard 27 апр 2009 в 05:26

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

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

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

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

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

@DanilovAnatoly 27 апр 2009 в 05:36

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

@quard 27 апр 2009 в 05:44

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

НЛО прилетело и опубликовало эту надпись здесь

@zw0rk 27 апр 2009 в 05:32

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

@DanilovAnatoly 27 апр 2009 в 05:39

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

@bat 27 апр 2009 в 06:43

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

@bat 27 апр 2009 в 06:45

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

@zw0rk 27 апр 2009 в 06:58

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

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

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

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

@strib 27 апр 2009 в 07:39

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

@bat 27 апр 2009 в 08:34

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

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

@zw0rk 27 апр 2009 в 13:03

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

@strib 27 апр 2009 в 14:08

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

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

@romychs 27 апр 2009 в 06:58

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

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

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

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

@strib 27 апр 2009 в 07:29

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

НЛО прилетело и опубликовало эту надпись здесь

@DanilovAnatoly 27 апр 2009 в 08:13

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

@mgyk 27 апр 2009 в 09:59

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий