Общий вопрос о создании БД

← →
inic © (2004-11-02 14:56) [0]

Меня всегда преследует такая проблема:
Например, есть организации-поставщики с полями (ID*, NAME).
Фирма-потребитель ведет журнал покупок (DATE, SUPPLIER_ID, ...).
Причем, второе поле ссылается на таблицу-справочник "Организации-поставщики".
Допустим фирма-потребитель должна ввести такие журналы какое-то продолжительное время.
Допустим, за это время, некая фирма изменила название или какой-то другой реквизит.
Соответственно, мы должны изменить таблицу-справочник.
Но в отчете за прошедшие периоды мы должны получать старые данные.
Пока я использовал два способа:
1. Запись в журнал реального имени/реквизита, а не использование ссылки через ключ.
2. При изменении названия фирмы, добавляется новая запись, а старая удаляется только, если она не использовалась где-либо (в т.ч. в журнале) ?

Существуют ли другие методы, может быть использование еще одной таблицы - журнала изменений, например ?

← →
Nikolay M. © (2004-11-02 15:24) [1]

Хранить промежуток дат, в который название актуально.

← →
Johnmen © (2004-11-02 16:12) [2]

Идеологически, думается, что способ №1 более верный. Если суть журнала - некий "лог".
Иначе - что-то типа №2.
Есть ещё один вариант. Но более "специфический".
Т.к. у нас появляется ещё одно измерение (совокупность названий одной и той же фирмы), то вводим для них ещё одну таблицу, в которую ссылаемся из справочника...

← →
paul_k © (2004-11-02 16:19) [3]

У нас для таких целей используется понятие "документ на изменение" и копия справочника с указанием даты окончания актуальности. (некий лог изменений)

← →
Sergey13 © (2004-11-02 16:29) [4]

Можно, при №2, добавить ссылку на "предка" фирмы. Тогда, если надо, легко вытащить всю историю, не потеряв.

← →
Жук © (2004-11-02 16:31) [5]

> Sergey13 © (02.11.04 16:29) [4]

Точно. Добавить в справочник поле "ид_предок", ссылающийся на эту же таблицу.

← →
VID © (2004-11-02 16:32) [6]

Дата окончания вещь не всегда предсказуемая. В общем можно сделать так (обобщая вышеприведённые варианты)
В справочнике организаций поставщиков (таблица FIRMS), в полях, всегда должна быть указана именно актуальная информация. И дополнительно для этого справочника необходимо создать новую таблицу (FIRMS_CHANGES) - которая будет содержать след. поля:
ID, FIRM_ID (код организации в таблице FIRMS), CHANGE_DT (дата-время внесения какого-то изменнеия в поля таблицы FIRMS), {и остальные поля-реквизиты, в соотв. с таблицей FIRMS}.

Пользуемся так.
При добавлении новой фирмы, добавляем новую запись в таблицу FIRMS, и сразу же эти же данные в таблицу FIRMS_CHANGES, с указанием поля CHANGE_DT (текущая дата-время). При изменении каких-либо реквизитов фирмы, во-первых изменяем их в таблице FIRMS, а во-вторых добавляем запись с новыми реквизитами в таблицу FIRMS_CHANGES, заодно указывая в поле CHANGE_DT текущую время-дату.

И тд.

Дальше при необходимости получить отчёт, допустим на 20.10.2003, всё становится оч. просто. Просто берёшь из таблицы FIRMS_CHANGES нужные реквизиты (записи), в соотв. со значение поля CHANGES_DT.

← →
inic © (2004-11-02 17:14) [7]

> VID

Да, и мне это хороший способ. Сначала, я решил, что это то же самое, что и №2, но это не так.

Всем спасибо за ответы.

PS Еще надо попробовать "массивовые" типы полей в Интербейзе. Может быть неплохо получится.

← →
msguns © (2004-11-02 18:11) [8]

