ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Различные способы реализации "истории изменений" в 1-й базе данных?
17 сообщений из 42, страница 2 из 2
  2  все
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33653122
GoldDragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GoldDragon
Гость
iscrafm, ModelR, Estets

Ребята, честное слово, большое спасибо, что пытаетесь помочь мне. Но... у меня складывается ощущение, что вы не поняли саму суть вопроса или я что-то упускаю.
Вернёмся к началу:
Есть, то что я называю 2 стандартных решения организации системы учёта:
1. Каждое изменение поля заносится в таблицу + поля самого учёта (это то что вы ModelR, Estets написали в своём варианте).
2. Каждое изменении записи заносится в таблицу + поля самого учёта, как мне кажется - это то что предлагаешь ты, iscrafm. Я не говорил как я буду организовывать это: через тригерры или процедуру - это не важно.

Вопрос который я пытался задать был другой: ИМЕЕТ ЛИ СМЫСЛ, использовать оба этих стандартных решения для таблиц или нет, и чем это чревато, кроме как более развёрнутая логика?
...
Рейтинг: 0 / 0
07.04.2006, 18:15
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33653868
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
использовать, имхо, можно или первый или второй вариант. Во втором, имхо опять же, проще необходимая отчетность получается и им проще управлять.
...
Рейтинг: 0 / 0
08.04.2006, 17:30
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33655109
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
"По полям" - лучше, когда поля меняюся в разном темпе (дни, годы). Проще ответить когда и кто менял поле.
"По записям" - лучше, когда объект рассматривается как целое. Любое изменение рассматриваеися как создающее новую версию; когда чаще запрашивают значения на дату чем дату значения. Т.е это хороший вариант для собственно оперативной работы.

Итого, судя по по написанному, я бы взял за основу "По записям" , две таблицы на объект с постоянной и с исторической частью. Есть конечно вопрос, насколько загрузят систему запросы про кто и когда сказал мяу. Но это только Вы можете определить.
...
Рейтинг: 0 / 0
10.04.2006, 10:35
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33655329
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
GoldDragon
Вопрос который я пытался задать был другой: ИМЕЕТ ЛИ СМЫСЛ, использовать оба этих стандартных решения для таблиц или нет, и чем это чревато, кроме как более развёрнутая логика?
Теперь я не понял вопрос. Имеет ли смысл использовать оба подхода одновременно ? На это вопрос вам боюсь ни кто не ответит. Поскольку никто не знает "Что и в каком виде" вы хотите получить в результате внедрения "исторического учета"

Если надо быстро получить ответ на вопрос кто и когда исправил в договоре "эту сумму на эту", то стоит хранить изменение значений полей. Если нужно показать "договор таким как он был на 01.01.06" то легче хранить изменение всей строки таблицы. Если нужно и то и другое то и хранить надо все.

Из своего опыта могу сказать что восновном использую подход описанный iscrafm . Вы судя по всему не совсем поняли что он предлагает, попробую описать как это выглядит у нас.

Есть анкеты клиентов, исправление которых закрыто из интерфейса. Приходит клиент, или присылает документ в котором написано "Моя фамилия изменилась с Перова на Васечкина". Оператор вводит документ "Изменение анкеты клиента", гле выбирает действие: "Изменение" и анкету: "Петров А.А." Автоматом заполняются данные которые были в системе на момент внесения изменений. Фамилия "Петров", дата рождения, инн, адреса и пр. Оператор вносит изменение в поле фамилия и сохраняет документ.

В данный момент в системе существует два набора данных "Анкета лица" с фамилией "Петров", и "Изменение анкеты" с фамилией "Васечкин". Документ "Изменение анкеты" хранит в себе "ID" изменяемого справочника, оператора, основание, Вх.-Исх. номера, комментарии.

Потом происходит то что уважаемый iscrafm назвал "Процедурой постинга", а у нас называется "Подтверждением изменений". Оператор или контролер проверив правильность внесенной информации, подтверждает "Изменение анкеты" и данные переносятся в основную таблицу "Анкеты лиц" простым UPDATE.

