Нужна разумная идея

← →
PVOzerski (2003-03-06 10:38) [0]

Взялись мы тут маленькой командой делать сайт природоохранно-просветительского плана, и будет там на сервере жить база данных... Сервер, ясно, линуксовый, так что BDE там не будет. Но в идеале система должна получиться кросс-платформенной, т.е. предусматривается создание и Win32-варианта. Возможно, какую-то часть ПО придется делать мне, и скорее всего я выберу FreePascal как средство разработки.
Сейчас я размышляю, как хранить для записи (вид животного)
информацию о его приуроченности к определенным типам экосистем.
Дело в том, что эта информация, с одной стороны, имеет определенную иерархическую организацию, типа:
1 Лес
1.1 Хвойный лес
1.1.1 Еловый лес
1.1.1.1 ....
....
1.1.2
...
1.2
...
2
...
,
причем, желательно, чтобы пользователь мог пользоваться этой иерархией при поиске, например, выбрать виды, водящиеся во всех лесах, или только в хвойных, или только в еловых.
С другой же стороны, сама приуроченность вида животного вовсе не подчиняется этой иерархии, т.е., скажем, для него могут подходить 1.1.1.1.1 и 2.2.2.2.2, но не подходить 1.2.....
Так что придется либо тупо перечислять для каждого вида список допустимых сочетаний индексов, что, IMHO, заведомо замедлит поиск, так как не позволит пользоваться иерархичностью, либо как-то мудрить с жуткими разветвлениями иерархических структур. И при этом очень хотелось бы избежать полей переменной длины, хотя вряд ли это возможно.

Нет ли каких-то общепринятых путей решения подобных задач? И не знает ли кто freewar"ные решения (библиотеки, серверные программы), здесь приемлемые?

Понятно, что жесткой привязки к формату хранения данных пока нет.

← →
Max Zyuzin (2003-03-06 10:51) [1]

Кроме тупого хранения индексов экосистем у каждого вида в голову ничего не лезет...
Возможно не очень умная мылся... но может ускорить поиск...
В структуре экосистем так же хранить списки видов там обитающих... конечно будет много проблем с целостностью и забываем о нормализации... но поиск будет идти быстро в обе стороны...

← →
passm (2003-03-06 10:55) [2]

Иерархически хранить леса. Можно так же хранить представителей животного мира - тоже есть своя классификация. И таблицу соответствий:
ЛЕС_ИД, ЖИВОТНОЕ_ИД, АКТУАЛ(Признак обитает/не обитает)
Соотв. можно прописать, что какой-нибудь зверь обитает во всех лесах хвойного типа, кроме...
Но это на первый взгляд.

← →
Johnmen (2003-03-06 10:59) [3]

Я так понял, что это связь Многие-ко-Многим.
Стандартная реализация - через дополнительную таблицу...

← →
Delirium (2003-03-06 11:51) [4]

Согласен с Johnmen, обыкновенная высоконормальная схема справочников и кроссов, никакими "лесами" тут и не пахнет.

← →
Delirium (2003-03-06 12:28) [5]

Любая иерархия ("леса" и "деревья") эффективны при наличии ОДНОЗНАЧНОЙ зависимости и действительно МНОГОУРОВНЕВОЙ номенклатуры. На практике такое встречается лишь в искусственных областях деятельности - машиностроении например. В области-же PVOzerski, мне представляется нормальным наличие ситуаций когда элемент является членом более чем одной группы одного уровня. Т.е. какое-либо растение может принадлежать как к группе "Хвойный
лес" так и "Лиственный лес". Следовательно - однонаправленное дерево никак не получится, а если начать пытаться строить сеть, то при наличии множества вышеописанных ситуаций, эффективность такой схемы будет стремиться к нулю. В схеме-же многие ко многим имеем -
справочники:

типы леса (ForestType)
*id_ForestType, c_ForestType
1 Хвойный
2 Лиственный

растения (Plant)
*id_Plant, c_Plant
1 Нечто1
2 Нечто2

и кросс (ForestType_ForestType)
*(id_ForestType, id_Plant)
1 1
1 2
2 2

где * - ключи

Вот и всё, нормальность - выше некуда, избыточность на нуле, и никаких проблем с целостностью.

← →
passm (2003-03-06 12:38) [6]

Delirium © (06.03.03 12:28)> Верно, но непонятно почему тебе не нравится справочник лесов в виде иерархии.

← →
Delirium (2003-03-06 12:42) [7]

Мне не нравится сети, а не деревья. А именно к этому придёт любое дерево с нечёткой зависимостю.

← →
Delirium (2003-03-06 12:48) [8]

Точнее, я допускаю существование деревьев вида (id, idParent), но не допускаю (id, idParent, idParent2, idParent3 ...) или
(id, idParent, iLevel) - и то и другое не укладывается в моём понимании нормальности, а значит - порочно. Разумеется это IMHO основанное на личном опыте.

← →
passm (2003-03-06 12:50) [9]

← →
Delirium (2003-03-06 13:16) [10]

> PVOzerski © (06.03.03 10:38)

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

Ваше IMHO - не верно, если Вы будете придерживаться пары простых правил.
Во первых: в спавочниках не должно быть составных ключей (для этого существуют таблицы оперативных данных).

Во вторых: кроссы служат для объединения только 2-х таблиц, причём оба ключа в единый кластерный индекс.

Вот и всё - уверяю, при таком подходе миллионные таблицы у Вас будут просто "летать".

← →
guest (2003-03-06 15:03) [11]

Delirium совершенно правильно заметил. (асколькоя я понимаю в биологии)
И еще, коллеги не очень увлекайтесь с индексами, словарями и кластерными индексами
сказано же - база будет работать под виндами и под юниксом. Соответственно, там она скорее всего либо превратится в базу MySQL или PostgreSQL, и т.д., или к ней будет доступ через какие-нибудь модули Perl, или классы PHP (и то, и другое без SQL сервера обычно работает в усеченном издании), либо это будет плоская база

← →
Delirium (2003-03-06 15:13) [12]

Дело ведь не в "движке" БД, а лишь в грамотном проектировании. Иначе говоря, не надо допускать грубых ошибок только потому, что БД будет работать не под Oracle, а под MySQL. Думается, что дело обстоит как раз наоборот - чем проще (примитивние) "движек", тем серьёзнее надо подходить вопросам проектирования и оптимизации.

Нужна разумная идея Найти похожие ветки