справочная таблица

Добрый день. Подскажите как лучше быть в такой ситуации. Имеются справочная таблица с сотрудниками и основная, типа журнала. В журнале хранится инфа и сотрудники определяются по их id из справочной таблицы. Как быть в такой ситуации, когда сотруднику необходимо будет, например, сменить фамилию или отдел, но в журнале изменений не должно происходить?

0

Ну так если Id сотрудника не изменится, с какой стати будет изменение в журнале?
А для сохранения истории (скажем, изменение атрибутов сотрудника, например, фамилии) обычно заводится отдельная историческая таблица, куда при изменении атрибутов заносится предыдущая версия записи (например, с пом. триггера).

PS
Вопрос по общей теории БД (или проектированию БД) и к Delphi никакого отношения не имеет

0

я имею ввиду фамилия сотрудника в журнале не должна меняться (при смене фамилии в справочнике).

0

Сообщение от Evgueny я имею ввиду фамилия сотрудника в журнале не должна меняться (при смене фамилии в справочнике).

Так...
Тогда я не понял, что такое журнал, и зачем там дублируется фамилия, которая уже есть в справочнике

0

Если не ошибаюсь, автор уже подымал тему по структуре БД. И опять-же, если я не ошибаюсь, то там уже говорилось, что приведенную автором структуру надо переделывать т.к. она нерабочая.

0

https://www.cyberforum.ru/delp... 72009.html
может помочь кто-нибуть по этой теме?

0

Кому нужна старая фамилия ?

Добавлено через 1 минуту
Отдел, кстати, тут вообще никаким боком не стоит ибо принадлжность сотрудника к подразделению должна храниться вовсе не в справочнике сотрудников, а в штатном расписании к примеру

0

Сообщение от MsGuns Кому нужна старая фамилия ?

Иногда нужна! Напрмер, если это фамилия судьи и дело рассмотривала судья Пертова, то при смене фамилии на Тяпкина-Ляпкина в информации о деле должна быть старая фамилия.

0

Сообщение от Grossmeister Так... Тогда я не понял, что такое журнал, и зачем там дублируется фамилия, которая уже есть в справочнике

Не дублируется. Вот журнал:

id | id_sotr | data | info
------------------------------
1 | 18 |28.09.2011 | AABBBB
2 | 9 |14.10.2011 | CCaaaaa
3 | 4 |16.10.2011 | FFFFggg
5 | 29 |22.10.2011 | DDDDSS

Запросом в грид выводится не id сотрудника, а его фамилия. Когда она в справочнике изменится, то изменится и когда будем просматривать журнал. А мне этого не нужно. Или например если его вообще удалить из справочника, то журнал осиротеет. Ну про удаление ладно, запретим. А с изменением что делать? Или лучше не id, а сразу name сотрудника в журнал кидать? Как вообще в таких ситуациях поступают?

Сообщение от Страдалецъ Если не ошибаюсь, автор уже подымал тему по структуре БД. И опять-же, если я не ошибаюсь, то там уже говорилось, что приведенную автором структуру надо переделывать т.к. она нерабочая.

Нет. Это было давно и уже неправда.

Сообщение от MsGuns Кому нужна старая фамилия ? Добавлено через 1 минуту Отдел, кстати, тут вообще никаким боком не стоит ибо принадлжность сотрудника к подразделению должна храниться вовсе не в справочнике сотрудников, а в штатном расписании к примеру

Больше ей нет смысла где-то храниться, поэтому она хранится в этом справочнике.

Сообщение от SAMZ Иногда нужна! Напрмер, если это фамилия судьи и дело рассмотривала судья Пертова, то при смене фамилии на Тяпкина-Ляпкина в информации о деле должна быть старая фамилия.

да да, именно так.

0

Вот в деле пусть и хранится, а причем тут справочник текущих фамилий ?

1

Сообщение от Evgueny Не дублируется. Вот журнал: id | id_sotr | data | info ------------------------------ 1 | 18 |28.09.2011 | AABBBB 2 | 9 |14.10.2011 | CCaaaaa 3 | 4 |16.10.2011 | FFFFggg 5 | 29 |22.10.2011 | DDDDSS Запросом в грид выводится не id сотрудника, а его фамилия. Когда она в справочнике изменится, то изменится и когда будем просматривать журнал. А мне этого не нужно. Или например если его вообще удалить из справочника, то журнал осиротеет. Ну про удаление ладно, запретим. А с изменением что делать? Или лучше не id, а сразу name сотрудника в журнал кидать? Как вообще в таких ситуациях поступают?

