Структура БД. II

← →
картман © (2009-07-22 12:27) [0]

Древовидная структура должна выглядеть следующим образом:

1 Авиация basic
2 Внуково basic
3 Аварии basic
4 Персоны subsidiary
5 Путин subsidiary
5 Горбачев subsidiary
.....
4 Организации subsidiary
.....
4 Должности subsidiary
......
3 Приобретения
....
2 Домодедово basic
......
1 Металлургическая промышленность basic
......

табличка:
id int | parent int | title nvarchar(123) | type_threme

вложенность тем type_threme = basic может быть любой.

вот этот блок примерно постоянный(type_threme):
4 Персоны
5 Путин
5 Горбачев
.....
4 Организации
.....
4 Должности
т.е. тут могут присутствовать, но не обязательно, Персоны, Организации и т.п., в них, в свою очередь, могут быть наборы объектов: Путин, Горбачев...

Любая тема basic может быть родительской как для basic, так и для subsidiary.

Очевидно, что элементы типа subsidiary будут повторяться раз от раза. Хранить их в этой же таблице - вроде, не совсем верно. Хранить в отдельной - как?

← →
test © (2009-07-22 12:32) [1]

ИМХО
А как ты собираешся хранить в одной таблице и поле фамелии, должности и доп инфу? Лучше разнести по типам, на крайний вариант справочник привяязать по типам хранимой информации.

← →
sniknik © (2009-07-22 12:34) [2]

> Хранить в отдельной - как?
как обычно, ссылкой на таблицу значений.

кстати так хранить можно все, дерево будет содержать только свою структуру и ссылку.

p.s. у меня вопрос, ты с базами что вообще не работал? книжку хоть какую нибудь почитай...

← →
картман © (2009-07-22 12:42) [3]

> test © (22.07.09 12:32) [1]

> Лучше разнести по типам, на крайний вариант справочник привяязать
> по типам хранимой информации.

Запрос на что будет похож?
Как дерево строить? Как разграничить id и parent из справочников для каждой основной темы?

пока писал, нашел тип bigint... id справочников стартовать с разных значений, с большим интервалом- как такой вариант? Или есть по симпотишнее?

← →
картман © (2009-07-22 12:44) [4]

> sniknik © (22.07.09 12:34) [2]

это все нужно отображать в одном дереве

← →
Ega23 © (2009-07-22 12:47) [5]

> Как дерево строить? Как разграничить id и parent из справочников
> для каждой основной темы?

id, parentid, вторичный ключ на таблицу с доп. информацией.

← →
sniknik © (2009-07-22 12:52) [6]

> как такой вариант?
идиотский...

если уж решил делать справочники в разных таблицах, то ссылка на них должна состоять из 2-х значений - тип записи (по которому можно будет определить таблицу) и собственно id записи в справочнике.

но лучше бы конечно свести все в один справочник, пусть там поля разные заполняются (кроме базовых типа "наименование"), но один.

> Запрос на что будет похож?
на Ж..., и чем дальше тем больше.

> это все нужно отображать в одном дереве
и что? объединения это тоже базовые знания баз... еще раз совет - почитай книжку по основам.

← →
картман © (2009-07-22 13:00) [7]

> sniknik © (22.07.09 12:52) [6]

> > это все нужно отображать в одном дереве
> и что? объединения это тоже базовые знания баз... еще раз
> совет - почитай книжку по основам.

ну может я и не знаю базовых основ, но понимаю, что, фактически, нужно будет формировать ветви дерева из справочника(-ков), а посему, как быть с id и parent цепляемых веток?

← →
PEAKTOP © (2009-07-22 13:16) [8]

> как быть с id и parent цепляемых веток

Такое уже давно реализовано в бухучете. Называется справочник "План счетов", древовидный, в котором есть дополнительное поле "субконто": имя таблицы справочника субконто. Вопрос в том, что не во всех СУБД возможно получение выборки из такого справочника одним запросом.

Конкретно в твоем случае я бы сделал так:

CREATE TABLE TREE ( ID INTEGER NOT NULL -- код элемента ,PARENT_ID INTEGER -- код родителя ,REF_NAME VARCHAR(50) -- имя справочника, откуда брать элемент ,REF_ID INTEGER -- код элемента во внешнем справочнике ); ALTER TABLE TREE ADD CONSTRAINT C_PK$TREE_ID PRIMARY KEY (ID) USING INDEX INDX$TREE_ID; ALTER TABLE TREE ADD CONSTRAINT C_FK$TREE_PARENT_ID FOREIGN KEY (PARENT_ID) REFERENCES TREE (ID) ON UPDATE CASCADE ON DELETE CASCADE USING INDEX INDX$TREE_PARENT_ID; CREATE ASCENDING INDEX INDX$TREE_REF_ID ON TREE (REF_ID);

что значит как быть? в этом смысле (id и parent) твое "ноу хау по структуре" ничем не отличается от классического дерева которое разбирают в первой же главе о деревьях...
все отличие от классики в том, что данные дерева хранить не в самом дереве, а в справочнике, собирается все вместе простым запросом с объединением, что тоже одна из первых вещей о чем пишут в книгах.

вся проблема у тебя не в том, что структура какая то "особо хитрая", нет, она простая, соединенные вместе 2 основы, которые ты не понимаешь...
но почему то делаешь выводы, от том что надо, что то "хитрое" чтобы с эти работать.... ???

p.s. решить твою проблему по тому "как быть" невозможно, т.к. проблемы то в этом нет, есть только твое непонимание, а непонимание не решается хитрыми наворотами над простой структурой по чужим советам, оно решается изучением основ, искоренением "корня" непонимания.

> есть только твое непонимание, а непонимание не решается
> хитрыми наворотами над простой структурой по чужим советам,
> оно решается изучением основ, искоренением "корня" непонимания

Во загнул !
Забористая у вас трава... :)))

> картман (22.07.2009 12:27:00) [0]

Хватит и одной ветки.

Структура БД. II Найти похожие ветки