| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проектирование БД [D5, IB6.x]
Andrey V. © (2003-02-17 21:06:00)Прошу заранее извинить если вопрос не соответствует эхотагу.
Уперся в такую проблему , с которыми раньше не приходилось сталкиваться.
Нужно хранить в базе историю изменения данных.На первый взгляд все казалось просто - завести поле(вроде даты с которой запись активна) и все. Но все портит вероятность внесения информации задним числом.
Если ближе к предмету , то речь идет о хранилище информации о квартирах. Допустим 1мая жилая площадь составляла 100м.
1июня она стала 90м и (ну к примеру) 1августа - 70м.Все вроде нормально - имеется три строки и все ок. Но вдруг надо внести информацию за 15мая и площадь 50м. Получается что историю позднее 15мая надо покилять.
И это было бы реально если бы квартира не имела еще кучу атрибутов , которые конечно тоже могут во времени меняться. Понятно ,что проблема не решается советом , типа А+Б. Я и не жду конкретного совета(хотя в тайне надеюсь).Наведите на сайты,форумы или книжки , где можно обсудить это , проблема-то не редкая , как я понимаю.
Sergey13 (2003-02-19 09:58:00) [1]2MsGuns © (18.02.03 12:02)
>Ну, несколько десятков - это ты загнул
Боюсь только в меньшую сторону ошибся. 8-(
>Если с материальным учетом (склады, логистика, планирование, учет себестоимости и т.д.), то это уже совсем другая история
Вот-вот. 8-(
2AK-74 © (18.02.03 13:56)
>Вот это вас занесло, пока хозяина вопроса не было :)
Да уж 8-).
AK-74 (2003-02-18 13:56:00) [2]Вот это вас занесло, пока хозяина вопроса не было :)
MsGuns (2003-02-18 12:07:00) [3]Пардон, забыл про "слона" - кодификатор изделий и ДСЕ ;((
MsGuns (2003-02-18 12:02:00) [4]>Sergey13 © (18.02.03 11:16)
>Ну в принципе то оно все понятно. Но в реале все намного сложней. Например состояние какого то объекта (изделия) - это не одна таблица, и даже не один десяток таблиц, завязаных друг на друга такими связями, что мало не покажется. 8-(
Ну, несколько десятков - это ты загнул
По большому счету, таблицы следующие:
-Состав изделий (дерево) (в народе - ВПР), включающий понятие - ключ "Комплект"
-Нормы ПКИ на ДСЕ (в народе ВНР ПКИ)
-Расцеховка (т.е. номера цехов на ДСЕ)
-БД конструкторских извещений (2 таблицы)
-БД технологических извещений (2 таблицы)
Это если без МТС. Если с материальным учетом (склады, логистика, планирование, учет себестоимости и т.д.), то это уже совсем другая история ;))
Sergey13 (2003-02-18 11:58:00) [5]2Romkin © (18.02.03 11:38)
>Типично - в таблицах ставится timestamp
Это когда вся сущность описана этой таблицей. Потом, какая то часть старой инфы (99%) переходит без изменения и новую. Нет, тут сложнее все.
Romkin (2003-02-18 11:38:00) [6]А я и не говорил, что будет легко :-))
Есть много способов это организовать, вопрос в конкретике.
Типично - в таблицах ставится timestamp, и по нему вычисляется, что когда было...
Sergey13 (2003-02-18 11:16:00) [7]2Romkin © (18.02.03 10:59)
Ну в принципе то оно все понятно. Но в реале все намного сложней. Например состояние какого то объекта (изделия) - это не одна таблица, и даже не один десяток таблиц, завязаных друг на друга такими связями, что мало не покажется. 8-(
Да и дата изменения не шибко катит, только как чисто информативная штука. Дело в том что производство - процесс достаточно (мягко говоря) рассинхронизированый по времени. Тем паче что все состояния надо хранить "вечно"(достаточно долго 8-), для рассмотрения рекламаций например.
>Но удалять уж точно ничего не надо :-)
Помилуй Бог. Чур меня. 8-))))))))))))))))
MsGuns (2003-02-18 11:14:00) [8]>Sergey13 © (18.02.03 09:54)
Эх, было дело когда-то... Разрабатывали "АПКИ" - автоматизированное проведение конструкторских изменений. СУБД - ADABAS (точнее, "СПЕКТР"), завод - радиоприборный. Ностальжи !
Короче, без сущности "Комплект" и "Расцеховка" тебе эту траблу вряд ли решить. ;)))
Romkin (2003-02-18 10:59:00) [9]А, вот теперь понял... Тебе нужна структура с отслеживанием состояний во времени.
Здесь у записей должна вестись история, причем в ней должна быть дата внесения изменения и дата начала действия изменения, как минимум.
У тебя - что-то вроде связки мастер-деталь, мастер: наименование комплектующего и тд, деталь - дата/время изменения, дата начала действия изменения, ссылка на спецификацию...
Тогда разные функции будут брать что нужно - одни информацию на момент заказа, другие - спецификацию на текущий момент.
Упрощенно, конечно, может понадобится более сложная структура. Но удалять уж точно ничего не надо :-)
Sergey13 (2003-02-18 10:43:00) [10]2stone © (18.02.03 10:12)
>ИМХО, чтобы не было извращений нужно тщательно разрабатывать базу данных
Полностью согласен
>, а не лепить заплатку на заплатке. Иначе количество подобных извращений будет расти как снежный ком.
А, так ты намекаешь, что я извращенец. Ну, батенька, для таких утверждений, нужно по крайней мере представлять себе предметную область.
Ситуация.
Есть сложное изделие (N-деталей).
Конструктора меняют крепление двух (связанных) деталей. Было 5 отверстий - стало 3.
Первой детали - уже наделанона 2 месяца вперед (это не хорошо, но в жизни бывает). У второй задела нет. Что бы изделие собиралось. Нужно второй детали доделать до комплекта первой. По старым чертежам, техпроцессам, нормам, зарплатам....
Но мне нужно и новое состояние. С ним уже работают конструктора, технологи, нормировщики.....
Да и если отвлечься от деталей. Реальное время прохождения изменений в серийном производстве к сожалению намного больше чем время изменения в таблице БД. И с этим ничего не поделаешь. Приходится извращаться.
jocko (2003-02-18 10:14:00) [11]Мне кажется проблема в некорректной постановке задачи.
Определись что хранишь:
а) актуальные данные,
в) хронологию изменений объекта,
в) лог изменений (кто, когда и что менял),
помоему в одном флаконе (и тем более таблице) это не смешаешь, я вижу как минимум 3 объекта (есть объект - есть таблица, остальные рождаются из нормализации и физического проектирования, т.е. N>>3).
Все остальное (выборки по условиям), как мне каж. реализуется бизнес логикой приложения, которая закладывается в хран. процедуры...
ЗЫ:очень грустно,если 1 мая площадь квартиры была 100м а к августу она усохла до 70 м, если так пойдет то через полтора года останется только коврик при входе
stone (2003-02-18 10:12:00) [12]
> Это из области извещений
ИМХО, чтобы не было извращений нужно тщательно разрабатывать базу данных, а не лепить заплатку на заплатке. Иначе количество подобных извращений будет расти как снежный ком.
Sergey13 (2003-02-18 09:54:00) [13]2AK-74 © (17.02.03 22:46)
>Почту проверь
Может это и не вежливо, но если не секрет, что там. Меня эта тема тоже очень интересует. Только у меня условия посложнее - нужно одновременно работать с разными версиями очень сложной информации. Это из области извещений об изменениях на крупном предприятии.
AK-74 (2003-02-17 22:46:00) [14]2 Andrey V.
Почту проверь
Andrey V. (2003-02-17 22:37:00) [15]Удалить-то не проблема.
Но в "старших" записях может быть "нужная" информация и ее нельзя
терять...
С журналом идея интересная,но что там хранить строки или только
измененые поля ? Но и там IMHO все летит при записях "задним" числом.
Romkin (2003-02-17 22:14:00) [16]Немного не понятно, какого фига так все меняется? И почему трудно удалить в триггере информацию старше вставляемой даты? Или поставить у нее флаг несоответствия? Или выдать ошибку? Или вести реальные дела в одной таблице, а журнал изменений - в другой?
| |
