Проектирование БД

← →
Andrey V. (2003-02-17 21:06) [0]

Прошу заранее извинить если вопрос не соответствует эхотагу.
Уперся в такую проблему , с которыми раньше не приходилось сталкиваться.
Нужно хранить в базе историю изменения данных.На первый взгляд все казалось просто - завести поле(вроде даты с которой запись активна) и все. Но все портит вероятность внесения информации задним числом.

Если ближе к предмету , то речь идет о хранилище информации о квартирах. Допустим 1мая жилая площадь составляла 100м.
1июня она стала 90м и (ну к примеру) 1августа - 70м.Все вроде нормально - имеется три строки и все ок. Но вдруг надо внести информацию за 15мая и площадь 50м. Получается что историю позднее 15мая надо покилять.
И это было бы реально если бы квартира не имела еще кучу атрибутов , которые конечно тоже могут во времени меняться. Понятно ,что проблема не решается советом , типа А+Б. Я и не жду конкретного совета(хотя в тайне надеюсь).Наведите на сайты,форумы или книжки , где можно обсудить это , проблема-то не редкая , как я понимаю.

← →
Romkin © (2003-02-17 22:14) [1]

Немного не понятно, какого фига так все меняется? И почему трудно удалить в триггере информацию старше вставляемой даты? Или поставить у нее флаг несоответствия? Или выдать ошибку? Или вести реальные дела в одной таблице, а журнал изменений - в другой?

← →
Andrey V. (2003-02-17 22:37) [2]

Удалить-то не проблема.
Но в "старших" записях может быть "нужная" информация и ее нельзя
терять...
С журналом идея интересная,но что там хранить строки или только
измененые поля ? Но и там IMHO все летит при записях "задним" числом.

← →
AK-74 © (2003-02-17 22:46) [3]

2 Andrey V.

Почту проверь

← →
Sergey13 © (2003-02-18 09:54) [4]

2AK-74 © (17.02.03 22:46)
>Почту проверь
Может это и не вежливо, но если не секрет, что там. Меня эта тема тоже очень интересует. Только у меня условия посложнее - нужно одновременно работать с разными версиями очень сложной информации. Это из области извещений об изменениях на крупном предприятии.

← →
stone © (2003-02-18 10:12) [5]

> Это из области извещений

ИМХО, чтобы не было извращений нужно тщательно разрабатывать базу данных, а не лепить заплатку на заплатке. Иначе количество подобных извращений будет расти как снежный ком.

← →
jocko (2003-02-18 10:14) [6]

Мне кажется проблема в некорректной постановке задачи.
Определись что хранишь:
а) актуальные данные,
в) хронологию изменений объекта,
в) лог изменений (кто, когда и что менял),
помоему в одном флаконе (и тем более таблице) это не смешаешь, я вижу как минимум 3 объекта (есть объект - есть таблица, остальные рождаются из нормализации и физического проектирования, т.е. N>>3).
Все остальное (выборки по условиям), как мне каж. реализуется бизнес логикой приложения, которая закладывается в хран. процедуры...

ЗЫ:очень грустно,если 1 мая площадь квартиры была 100м а к августу она усохла до 70 м, если так пойдет то через полтора года останется только коврик при входе

← →
Sergey13 © (2003-02-18 10:43) [7]

2stone © (18.02.03 10:12)
>ИМХО, чтобы не было извращений нужно тщательно разрабатывать базу данных
Полностью согласен
>, а не лепить заплатку на заплатке. Иначе количество подобных извращений будет расти как снежный ком.
А, так ты намекаешь, что я извращенец. Ну, батенька, для таких утверждений, нужно по крайней мере представлять себе предметную область.
Ситуация.
Есть сложное изделие (N-деталей).
Конструктора меняют крепление двух (связанных) деталей. Было 5 отверстий - стало 3.
Первой детали - уже наделано на 2 месяца вперед (это не хорошо, но в жизни бывает). У второй задела нет. Что бы изделие собиралось. Нужно второй детали доделать до комплекта первой. По старым чертежам, техпроцессам, нормам, зарплатам....
Но мне нужно и новое состояние. С ним уже работают конструктора, технологи, нормировщики.....

