Здравствуйте!
Существует некое ООО "РУСИНВЕСТСТРОЙ", директор Пупкин Петр Петрович, его заместитель Гогидзе Гоги Вахович.
Хранится в БД допустим таблица:
org_tbl
Предположим изменяется название РУСИНВЕСТСТРОЯ на ИНВЕСТСТРОЙ-М. Пох, меняем поле org_name на ООО "ИНВЕСТСТРОЙ".
НО! Как же быть с ранее веденными данными? Получается во всех таблицах где будет хранится id_org этого инвестстроя название поменяется тоже? Как можно обеспечить хранение и старой и новой информации?
Читал про КЛАДР, там в общероссийском классификаторе эта проблема приемлемо не решена получается?
Неужели какой то разработанной методики?
мой подход пока такой:
id_org_classifier_tbl

id_org_tbl

То есть инвест строю в таблице id_org_tbl будут соответствовать 2 записи, но у недействующей флаг acts будет false. Одинаковыми у них будут id_org_class, подцепляемые из таблицы id_org_classifier_tbl. А поле acts будет использоваться для всяких выпадающих списков.

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

Программист-ЛюбительЕсть более сложное - слияние и поглощение организаций, например.
и-и-иии? существует ли какой то общий подход к этой проблеме?

gardenman
Примерно также как у людей с паспортами, когда девушка замуж выходит и берет чужую фамилию. Пофиг как ты на мониторе в гриде ее обзавешь. А паспорт как был так и будет на прежнюю фамилию пока не поменяют.
Типа понял?
не понял. на человека статистику заказов, контрактов, проектов делать в течение времени не надо. а тут понимаешь надо:
1) при создании отчетов учитывать что под разными названиями могут иметься в виду одни и те же сущности
2) при печати документов, справок за определенный период надо учитывать что на тот момент название было другим

gardenman , можно поподробнее?

Программист-Любитель , согласен, бывают и сложнее варианты, а как ты решаешь вариант с переименованием, когда нужно хранить и старое название?

ODIN.
хорошая мысль. Только вопрос по пункту 4. что значит переводим задолженность? это значит групповая обработка массива данных? если так, может изловчиться как нибудь чтобы ничего нового не рождать в документах... а заставить смотреть на другую контору... типовой запрос правда будет (и должен тогда) всегда учитывать этот момент...
как вам тогда вариант с неким классификатором организации? Например если перейти на уровень отделов, то могут быть: отдел кадров, бухгалтерия, ИТ отдел. Хранить в таблицах значения идентификатора названия и идентификатора класса подразделения. Точнее видится, что можно хранить только идентификатор названия, по которому будет цепляться идентификатор подразделения.
Что то насчет плюсов/минусов мыслей нет.

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

Программист-Любитель
Сохраняю в таблице истории изменения ключевых атрибутов организаций (не только переименования).
можешь описать структуры таблиц и то как сохраняется история изменения ключевых атрибутов?

Программист-Любитель спасибо! пошел изучать

Программист-Любитель , получается по твоей таблице поле iCustomerID необходимо для различным статистических отчетов?
То есть если было РУССТРОЙИНВЕСТ (iCustomerHistoryID=2, iCustomerID=1, iCustomParentID=Null) и оно становится СТРОЙИНВЕСТ-М, то добавляется новая запись (iCustomerHistoryID=3, iCustomerID=1 (совпадающий c iCustomerID РУССТРОЙИНВЕСТа), iCustomParentID=2 (То есть iCustomParentID РУССТРОЙИНВЕСТа)).
Так или нет?

Пришла в голову следующая мысль. Например организация с различными должностями. Директор, Зам директора, Бухгалтер и так далее. Сотрудник Иванов Иван Иванович, Петров Петр Петрович и т.д. Хранение информации об изменяющихся наименованиях аналогично задаче о хранении информации об изменении должностей сотрудников.
В общем случае получается что данная ситуация идентична связи много-много между сущностями (одна и та же должность может быть занята с течением времени разными сотрудниками, один и тот же сотрудник может занимать разные должности с течением времени; одна и та же компания может входить в состав различных холдингов с течением времени, один и тот же холдинг может включать в себя различные компании).
=> можно применить стандартный подход реализации связи многие-к-многим

таблица Должности

таблица Сотрудники

таблица СотрудникиДолжности

Аналогично можно сделать для организаций. Но тут вопрос.
Какой способ хранения данных о сотруднике принявшем, выполнившем заказ предпочтительнее?
Есть вариант хранить в БД в этих случах идентификатор записи в таблице СотрудникиДолжности. В этом случае:
+ хранится 1 поле
- если произойдет какой либо сбой и записи в таблице СотрудникиДолжности будут утеряны, то восстановить что же значил идентификатор 152 не получится

Другой вариант, хранить сотрудник_id, должность_id
- хранится будет два поля
+ большая устойчивость к сбоям

Может есть что то еще? Как решаете этот момент?

!ап
пришла в голову мысль о следующем решении.

Каждый объект (в случае структуры организаций с территориальным и департаментальным делением) можно представить в виде вектора со следующими координатами:
Объект(Организация, Департамент, Территориальное местоположение, Уровень, Родительский объект, Наименование)
Суть в том что набор координат:
(Организация, Департамент, Территориальное местоположение, Уровень)
в ряде случаев однозначно идентифицирует так скажем тип объекта.

Например (Лукойл, ИТ, г. Самара, Отдел, филиал Лукойл в г. Самара) определяет однозначно отдел ИТ обеспечения филиала Лукойл в г. Самара. Наименование же может изменяться, но сам объект остается тем же.

Для реализации этого решения необходима таблица
tblObjects
и соответственно таблица
tblObjectNames
в этом случае привязку сотрудников делать к iObjectID. При изменении наименования iObjectID в таблицу tblObjectNames добавляется новая строчка с новым наименованием и ссылкой на предыдущее название.

Для хранения же реквзитов наименования в договорах, заказ и прочее указывать два FK - iObjectID - для составления статистических отчетов и iObjectNameID (который будет указывать на наименование, действовавшее на момент внесения данных)