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) Есть такие интерфейсы, но я предпочитаю чтобы тимлид или пм сами выбирали решения. Как в анекдоте "не грузите меня я стратегией занимаюсь" ))

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