Как грамотно организовать БД в данном случае?

3 таблицы: деревья, вредители, источники

+2 таблицы связей: вредитель-дерево, источник-вредитель-дерево. Здесь только id-шники элементов.

Ну-у-у, у каждого дерева несколько вредителей, у вредителей по несколько источников. Следовательно, нужны связи:

Дерево - вредитель

Вредитель - источник

БД:

Таблица1: деревья

Таблица2: вредители

Таблица3: источники

Таблица4: связь дерево-вредитель

Таблица5: связь вредитель-источник

x-mobi.ru добавил 30.03.2009 в 02:11

А зачем тут "дерево"? Помоему лишнее

x-mobi.ru добавил 30.03.2009 в 02:21

Asar, на будущее запомните, если у вас в БД планируется хранение двух типов объектов, при этом, первый может включать в себя несколько вторых, то - все, однозначно нужна таблица связей :)

Для каждого дерева источник вредителей может быть разным, поэтому добавил его в таблицу. Прото подумал, что есть книга о берёзах, там рассказывается об ужасном лиственном вредителе. И есть книга о липах, там тоже о нём рассказывается, но применительно уже к липам. Могут быть разные способы заражения, симптомы и лечение.

Asar, в таблицах связей не забудьте сделать уникальный составной индекс по всем полям.

Быдлокодеры понабежали.

Словосочетание Foreign Key вам о чем нибудь говорит?

В данном случае если для каждого дерева может быть несколько вредителей, а каждый вредитель может быть только у одного дерева, т.е. имеет место связь many-to-one, то достаточно в таблице вредителей сделать ключик tree_id с отсылкой на таблицу пород дерева.

Поскольку вряд ли один вредитель вредит одному дереву, но при этом для каждой породы дерева свой источник о каждом вредителе (связь many-to-many-by-one), то три таблицы - деревья, источники и вредители, в таблице вредители два внешних ключа на таблицу пород и таблицу источников, при этом имя вредителя и прочая связанная информация может дублироваться, но группа (имя вредителя, ид источника, ид породы) будет уникальная, можно прям constraint явно указать. Итого 3 таблицы в любом случае.

Ну а если связь many-to-many, то конечно нужна доп. таблица

neolord, а тут как бэ и говорится о том, что связи везде "многие ко многим".

тут как бэ и отвечается сразу, что нифига не многие-ко-многим...

Есть деревья, есть вредители, есть источники информации. Один вредитель может быть у нескольких деревьев - это вроде логично. Об одном вредителе могут написать несколько источников для каждого дерева свой - это я вроде объяснил ранее. У дерева может быть несколько вредителей, вроде тоже вполне логично. Отсюда получаем связи:

Деревья-вредители: многие ко многим, т.к. у дерева много вредителей, вредитель жрёт несколько деревьев.

Вредители-источники: многие ко многим, т.к. об одном вредителе написано может быть несколько источников для каждого дерева свой. Один источник может описать несколько вредителей.

Да, связь будет множественная, в том и сложность. Т.е. могут быть совершенно разные сочетания дерево/вредитель/источник...

Спасибо всем ответившим, пойду пробовать/разбираться...

Читайте внимательнее:

Т.е. один вредитель также может несколько деревьев жрать, ну и у деврева несколько врежителей. Классический случай связи многие ко многим.