Вот так вот и создаются проблемы на ровном месте, а потом изобретаются хитровыстеленные способы преодоления, пишутся дисеры..;))

Малаадой челавек, а Вы слыхали что-нибудь об архивах ? Устаревшие данные всегда можно поднять и посмотреть то, что было при царе Горохе и Василисе Премудрой. Ведь тот пример, что Вы привели с изменением наименования поставщиков есть очень упрощенный, фактически выхолощенный. Устареть может очень многое. Например, план счетов, прайсы, информация о взаиморасчетах и т.п. И что, на каждый "чих" свой лог ? Или одын бааалшой на усе случаи жизни ?

← →
VID © (2004-11-02 18:42) [9]

msguns © (02.11.04 18:11) [8]
И что ты советуешь ?

← →
msguns © (2004-11-02 18:49) [10]

>VID © (02.11.04 18:42) [9]
>>msguns © (02.11.04 18:11) [8]
>И что ты советуешь ?

Я вообще-то уже посоветовал (см. [8]). Конечно, бывают случаи, когда одновременно нужны старые и новые данные или надо корректить старые, но это бывает редко. Устаревшие данные удобно и без затрат просматриваются например, на лок.ПК простой переустановкой пути к БД. Более того, можно даже запустить две проги: одна смотрит новую БД (типа сетевую), а другая, запущенная, к примеру из другого каталога, смотрит старую, разархивированную на этой же тачке.
Вообще способов просмотра можно придумать множества. И без хирургии в бизнес-логике самих баз.

msguns, один вопрос к тебе. Берём интервал в три дня. В течении этих трёх дней некая фирма, находящаяся в справочнике FIRMS три раза поменяла своё наименование, в течении трёх дней меняла наименование каждый день.

Что ты сделаешь, пользуясь своей технологией архивов, что бы на четвёртый день, один за другим распечатать три отчёта:
1. Отчёт трёхдневной давности
2. Отчёт двухдневной давности
3. Отчёт однодневной давности (вчерашний).
При этом необходимо, что бы в отчёте трёхдневной давности, наименование той самой фирмы, было именно таким каким оно было три дня назад, и соотв. для отчётов двухдненой и однодневной давности.

>VID © (02.11.04 19:58) [11]
>Берём интервал в три дня.

Насчет архивов msguns полностью прав, единственное, это то что такой архив разумно делать при глобальных изменениях. Так, например, при смене плана счетов мы так и делаем, слишком много настроек на него завязано. А вот для решения проблемы сменных реквизитов я знаю только одно решение - дополнительная таблица. То есть в одной хранятся организации, в другой товары, а в третьей их связь в рамках конкретной операции - когда, кому, чего, сколько, по какой цене, все необходимые реквизиты свои и покупателя, актуальные на данный момент. Смена названия организации - это конечно редкость. А вот адрес может меняться часто, а то и быть несколько. То же самое со счетами и банками. На все это ID не напасешся, да и может вполне быть, что все сменные пеквизиты заполнены заранее и просто каждый раз выбираются нужные, т.е. устаревших данных просто нет, но они каждый раз разные. И выборки по такой таблице делать - одно удовольствие.

Сергей Суровцев © (02.11.04 22:35) [12]
Я тоже ничего против архивов не имею, архивация баз данных это вообще хорошо, но вот в вышеописанной проблеме (нулевой пост) с этими архивами просто задолбаешься. Всякой методике своё место.

>VID © (02.11.04 22:45) [13]
>Всякой методике своё место.

По этому я и привел ту, которой сам пользуюсь. За много лет ни разу не подводила.

Сергей Суровцев © (02.11.04 22:35) [12]
На все это ID не напасешся
Да, кстати, вопреки стандартному мышлению, ID можно начинать считать не с нуля, а с -Min(Integer) до +Max(Integer) ;) И тогда ID становиться ровно вдвое больше :)

Общий вопрос о создании БД Найти похожие ветки