Здравствуйте!
Существует некое ООО "РУСИНВЕСТСТРОЙ", директор Пупкин Петр Петрович, его заместитель Гогидзе Гоги Вахович.
Хранится в БД допустим таблица:
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 (который будет указывать на наименование, действовавшее на момент внесения данных)

MGR
3. Делаем запись о том, что первая является наследником второй. Основание - "переименование", "поглощение", "покупка долгов", "ошибка операциониста" и т.п.

для реализации данной функции можно в таблицу tblObjectNames ввести поле для описания причины наименования.


Вобщем как вам такой некий координатный подход?

gardenman
Аналогично и организации. Меняется устав - иногда меняется и название организации. При этом куча инфы остается: номера счетов, договора и прочая хренотень.... Понятно?
этот метод мне понравился, но условием его применимости является полнота получения сведений о документам, согласно которым происходят те или иные переименования. но у меня в ряде случаев такой информации нет и есть необходимость учитывать изменения по факту

в раздумьях вводить такую схему или нет. может есть у кого мнения?

Vasoydотпишусь *о* подводных камнях :)
первый подводный камень - предложенную схему проблематично использовать для процессов слияния и разделения объектов.
shelsoftЯ бы исходил из "естественных" процессов
1) Т.е. закрывал старую запись ООО "Пупкин и Ко" и открывал новую ЗАО "Пупкин и Ко"
2) И ввел бы таблицу кросс-связей между организациями с типами связи. Одним из типов связей было бы "правоприемник". В т. ч. таким образом решилась бы и задача объединения и разделения организаций.
подумаю над этим. вариант на вскидку очень даже понравился.
Senya_Lhttp://martinfowler.com/ap2/timeNarrative.html
спасибо за ссылку. читаю.

Senya_Lhttp://martinfowler.com/ap2/timeNarrative.html
это ж вроде больше как относится к ОО подходу? или как?

Senya_L Vasssoid Senya_Lhttp://martinfowler.com/ap2/timeNarrative.html
это ж вроде больше как относится к ОО подходу? или как? Да, как-то относиться к ОО. Как, впрочем, и все творчество мистера Фаулера :)
Если тема еще актуальна, могу посоветовать ссылку более близкую к жизни, просто тогда найти не мог, у меня сохранена страничка локально.
премного благодарен )) это хороший материал.однако ж немного по другой теме

MGRЯ бы предложил бы по другому.
Оставить старую табличку org_tbl в неприкосновенности, добавив только статус
параллельно ей вести табличку переименований (слияний, дроблений).
Ну и, соответственно, ввести операцию "смена кастомера" например, когда все задолженности с ООО "РУСИНВЕСТСТРОЙ" необходимо перевести на ООО "ИНВЕСТСТРОЙ-М".

Таким образом переименование происходит следующим образом:
1. Создаём запись о ООО "ИНВЕСТСТРОЙ-М".
2. Делаем ООО "РУСИНВЕСТСТРОЙ" неактивным
3. Делаем запись о том, что первая является наследником второй. Основание - "переименование", "поглощение", "покупка долгов", "ошибка операциониста" и т.п.
4. Переводим задолженность.
5. Работаем с новой компанией.
6. В отчётах можно анализировать дату и писать сноску "ранее известный как Принц" и т.п.

Пункты 2-4 можно объединить в одну операцию.
shelsoftЯ бы исходил из "естественных" процессов
1) Т.е. закрывал старую запись ООО "Пупкин и Ко" и открывал новую ЗАО "Пупкин и Ко"
2) И ввел бы таблицу кросс-связей между организациями с типами связи. Одним из типов связей было бы "правоприемник". В т. ч. таким образом решилась бы и задача объединения и разделения организаций.

Вот эти два сообщения а также описание работы 1С, в которой нельзя обращаться напрямую к таблицам
одтолкнули к следующему решению).
1) объекты характеризуются и идентифицируются полным набором своих параметров. координатный подход не покатил (т.е. даже если буква в название добавляется - это уже новый объект, с новыми свойствами)

^{___________________________
здесь и далее объект - это организационное подразделение - ООО, ОАО, ЗАО, департамент, отдел и прочее}

2) все объекты хранятся в одной таблице.
3) связи между объектами хранятся в таблице вида

4) виды связей
авторОдним из типов связей было бы "правоприемник". В т. ч. таким образом решилась бы и задача объединения и разделения организаций.
также виды связей - выведен из состава, введен в состав, расформирован, организован и т.д.

5) ВСЕ действия по изменению объектов, ТОЛЬКО через соответствующие формы. Типа выбрал из списка Объект1 выбираешь действие (переименовать, перевести в подчинение другому объекту), выходит соответствующий диалог и все. остальное берет на себя логика.

^{___________________________________
сейчас реализую данную схему на Access, потому всю логику загоняю в форму. а так наверное триггеры и хранимые процедуры рулят}
ИТОГИ:
+ все изменения объектов делаются только через заранее определенные интерфейсы
+ вероятность внести чего-то не так крайне малы. (О! необходима кнопка - "исправить"ж) )
+ все необходимые действия при изменении, создании, уничтожении объектов (перевести сотрудников в новый департамент, уволить сотрудников, и прочее прочее) будут производится логикой приложения


- необходимо четко формализовать все связи
- все формализованные связи необходимо учитывать в логике приложения
=> сложность логики.


+/- стороннему человеку в таблицах и логике без бутылки не разобраться

_______________________
написал и понял, что это все отражение принципа: Чем проще идея, тем сложнее ее техническая реализация

интересно было бы услышать мнения

shelsoft1) А дата/время где ?

дата время изменений? типа - дата перименования и прочее? конечно должны быть.
shelsoft2) Связи бы я ИХМО давал возможность только добавлять и отменять

хм...это как? можно поподробнее?
shelsoftПродумать интерфейс в "три щелчка"

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

shelsoft1) Думайте самостоятельно и критично в чем я был возможно не прав поскольку не знаю местных условий
2) Есть такие интерфейсы, но я предпочитаю чтобы тимлид или пм сами выбирали решения. Как в анекдоте "не грузите меня я стратегией занимаюсь" ))

Ну буду ждать тимлида Ж)