Вставка новой анкеты производится аналогично только оператор выбирает действие: "Вставка", а новая запись с анкетой вставляется а не изменяется.

В результате мы имеем текущие данные в Анкете и историю изменений, из которых можно понять кто когда и на каком основании вставил/изменил/удалил данные.
...
Рейтинг: 0 / 0
10.04.2006, 11:44
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33655347
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
P.S. Не уверен, что для вашего вслучая этот подход подойдет. Это зависит от того как построен документооборот у вас. В нашем случае все внесения изменений данных "законодательно" должны регистрироваться, и воответственно происходят на основании подписанных клиентом документов, имеюжих вхоящую дату и номер.
...
Рейтинг: 0 / 0
10.04.2006, 11:49
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33656974
GoldDragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GoldDragon
Гость
iscrafmиспользовать, имхо, можно или первый или второй вариант. Во втором, имхо опять же, проще необходимая отчетность получается и им проще управлять.
Теперь мы говорим по существу :)
Допустим, мы используем 2-й вариант, тогда что у нас получится:
10% полей изменяется часто, другие - очень редко. Некоторые поля вообще имеют тип - ТЕКСТ. Т.е. 1 запись будет в райoне 1-2к. Т.е. в среднем будет добавлятся от 1М до 5М данных в день. Сам посчитай что получится через месяц. А история должна хранится от 5 до 10 лет, зависит от правил штата.
...
Рейтинг: 0 / 0
10.04.2006, 20:15
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33657030
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
а...ты ж не забывай, что пишутся только изменения. Если текст менялся, то при любом раскладе его нужно записать в базу. А не менялся, то он и не будет место занимать.

если тупо в лоб, то примерно это имелось ввиду в процедуре постинга:

Код: plaintext
1.
2.
3.
4.
update tagtable
set descr = isnull(s.descr,t.descr)
from srctable s
inner join tagtable t on t.id = s.tagid
where s.batchid = @batchid

т.е. неизменяемые поля заполнять не нужно когда вводится информация.
...
Рейтинг: 0 / 0
10.04.2006, 20:52
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33657514
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
А как тогда занулить поле? Старое 'xxx' , новое NULL. В источнике придется иметь флаги изменения для каждого поля. В источник также нужно той же транзакцией вернуть временнУю метку/последовательный номер.
Т.е по сравнению с простой исторической таблицей технология несколько сложнее.
...
Рейтинг: 0 / 0
11.04.2006, 10:09
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33657546
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Наверное обязательно в системе будут такие запросы: покажите мне каким был объект 01.01.2004 в 10:45:33. Или более того, нужно будет соорудить множество всех объектов на заданную точку времени.Если хранить историчность по полям - то это будет просто тихий ужас. Если по строкам - то более-менее все будет ворочаться. Взвесьте сначала какого типа тормоза нужны (и какой сложности) вам в вашей системе нужны.
...
Рейтинг: 0 / 0
11.04.2006, 10:19
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33657560
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ModelRА как тогда занулить поле? Старое 'xxx' , новое NULL. В источнике придется иметь флаги изменения для каждого поля. В источник также нужно той же транзакцией вернуть временнУю метку/последовательный номер.
Т.е по сравнению с простой исторической таблицей технология несколько сложнее.
я бы так сказал. Это несколько может и сложнее в плане интерфейса, но совсем немного.
А зачем метки возвращать?
...
Рейтинг: 0 / 0
11.04.2006, 10:24
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33658049
AlexTheRaven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexTheRaven
Участник
По-моему, организация хранения исторических данных зависит от самой концепции укладки классов в БД.

Можно хранить каждый класс в отдельной таблице (ROT). Тогда хранение исторических данных можно организовать:
1) В виде отдельной "таблице изменений строк", либо "таблицей изменений ячеек"
2) В той же таблице, с признаком "актуальности", "времени действия"
3) Использованием темпоральных расширений выбранной СУБД
4) Теоретически - хитрой работой с журналом.
В (1) будет дублирование данных, в (2) - сложная логика работы. (4) - не пробовал, вряд ли решение будет хорошим. Я выбрал бы (3), если не предполагается переходить с одной СУБД на другую.

