Не придумывай. Ты попутал мягкое с теплым. То, для чего автор топика делает свое расширение - это Аудит или Лог-таблицы (в которых кроме ID объекта должно быть ВРЕМЯ_ОПЕРАЦИИ, ТИП_ОПЕРАЦИИ, ПОЛЬЗОВАТЕЛЬ_СОВЕРШИВШИЙ_ОПЕРАЦИЮ). То о чем говоришь ты - это Темпоральные таблицы, в которых кроме ID и атрибутов объекта должны быть 2 обязательных столбца ВРЕМЯ_С и ВРЕМЯ_ПО. И эти 3 столбца ID, ВРЕМЯ_С, ВРЕМЯ_ПО образуют уникальный ключ и позволяют отслеживать временное изменение данных, в том числе и обновлять данные "задним числом". И на эту таблицу для отслеживания всех действий пользователя тоже можно сделать свою аудит-таблицу, которую автор и обозначает как _hist
History-таблицы априори должны быть append-only. Это строки в основной таблице могут быть вставлены(INSERT), обновлены(UPDATE), удалены(DELETE). В history таблицах разрешается только вставка (INSERT) с указанием операции. Но при этом есть особенности - как хранить изменения: полностью копировать измененную строку основной таблицы с указанием типа операции(I,U.D) и атрибутов того, кто это сделал и времени изменения. При этом history-таблица (или таблица аудита) будет в разы больше основной таблицы. Либо же есть вариант, когда в history-таблицы данные заносятся по технологии "разряженных массивов", то есть фиксируются только значения измененных столбцов (при INSERT - изначально вставляются все столбцы и их значения, а при UPDATE - только измененные столбцы, при DELETE - только факт операции). При этом уменьшается размер history-аудит таблицы, но увеличивается время анализа измененных данных, логика и тип хранения этих данных с указанием измененного столбца, процедура восстановления полного состояния полей строки таблицы на определенную дату. Также для history-аудит таблиц делают архивные(archive) таблицы, куда периодически переносят древние строки аудит-таблиц и где-нить хранят отдельно от базы.
Коллеги в части EAV в общем-то показали свой виласапед, но очень простой.
Метод, подобный EAV, но немного другой, более сложный, хранение значений только в текстовом формате заранее оговренных форматов, с разграничением доступа, используется, например, в Oracle eBS (Oracle Fusion Apps) - это основной механизм расширения функциональности этой системы, который не затрагивают патчи. Он применяется уже лет 25-30.
В отечественном ПО мне известен подобный механизм в Босс-Кадровик, он свой, но сделан по мотивам механизмов расширения западного ПО.
Отвечу за авторов - зачем несколько разных типов столбцов? - 1. Для уменьшения места для хранения значения 2. Исключения фазы преобразования из текстового представления в требуемое (дата, число и т.д.)
К расширению через JSON отношусь скепьтически - это временная заглушка. На больших данных это совсем нехорошо.
Не придумывай. Ты попутал мягкое с теплым. То, для чего автор топика делает свое расширение - это Аудит или Лог-таблицы (в которых кроме ID объекта должно быть ВРЕМЯ_ОПЕРАЦИИ, ТИП_ОПЕРАЦИИ, ПОЛЬЗОВАТЕЛЬ_СОВЕРШИВШИЙ_ОПЕРАЦИЮ). То о чем говоришь ты - это Темпоральные таблицы, в которых кроме ID и атрибутов объекта должны быть 2 обязательных столбца ВРЕМЯ_С и ВРЕМЯ_ПО. И эти 3 столбца ID, ВРЕМЯ_С, ВРЕМЯ_ПО образуют уникальный ключ и позволяют отслеживать временное изменение данных, в том числе и обновлять данные "задним числом". И на эту таблицу для отслеживания всех действий пользователя тоже можно сделать свою аудит-таблицу, которую автор и обозначает как _hist
History-таблицы априори должны быть append-only. Это строки в основной таблице могут быть вставлены(INSERT), обновлены(UPDATE), удалены(DELETE). В history таблицах разрешается только вставка (INSERT) с указанием операции. Но при этом есть особенности - как хранить изменения: полностью копировать измененную строку основной таблицы с указанием типа операции(I,U.D) и атрибутов того, кто это сделал и времени изменения. При этом history-таблица (или таблица аудита) будет в разы больше основной таблицы. Либо же есть вариант, когда в history-таблицы данные заносятся по технологии "разряженных массивов", то есть фиксируются только значения измененных столбцов (при INSERT - изначально вставляются все столбцы и их значения, а при UPDATE - только измененные столбцы, при DELETE - только факт операции). При этом уменьшается размер history-аудит таблицы, но увеличивается время анализа измененных данных, логика и тип хранения этих данных с указанием измененного столбца, процедура восстановления полного состояния полей строки таблицы на определенную дату. Также для history-аудит таблиц делают архивные(archive) таблицы, куда периодически переносят древние строки аудит-таблиц и где-нить хранят отдельно от базы.
Коллеги в части EAV в общем-то показали свой виласапед, но очень простой.
Метод, подобный EAV, но немного другой, более сложный, хранение значений только в текстовом формате заранее оговренных форматов, с разграничением доступа, используется, например, в Oracle eBS (Oracle Fusion Apps) - это основной механизм расширения функциональности этой системы, который не затрагивают патчи. Он применяется уже лет 25-30.
В отечественном ПО мне известен подобный механизм в Босс-Кадровик, он свой, но сделан по мотивам механизмов расширения западного ПО.
Отвечу за авторов - зачем несколько разных типов столбцов? - 1. Для уменьшения места для хранения значения 2. Исключения фазы преобразования из текстового представления в требуемое (дата, число и т.д.)
К расширению через JSON отношусь скепьтически - это временная заглушка. На больших данных это совсем нехорошо.
8>-