Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.03.10;
Скачать: [xml.tar.bz2];

Вниз

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

 
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, и по нему вычисляется, что когда было...


 
Sergey13   (2003-02-18 11:58) [12]

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


 
MsGuns   (2003-02-18 12:02) [13]

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

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

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

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


 
MsGuns   (2003-02-18 12:07) [14]

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


 
AK-74   (2003-02-18 13:56) [15]

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


 
Sergey13   (2003-02-19 09:58) [16]

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.03.10;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.61 MB
Время: 0.044 c
3-29763
Sectey
2003-02-19 18:11
2003.03.10
Access 2 через Ado


14-30064
SergeN
2003-02-21 10:27
2003.03.10
Эти капли никотина меня убивают!


14-30021
Слесарь Матерящийся
2003-02-20 10:00
2003.03.10
---|Ветка была без названия|---


4-30184
Ahmad K
2003-01-20 02:30
2003.03.10
Выход из виндовса для проги?!


14-30025
Andrey
2003-02-24 12:11
2003.03.10
Как отцепить курсор мышки от самой мышки





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский