Организация таблицы с перекрестными ссылками, как?

[EvilsInterrupt]

День добрый!

Возникла такая ситуация, когда мне надо книгу от нести по 2 или более тематикам, к примеру книга "Внутреннее устройство Windows" от М.Руссиновича может быть отнесена к тематикам: "Разработка драйверов", "Операционные системы", "Администрирования" и еще бог весть куда, куда пользователь захотел.
Но поиск по ключевому слову "перекрестные" не на форуме, не на сайте ничего не выдал, а поиск в ya.ru такое выдал, что мне ребенку с неокрепшим мозгом такое читать вредно

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

Удачи вам

[avenger]

Возникла такая ситуация, когда мне надо книгу от нести по 2 или более тематикам, к примеру книга "Внутреннее устройство Windows" от М.Руссиновича может быть отнесена к тематикам: "Разработка драйверов", "Операционные системы", "Администрирования" и еще бог весть куда, куда пользователь захотел.

Ну так и в чем проблема? Это обычная связь многие-к-многим. Делается через промежуточную таблицу.
Books(ID: Integer); Tematiks(ID: Integer)

Таблица связей:

Код: Выделить всё

СвязьКнигСТематиками(
  BookFK: Integer,
  TematikFK: Integer,
  ...
)

PrimaryKey=(BookFK, TematikFK)
ForeignKey1=(BookFK на таблицу Books)
ForeignKey2=(TematikFK на таблицу Tematiks)

[EvilsInterrupt]

Получается не много-ко-много, а один-ко-много. Т.к. одна книга и много тематик.

вот у мну есть:

Код: Выделить всё

CREATE TABLE EBook (
       ID Integer NOT NULL,
       Name Varchar(50) NOT NULL,

...
и:

Код: Выделить всё

CREATE TABLE Subject (
       ID Integer NOT NULL,
       Parrent_FK Integer NOT NULL,
       Value_ Varchar(15) NOT NULL,
       CONSTRAINT PK_Subject PRIMARY KEY (ID)
);

ALTER TABLE Subject ADD CONSTRAINT Subject_FK FOREIGN KEY (Parrent_FK) REFERENCES Subject(ID) ON UPDATE CASCADE ON DELETE CASCADE;

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

[avenger]

Получается не много-ко-много, а один-ко-много. Т.к. одна книга и много тематик.

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

В любом случае, делай через промежуточную таблицу. Структуру привел выше постом.

[CyberMax]

Получается не много-ко-много, а один-ко-много. Т.к. одна книга и много тематик.

Один-ко-многим - это частный случай случай много-ко-многим .
Так что тебе правильно сказали.

[EvilsInterrupt]

Придется ждать полнолуния, мозг отказывается думать.

[hvlad]

Получается не много-ко-много, а один-ко-много. Т.к. одна книга и много тематик.

И каждой тематике соответствует множество книг

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

В чём проблемы ?
Связь M:N между книгами и тематиками никаким образом не касается внутреннее устройство тематик (дерево, куст, окоп и т.п.) - главное чтобы было на что ссылаться (PK)

[EvilsInterrupt]

Вчера фаза луны была подходящей и в аську вышел очень хороший человек и дал пинка в нужном направлении. Спасибо тем, кто дал мне понимание этой техники!

Проблема решана

[kdv]

А Parrent - это, очевидно, смесь между parent и parrot ?

[WildSery]

Нет, это Parrent -> Par Rent -> Parent Rent (а может Param Rent)