Комментарии 20
реализацию простой вещи усложнили в несколько раз
Может быть. Собственно топик и написан для того, что бы узнать как это сделано у других ;)
Поделитесь знаниями — как сделать проще?
Поделитесь знаниями — как сделать проще?
НЛО прилетело и опубликовало эту надпись здесь
Название сильно отличается от содержания %) Где тут периодические переменные? Это скорее можно обозвать (и обычно и обзывают) «версионность данных».
Спасибо, топик переименовал.
Ну и зря.
Версионность в СУБД, это несколько иное. Условно говоря, это организация данных, при которой хранится старая версия записи, необходимая транзакциям, запущенным раньше, чем транзакция изменившая эту запись. Версионность изначально была в Interbase/Firebird, pgsql тоже версионник, вроде как такая фишка появилась в MSSQL.
Версионность в СУБД, это несколько иное. Условно говоря, это организация данных, при которой хранится старая версия записи, необходимая транзакциям, запущенным раньше, чем транзакция изменившая эту запись. Версионность изначально была в Interbase/Firebird, pgsql тоже версионник, вроде как такая фишка появилась в MSSQL.
Я собственно и купился на заголовок, подумав, что в MySQL анонсировали версионность.
Ну можно назвать «имитация версионности». Суть не меняется. В любом случае, такое название гораздо ближе по смыслу к содержанию, чем «периодические переменные».
> Версионность в СУБД, это несколько иное. Условно говоря, это организация данных,
Это тоже не всегда так. Версионность это поддержка хранения версий объектов. Как она реализована: на уровне СУБД или непосредственно логикой — дело десятое.
Вот в Оракле, возможно, есть версионность на уровне СУБД? А в ПО всем известной конторы CBOSS она реализуется программно.
> Версионность в СУБД, это несколько иное. Условно говоря, это организация данных,
Это тоже не всегда так. Версионность это поддержка хранения версий объектов. Как она реализована: на уровне СУБД или непосредственно логикой — дело десятое.
Вот в Оракле, возможно, есть версионность на уровне СУБД? А в ПО всем известной конторы CBOSS она реализуется программно.
В версиях 9 и 10 оно работает на undo сегменах. Ясно что совсем недолго данные хранятся.
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь
В версиях 9 и 10 оно работает на undo сегменах
Оно и в 8-ке так же работает, только при активных изменениях данных легко словить «слишком старый снимок» + достаточно дорогой rollback.
Я имел в виду, что то, что в Оракле это есть «из коробки» не остановило ребят из CBOSS сделать это программно. Они не дураки, я думаю, просто так не делали бы.
Как раз таки и не было. CBOSSу в этом случае зачет.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.
«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.
«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.
Обычно, для таких целей достаточно просто хранить две даты, дату начала и дату конца жизни версии данной записи.
Например fd (from date) и td (to date)
При создании новой записи fd=now(), td=«некая дата в далеком будущем»
При создании новой версии, записи td=now(), у новой записи fd=now(), td=«некая дата в далеком будущем»
И соответственно для получения текущей версии SELECT… FROM… WHERE NOW() BETWEEN fd AND td
Встречал подобную схему в некоторых коммерческих системах биллинга, когда, например, нужно хранить версии тарифных планов и историю их изменения. Списки услуг у абонента и их историю. А «виновников» внесения тех или иных изменений можно хранить в отдельной таблице.
Например fd (from date) и td (to date)
При создании новой записи fd=now(), td=«некая дата в далеком будущем»
При создании новой версии, записи td=now(), у новой записи fd=now(), td=«некая дата в далеком будущем»
И соответственно для получения текущей версии SELECT… FROM… WHERE NOW() BETWEEN fd AND td
Встречал подобную схему в некоторых коммерческих системах биллинга, когда, например, нужно хранить версии тарифных планов и историю их изменения. Списки услуг у абонента и их историю. А «виновников» внесения тех или иных изменений можно хранить в отдельной таблице.
НЛО прилетело и опубликовало эту надпись здесь
Имхо данная штука имитируется прозрачно одним триггером. На Update вешаем вставку данных + перемещение маркера текущей записи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Версионность данных в MySQL