Xpoint
   [напомнить пароль]

Виртуальная иерархия: плюсы, минусы и оптимальное решение

Метки: [без меток]
2007-02-01 11:32:06 [обр] Top manager(0/2)[досье]
Задача выходит из требований проекта, в котором заведомо предполагается возможность динамически создавать разные уровни (и из название и прочие поля) иерархии, по таким "объектам", как: продукты, услуги, география и прочие. Речь идёт о множестве виртуальных иерархий. проблема в том, что характеристики (а соответственно и поля БД), например продуктов , отличаются от услуг, не говоря уже о географии (страны -> области - > города и сёла - > районы...)
Как быть, хотелось бы создать инструмент, не слишком сложный по структуре, максимально гибкий и что не маловажно - быстрый. Люди - поделитесь мнением, знаниями и опытом. Этот вопрос конечно не "нейронный сети" и "искуственный интеллект", но всё же не прост...
спустя 3 часа 17 минут [обр] Thirteensmay(0/157)[досье]
Таблица иерархий: 3 поля: id, type, parent. Описания однотипных объектов в отдельных таблицах.
спустя 15 часов [обр] Top manager(0/2)[досье]

Thirteensmay[досье]

Описания однотипных объектов в отдельных таблицах.

А как быть если эти объекты заранее не определены?!

Может такой вариант: таблица для хранения всех объектов, с избыточным количество полей, названия и типы которых свойственны всем свойствам, всех объектов, а в другой таблицы, указывается, какой иерархии свойственны, какие поля...

спустя 5 часов [обр] Thirteensmay(0/157)[досье]
Тогда встречный вопрос: А кто будет определять эти объекты ? Пользователь ? или это всеже "искуственный интеллект" ? ;) Можно использовать CREATE/SHOW/ALTER DATABASE/TABLE/COLUMN. Ну или конечно можно и так как Вы предлагаете, только избавиться от избыточности, тут много вариантов, но IMHO так будет медленнее и замороченнее, по сути одна реляционная модель над другой. IMHO., надеюсь опытный народ всеже не отмолчится если я не прав.
спустя 57 минут [обр] Top manager(0/2)[досье]
Thirteensmay[досье] без условно, заморочено, по этому я и здесь. А определять будет юзер
спустя 1 час 30 минут [обр] Thirteensmay(0/157)[досье]
Ну вот я Вам и предлагаю не заморачиваться. По крайней мере в этой моделе все относительно просто и понятно. Даже фронтенд для модификации таблиц наверное можно найти готовый. Конечно местами она будет проигрывать какой либо другой, но также местами эта какая либо будет проигрывать ей... Так что думаю не стоит. ;)
спустя 3 минуты [обр] Top manager(0/2)[досье]
Thirteensmay[досье] сама по-себе идея не плоха, но какие будут таблицы, не говоря уже о полях с их типами, регулируют юзеры. Они создадут новый тип иерархии, значит, согластно вашей логике, должна создаться таблица... . А как в ней будут распределены поля?... И вообще, когда система создаёт таблицы, а потом ещё и обращается к ним, мне кажется не очень стабильной, хоть и быстрой.
спустя 17 минут [обр] Thirteensmay(0/157)[досье]
Да, конечно, при создании нового типа будет создаваться новая таблица. Поля в ней будут распределены так как пользователь задаст, точнее пользователь работает с инструментом (скриптом) который позволяет описать новый тип, ну там селекты всякие, инпуты, а уже потом на основе полученного описания типа создается таблица. Не понимаю причем тут стабильность, она зависит не от того таблицы это будут или другая структура, а от адекватности действий пользователей. Если Вы запустите козла в огород то хоть рядками, хоть колечками капусту сажайте, один хрен сожрет. Т.е. бардак можно устроить и в любой другой структуре, и единственный вариант - ставить загородки и делать проверки. Никто не мешает, где угодно.
спустя 2 дня 16 часов [обр] Top manager(0/2)[досье]
Thirteensmay[досье] ясно :)
спустя 9 дней [обр] Степаныч(0/50)[досье]
А по мне, если заказчик не может определиться с объектами и их взаимосвязями изначально - это значит что он сам не знает чего хочет и толку от разработки системы не будет.
Powered by POEM™ Engine Copyright © 2002-2005