Можно хранить классы в структуре EAV. Тогда всё получается само собой, достаточно в таблице значений атрибутов добавить поля "актуальность" и "дата создания", а вместо изменения значения добавлять новое, а старое объявлять неактуальным. Делал, работает, логика не очень сложная.
...
Рейтинг: 0 / 0
11.04.2006, 12:46
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33658885
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
iscrafmА зачем метки возвращать?Э.. я так понял, что в данном случае время фактического обновления основной таблицы и есть прикладное время, это же регистрация изменеий характеристик объектов недвижимости в "реальном" времени, а не бух проводки за позапрошлый месяц. Но даже если нет, административное время все равно необходимо.
...
Рейтинг: 0 / 0
11.04.2006, 16:09
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33659802
GoldDragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GoldDragon
Гость
А как насчёт такой модели?
Допустим, у нас есть таблица X.
Строим 3 таблицы (не буду описывать сами поля, только смысл):
X_Dates - хранится информация о времени изменения;
X_Fast - только частоизменяемые поля;
X_Slow - редкоизменяемые.
Связи между ними 1 к 1-му.

Я сейчас говорю о варианте, когда вся запись изменяется.
...
Рейтинг: 0 / 0
11.04.2006, 23:13
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33659806
GoldDragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GoldDragon
Гость
GoldDragonЯ сейчас говорю о варианте, когда вся запись изменяется.

Т.е. не каждое изменение, полностью вся запись записывается. Только теперь это будет записываться в 2 таблицы данных и 1 таблица времени изменения. Если никакое поле, которое находится в 1-й из таблиц, не было заменено, то и запись туда не будет заносится, только во другую.
...
Рейтинг: 0 / 0
11.04.2006, 23:22
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33659810
GoldDragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GoldDragon
Гость
AlexTheRaven
Можно хранить классы в структуре EAV. Тогда всё получается само собой, достаточно в таблице значений атрибутов добавить поля "актуальность" и "дата создания", а вместо изменения значения добавлять новое, а старое объявлять неактуальным. Делал, работает, логика не очень сложная.

И что это за зверь такой? :) И где его найти можно?
...
Рейтинг: 0 / 0
11.04.2006, 23:25
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33660213
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
GoldDragon AlexTheRaven
Можно хранить классы в структуре EAV. Тогда всё получается само собой, достаточно в таблице значений атрибутов добавить поля "актуальность" и "дата создания", а вместо изменения значения добавлять новое, а старое объявлять неактуальным. Делал, работает, логика не очень сложная.

И что это за зверь такой? :) И где его найти можно?
Это такой принцип построения хранилища данных. Запусти в гугле EAV/CR, повываливается много.
...
Рейтинг: 0 / 0
12.04.2006, 10:05
| Ответить | Цитировать | Написать  
Различные способы реализации "истории изменений" в 1-й базе данных?
    #33660273
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
GoldDragonТ.е. не каждое изменение, полностью вся запись записывается. Только теперь это будет записываться в 2 таблицы данных и 1 таблица времени изменения. Если никакое поле, которое находится в 1-й из таблиц, не было заменено, то и запись туда не будет заносится, только во другую.Логически это тоже вполне нормальный вариант. Но выбор зависит чисто от количественных физических характеристик. Боюсь, что формул не найдете. Экспериментируйте.
...
Рейтинг: 0 / 0
12.04.2006, 10:21
| Ответить | Цитировать | Написать  
17 сообщений из 42, страница 2 из 2
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Различные способы реализации "истории изменений" в 1-й базе данных?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=33655329&tid=1545325]:
 0ms
get settings:
 9ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 156ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 53ms
get tp. blocked users:
 2ms
others: 236ms
total:  489ms
созд. / загр.: 489ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]