Форум: "Базы";
Текущий архив: 2002.07.22;
Скачать: [xml.tar.bz2];
ВнизКак избавиться от появления лишних данных в базе? Найти похожие ветки
← →
Fox_Home (2002-06-28 04:46) [0]День добрый!
вот такая проблема возникла:
допустим есть набор связанных таблиц, которые в интерфейсе показываються как одна форма, особенность в том что на уровне базы данных каждое изменение в базе автоматически фиксируеться( это сделанно для того чтобы фиксировать статистику изменений), а с учетом связанности таблиц на 3-4 уровня, при изменении на интерфейсе одного из значений, автоматически пораждается куча повторных записей в базе данных...
теперь вопрос, как бы зафиксировать конект к базе до момента нажатия кнопки ОК, или Отмена, чтобы в случае множественных изменений на интерфейсе в базе появлялся только один набор измененых данных???, либо если Отмена то в базу вообще ни чего не попадало???
Временные таблички тут не помогают, потому как при внесении в базу очередной записи где-нибудь на 3ем уровне, порождаються копии не измененных данных на всех уровнях...
мне на палцах обьяснили что делать надо примерно так:
фиксировать DataSet, если ОК, то передавать его в базу либо на прямую, либо через какой-нибудь коннектор(ы) к базе(его наверно тоже надо писать отдельно на тот случай если для храения данных предполагаеться использовать разные базы MsSQL, Oracal, IB или еще что-нибудь), если отмена то не передавать ни чего!
я пока еще не дорос до такого понимания, по этому прошу совета, посоветайте где можно найти ответ на свой вопрос?
можно ли это реализовать как-то иначе?
← →
Polevi (2002-06-28 08:17) [1]если у тебя изменения пишутся в лог таблицу в триггерах, то к чему вообще разговор об интерфейсе и датаcете ?
Напиши процедурку которая будет из лог таблицы раз в день удалять повторяющиеся записи.
Или я чего то не так понял ?
← →
ShuraGrp (2002-06-28 10:02) [2]Можно оформить запись в журнал в процедуру, а не на тригер, и по ОК запускать процедуру, а в противном случае не запускать.
Здесь только одна тонкость - надо внимательно отследить те места, где эта процедура действительно должна запускаться. Удачи.
← →
Fox_Home (2002-06-28 11:42) [3]2 Polevi
дело в том что данные в базу попадают примерно так
есть договор, у которого несколько связанных таблиц, типа контрагент, товар и т.д.
допустим в договоре сменились реквизиты контрагента, нам нужно породить две записи
первая: это новая редакция договора в таблице договоров
и вторая: новая редакция контрагента в таблице контрагентов
на самом деле порождаеться записей на много больше, потому что при создании новой редакции договора, в каждой связанной таблице появляеться новая запись для данной редакции договора...
допустим это приемлемо...
а теперь представьте что нужно одновременно изменить два параметра, например реквизиты контрагента и цену товара, в момент изменения контрагента порождаеться новая редакция договора, а в момент изменения цены пораждаеться еще одна редакция договора, хотя на самом деле можно было бы порадить всего одну редакцию с двумя измененными подчиненными табличками!
если бы гдето в кеше создать измененный вариант договора, а потом его разом пихнуть в базу, то не появилось бы две записи, ну и плюс ко всему кеш можно сбросить в случае отмены, и тода не пришлось бы удалять записи из базы в случае не окончания изменения договора...
← →
fnatali (2002-06-28 12:23) [4]Я, может, чего-то не понимаю, но если изменяются реквизиты контрагента, то изменения касаются только таблицы "контрагенты". В таблице "договоры" содержится лишь ссылка на таблицу "контрагенты" и она не изменяется. Зачем её заносить в лог-файл? Тоже самое и с изменением цены. Если же в договорах поменяли одного контрагента на другого, только в этом случае появляется редакция таблицы "договоры". Но опять же только одна запись об изменениях. Или всё-таки ты имел в виду что-то другое?
← →
Fox_Home (2002-06-28 12:38) [5]1 нам необходимо фиксировать кто из пользователей менял документ!
2 бывает необходимость восстановить документ на какойто давно прошедший период, даже если после этого документ десять раз менялся...
просто мы посчитали что небольшая избыточность не повредит, зато будет быстрее происходить поиск по базе...
можно было бы вообще не пораждать ни одной повторяющейся записи, но тогда бы запрос к базе был бы очень сложным...
у нас максимальное вложение подчиненых таблиц до 12 !
← →
Delirium (2002-06-28 12:54) [6]Налицо стандартная ситуация невозможности прямой модификации информации в БД из-за сложных бизнес-правил. Для этой цели созданы хранимые процедуры. Требуется понимание бизнес-процесса и проработка правил работы с информацией. Вообще существует негласный закон для больших БД - все изменения должны осуществляться исключительно через ХП.
← →
Polevi (2002-06-29 11:04) [7]2Fox_Home
Значит надо сделать кэш - какие проблемы ?
Создаем кеш таблицу, в триггере смотрим - если для данного договора там нет записей - добавляем, иначе модифицируем запись в кеше. А специальная SP будет удалять записи из кеша и бросать их в лог таблицу
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.07.22;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.006 c