Я уже сказал. Есть историческая таблица, где указано bdate, edate, Fio. Хранить ли там и текущую ФИО - можно по разному, как удобнее. При выборке ты указываешь не только ссылку на Id, но и дату, за которую делается выборка. Соответственно, за любую дату ты можешь выбрать ту ФИО, которая была актуальна на тот момент. Если тебе трудно это соорудить в одном SQL, можно написать функцию для выборки ФИО на указанную дату.
А удаление - однозначно запретить, иначе получишь так называемые висящие ссылки

1

т.е. мне нужно создать доп. таблицу, в которую будут записываться значения из справочника, после события редактирования так? А из какой тогда таблицы делать выборку для журнала?
Как же всё-таки оптимальнее будет, записывать в журнал сразу фамилию или же id, но с созданием таблицы истории?

0

Сообщение от MsGuns Вот в деле пусть и хранится

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

1

Сообщение от SAMZ Тут тоже может быть много вариантов решений. Можно хранить историю смен фамилий с датами изменений. Можно в таблице дела вместе с кодом судьи хранить актуальную на момент рассмотрения дела фамилию. То есть, проблема (если это можно назвать проблемой) решается тривиально. Разработчику просто - напросто нужно слегка наморщить мозг и остановиться на определенном варианте.

Просто я никак не мог решиться, как лучше сделать, чтоб потом не пришлось многое переделывать. Да и чтоб сейчас не нужно было сильно переделывать. А сколько примеров пересматривал, на подобное не натыкался. Думаю, ну как же поступают в таких случаях? Не хочется грабли собирать.

Спасибо большое всем за советы.

0

Не зная предметной области и не имея понятия о Вашей модели БД, никто Вам тут ничего конкретного не подскажет, а вот просто совет дат смогут и уже давали. Я просто добавлю из собственного опыта.
В предметных областях существует несколько способов идентификации людей:
- по некоторому реально существующему внутреннему номеру (Например, табельному номеру),
- по суррогатному номеру (уник.идентификатору)
- по некоторому реально существующему внешнему номеру (Например, инд.налоговому номеру ИНН),
- по совокупности реальных сущностных реквизитов: Фимилия, Имя, Отчество, год рождения, место рождения и т.д.
Ни один из перечисленных способов не является абсолютно лучшим, каждый имеет недостатки и достоинства. Выбор поэтому зависит от конкретной предметной области.

Если решаемая задача из области "глобальных", т.е. нет и не может быть единого хранилища всех данных, т.е. данные собираются по мере надобности с разных мест (сетей, баз данных, ПК и т.д.) для получения некоторой сводной аналитичесчкой информации (по типу OLAP например), то конечно, лучше для идентификации следует выбирать реально существующий внешний номер.
Если данные в одном месте и их целостность обеспечивается аппаратно-программными средствами (например СУБД), то часто подходит один из "внутренних" вариантов.

Это "человеческий" аспект.

Далее. В любой уважающей себя БД есть средства отслеживания изменений в БД, как в части метаданных, так и в части информации. Чаще всего скл-сервера используют для этого технологию журнального типа, куда автоматически заносят ЛЮБЫЕ изменения, вносимые в БД. А если таких средств нет (например в интербэйзе, ЕМНИП), то проектировщик "базовик" может таки заставить сервер выполнять подобную работу, создав "ручками" соотв. таблицы-журналы и задействовав триггеры или другие подручные тулзы.
В принципе можно, имея такие журналы, вытащить на свет божий все изменения в любых таблицах и обработав их таким оразом, чтобы предоставить пользователю некоторый доп.сервис, приложив, конечно некоторые усилия (иногда неимоверные, например в мсскл)
А можно самому спроектировать собственную схему журналирования, куда более экоиномную, прозрачную и "годную к употреблению" нежели "лог" скл сервера. Но это, естественно, приведет к "накладным" (т.е. непосредственно не относящимся собственно к решениею поставленной задачи и, след-но, не финансируемым) расходам мозгов и рук, зачастую весьма немалым.

И, наконец, последний аспект - резервные копии. Все нормальные базы данных периодически сохраняются в архивах (бэкапах), а также очищаются от устаревшей информации (переодичность "чисток" определяется требованиям в временнОму диапазону актуальности данных и может варьировать от суток (системы видеонаблюдения, тест-регулировочные программы), до нескольких лет (системы управления предприятием, логистика, торговля..) и даже десятилетий (архивное дело). Имея архивы можно поиметь (написать, заказать профи) и систему поиска в архивах нужной информации. Либо же просто методом последовательного восстановления (Restore) и просмотра старых данных с поиском интересующий инф-ции.

Резюмируя все вышенаписанное, делайте выводы и определяйте способ решения - хранение изменений как сущностей реальных объектов, журналирование либо работа с архивами БД.
Либо их комбинацию

1

спасибо. Очень полезная инфа.

0