Да и если отвлечься от деталей. Реальное время прохождения изменений в серийном производстве к сожалению намного больше чем время изменения в таблице БД. И с этим ничего не поделаешь. Приходится извращаться.

← →
Romkin © (2003-02-18 10:59) [8]

А, вот теперь понял... Тебе нужна структура с отслеживанием состояний во времени.
Здесь у записей должна вестись история, причем в ней должна быть дата внесения изменения и дата начала действия изменения, как минимум.
У тебя - что-то вроде связки мастер-деталь, мастер: наименование комплектующего и тд, деталь - дата/время изменения, дата начала действия изменения, ссылка на спецификацию...
Тогда разные функции будут брать что нужно - одни информацию на момент заказа, другие - спецификацию на текущий момент.
Упрощенно, конечно, может понадобится более сложная структура. Но удалять уж точно ничего не надо :-)

← →
MsGuns © (2003-02-18 11:14) [9]

>Sergey13 © (18.02.03 09:54)

Эх, было дело когда-то... Разрабатывали "АПКИ" - автоматизированное проведение конструкторских изменений. СУБД - ADABAS (точнее, "СПЕКТР"), завод - радиоприборный. Ностальжи !

Короче, без сущности "Комплект" и "Расцеховка" тебе эту траблу вряд ли решить. ;)))

← →
Sergey13 © (2003-02-18 11:16) [10]

2Romkin © (18.02.03 10:59)
Ну в принципе то оно все понятно. Но в реале все намного сложней. Например состояние какого то объекта (изделия) - это не одна таблица, и даже не один десяток таблиц, завязаных друг на друга такими связями, что мало не покажется. 8-(
Да и дата изменения не шибко катит, только как чисто информативная штука. Дело в том что производство - процесс достаточно (мягко говоря) рассинхронизированый по времени. Тем паче что все состояния надо хранить "вечно"(достаточно долго 8-), для рассмотрения рекламаций например.
>Но удалять уж точно ничего не надо :-)
Помилуй Бог. Чур меня. 8-))))))))))))))))

← →
Romkin © (2003-02-18 11:38) [11]

А я и не говорил, что будет легко :-))
Есть много способов это организовать, вопрос в конкретике.
Типично - в таблицах ставится timestamp, и по нему вычисляется, что когда было...

2Romkin © (18.02.03 11:38)
>Типично - в таблицах ставится timestamp
Это когда вся сущность описана этой таблицей. Потом, какая то часть старой инфы (99%) переходит без изменения и новую. Нет, тут сложнее все.

>Sergey13 © (18.02.03 11:16)
>Ну в принципе то оно все понятно. Но в реале все намного сложней. Например состояние какого то объекта (изделия) - это не одна таблица, и даже не один десяток таблиц, завязаных друг на друга такими связями, что мало не покажется. 8-(

Ну, несколько десятков - это ты загнул
По большому счету, таблицы следующие:

-Состав изделий (дерево) (в народе - ВПР), включающий понятие - ключ "Комплект"
-Нормы ПКИ на ДСЕ (в народе ВНР ПКИ)
-Расцеховка (т.е. номера цехов на ДСЕ)
-БД конструкторских извещений (2 таблицы)
-БД технологических извещений (2 таблицы)

Это если без МТС. Если с материальным учетом (склады, логистика, планирование, учет себестоимости и т.д.), то это уже совсем другая история ;))

Пардон, забыл про "слона" - кодификатор изделий и ДСЕ ;((

Вот это вас занесло, пока хозяина вопроса не было :)

2MsGuns © (18.02.03 12:02)
>Ну, несколько десятков - это ты загнул
Боюсь только в меньшую сторону ошибся. 8-(
>Если с материальным учетом (склады, логистика, планирование, учет себестоимости и т.д.), то это уже совсем другая история
Вот-вот. 8-(
2AK-74 © (18.02.03 13:56)
>Вот это вас занесло, пока хозяина вопроса не было :)
Да уж 8-).

Проектирование БД Найти похожие ветки