| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Нужна разумная идея
PVOzerski © (2003-03-06 10:38:00)Взялись мы тут маленькой командой делать сайт природоохранно-просветительского плана, и будет там на сервере жить база данных... Сервер, ясно, линуксовый, так что 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"ные решения (библиотеки, серверные программы), здесь приемлемые?
Понятно, что жесткой привязки к формату хранения данных пока нет.
Delirium (2003-03-06 15:13:00) [1]Дело ведь не в "движке" БД, а лишь в грамотном проектировании. Иначе говоря, не надо допускать грубых ошибок только потому, что БД будет работать не под Oracle, а под MySQL. Думается, что дело обстоит как раз наоборот - чем проще (примитивние) "движек", тем серьёзнее надо подходить вопросам проектирования и оптимизации.
guest (2003-03-06 15:03:00) [2]Delirium совершенно правильно заметил. (асколькоя я понимаю в биологии)
И еще, коллеги не очень увлекайтесь с индексами, словарями и кластерными индексами
сказано же - база будет работать под виндами и под юниксом. Соответственно, там она скорее всего либо превратится в базу MySQL или PostgreSQL, и т.д., или к ней будет доступ через какие-нибудь модули Perl, или классы PHP (и то, и другое без SQL сервера обычно работает в усеченном издании), либо это будет плоская база
Delirium (2003-03-06 13:16:00) [3]> PVOzerski © (06.03.03 10:38)
>тупо перечислять для каждого вида список допустимых сочетаний >индексов, что, IMHO, заведомо замедлит поиск
Ваше IMHO - не верно, если Вы будете придерживаться пары простых правил.
Во первых: в спавочниках не должно быть составных ключей (для этого существуют таблицы оперативных данных).
Во вторых: кроссы служат для объединения только 2-х таблиц, причём оба ключа в единый кластерный индекс.
Вот и всё - уверяю, при таком подходе миллионные таблицы у Вас будут просто "летать".
passm (2003-03-06 12:50:00) [4]Delirium © (06.03.03 12:42)
> А именно к этому придёт любое дерево с нечёткой зависимостю.
Это к биологам :)
Delirium (2003-03-06 12:48:00) [5]Точнее, я допускаю существование деревьев вида (id, idParent), но не допускаю (id, idParent, idParent2, idParent3 ...) или
(id, idParent, iLevel) - и то и другое не укладывается в моём понимании нормальности, а значит - порочно. Разумеется это IMHO основанное на личном опыте.
Delirium (2003-03-06 12:42:00) [6]Мне не нравится сети, а не деревья. А именно к этому придёт любое дерево с нечёткой зависимостю.
passm (2003-03-06 12:38:00) [7]Delirium © (06.03.03 12:28)> Верно, но непонятно почему тебе не нравится справочник лесов в виде иерархии.
Delirium (2003-03-06 12:28:00) [8]Любая иерархия ("леса" и "деревья") эффективны при наличии ОДНОЗНАЧНОЙ зависимости и действительно МНОГОУРОВНЕВОЙ номенклатуры. На практике такое встречается лишь в искусственных областях деятельности - машиностроении например. В области-же 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
где * - ключи
Вот и всё, нормальность - выше некуда, избыточность на нуле, и никаких проблем с целостностью.
Delirium (2003-03-06 11:51:00) [9]Согласен с Johnmen, обыкновенная высоконормальная схема справочников и кроссов, никакими "лесами" тут и не пахнет.
Johnmen (2003-03-06 10:59:00) [10]Я так понял, что это связь Многие-ко-Многим.
Стандартная реализация - через дополнительную таблицу...
passm (2003-03-06 10:55:00) [11]Иерархически хранить леса. Можно так же хранить представителей животного мира - тоже есть своя классификация. И таблицу соответствий:
ЛЕС_ИД, ЖИВОТНОЕ_ИД, АКТУАЛ(Признак обитает/не обитает)
Соотв. можно прописать, что какой-нибудь зверь обитает во всех лесах хвойного типа, кроме...
Но это на первый взгляд.
Max Zyuzin (2003-03-06 10:51:00) [12]Кроме тупого хранения индексов экосистем у каждого вида в голову ничего не лезет...
Возможно не очень умная мылся... но может ускорить поиск...
В структуре экосистем так же хранить списки видов там обитающих... конечно будет много проблем с целостностью и забываем о нормализации... но поиск будет идти быстро в обе стороны...
| |
