http://sql.ru/forum/actualthread.aspx?tid=145484%5D%7C>]http://sql.ru/forum/actualthread.aspx?tid=145484]|>
http://sql.ru/forum/actualthread.aspx?tid=145484 " TARGET="_blank">читал, читал
пришел к выводу , что потом разъединять будет проще чем объединять
к тому же нет четкого критерия оптимальности
поэтому решил пойти экстремальным путем: сделать ОДИН справочник объектов
(база небольшая можно поэкспериментировать)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE TABLE [dbo].[Obj_spr] (
[ID] [int] IDENTITY ( 1 , 1 ) NOT NULL ,
[Name] [varchar] ( 30 ) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[Obj_Type_ID] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Obj_spr] WITH NOCHECK ADD
CONSTRAINT [PK__KA_spr__12D47FD7] PRIMARY KEY CLUSTERED
(
[ID]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Obj_spr] ADD
CONSTRAINT [DF_Obj_spr_Obj_Type_ID] DEFAULT ( 1 ) FOR [Obj_Type_ID]
GO
CREATE INDEX [IX_Obj_spr] ON [dbo].[Obj_spr]([Name]) ON [PRIMARY]
GO
в связи с этим появилась дилемма: как организовать связь между объектами.
самое простое и отработанное - дерево
как правило , любой объект в справочнике снабжают аналитическими признаками
кот. потом используют в отчетах для агрегации результатов
действия фактов хоз деятельности на объекты учета
Возьмем Товары
Они, как правило, разделены на группы
например Щебень->ЩебеньГранитный->Щебень гранитный фр.5-20
в обычном справочнике можно завести доп поля Группа1,Группа2... по числу уровней иерархии
Просто, но грубо и ограниченно (к тому же громоздко, если наберется большое кол-во уровней)
Делаем дерево.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CREATE TABLE [dbo].[Obj_Schema] (
[ChildID] [int] NOT NULL ,
[ParentID] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Obj_Schema] WITH NOCHECK ADD
CONSTRAINT [PK_Obj_Schema] PRIMARY KEY CLUSTERED
(
[ChildID]
) ON [PRIMARY]
GO
CREATE INDEX [IX_Obj_Schema] ON [dbo].[Obj_Schema]([ParentID]) ON [PRIMARY]
GO
ID , Name
1 Щебень
2 ЩебеньГранитный
3 Щебень гранитный фр.5-20
ChildID, ParentID
1,1
2,1
3,2
(Тут сразу небольшой вопрос:
Для узлов у которых нет предка указывать в схеме предка NULL или самого себя?)
Добавим еще один признак Товар(то что продают) и сырье(то что используют в производстве)
ID , Name
4 Сырье
5 Товары
Все нормально пока товар не попал сразу в обе категории (аналогично Контрагент -> Клиент и Поставщик)
Можно сделать дубль товара , а в расширенных признаках сделать ссылку мол это один и тот же чувак
(как в выше указанном топике Клиент и Поставщик имели ссылки друг на друга)
Сохранив таким образом «деревянную простоту и однозначную идентификацию ветки по младшему предку при агрегации.
Можно представить как граф , но при этом хранить его как N деревьев (лес)
причем деревьев много но состоят они из одних и тех же листьев
только листья эти могут сидеть на разных ветках (или вообще отсутствовать)
Чуток замучено , зато никаких внешних свойств
А можно отказаться от дерева и сделать полноценный граф
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
CREATE TABLE [dbo].[Obj_Schema] (
[ChildID] [int] NOT NULL ,
[ParentID] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Obj_Schema] WITH NOCHECK ADD
CONSTRAINT [PK_Obj_Schema] PRIMARY KEY CLUSTERED
(
[ChildID],
[ParentID]
) ON [PRIMARY]
GO
CREATE INDEX [IX_Obj_Schema] ON [dbo].[Obj_Schema]([ParentID]) ON [PRIMARY]
GO
CREATE INDEX [IX_Obj_Schema_1] ON [dbo].[Obj_Schema]([ChildID]) ON [PRIMARY]
GO
Один и тот же узел сможет получить нескольких предков
Только для агрегации теперь придется использовать полное сетевое имя предка
Чтобы не захватить соседние ветки, отчего запросы станут значительно тяжелее.
К тому же визуальное отображение подобной структуры в TreeView не очень наглядно
(некоторые узлы просто попадут сразу в несколько веток)
Сделав кальку дерево->лес для графа (не знаю как назвать объемный граф чтоли)
Можно получать дополнительные возможности
Например, используя то, что узлы могут исчезать в другом измерении
Получать какие-то упрощенные схемы и срезы только по товарам или только по контрагентам и т.п.
PS Теоретически вроде возможно, но чувствую широковато замахнулся.
Мож как то осадите практическими соображениями?
