Comments 12
Ничерта не понятно. Выложите полную схему БД, тогда можно будет обсудить
Дамп структуры доступен по ссылке.
У вас нету ни внешних ключей, ни комментариев. Хотите обсуждать ваше решение, при этом заставляя читателей самим разбираться в вашем коде?
Или, может, ваш пост — отписка, чтобы прорекламировать CMS?..
Или, может, ваш пост — отписка, чтобы прорекламировать CMS?..
В общем о рекламе речь не идет. Речь идет о идее. Просто разработчику иногда необходимо понять то что он делает имеет здравый смысл или нет. Кроме как таким образом сделать это трудно. По поводу отсутствующих комментариев — согласен. Однако для подробного описания необходимо много больше, чем я написал. А для оценки идее — вполне. Если идея интересна, то буду дальше расписывать реализованные механизмы.
Бенчмарки в студию! Я совершенно не верю, что это применимо для проекта большего чем сайтик на пару страниц.
Если принять во внимание «достаточно статические структурированные массивы данных», т.е. не требующие постоянного таскания их из базы, то файловое кэширование позволяет получиь достаточно неплохие результаты по скорости доступа — как на статичном html. Тормозить будут только frontend скрипты.
Весь необходимый интерактив в виде комментариев и иже с ним — то они лежат в отдельных таблицах и на отображение самих данных не влияют.
Весь необходимый интерактив в виде комментариев и иже с ним — то они лежат в отдельных таблицах и на отображение самих данных не влияют.
XML?
Не взлетит.
Не взлетит.
EAV?
Почему просто не использовать документ-ориентированную БД, например Mongo или CouchDB? Исходя из чего вообще вы выбрали _реляционную_ СУБД, если в предлагаемой структуре практически нет этих самых реляций (отношений, связей)? Как предполагаете осуществлять выборку данных для отображения «хлебных крошек» или, другими словами, получать полный путь произвольно выбранного элемента?
Проблема использование Mongo или CouchDB заключена в том что для их нет у хостеров виртуального хостинга. Покупать VPS и заниматься администрированием на ламерском уровне не хочется.
По поводу хлебных крошек в любом из вариантов построения дерева не обойтись одним запросом, собственно здесь есть parent_id по которому можно подняться до нужного уровня.
По поводу хлебных крошек в любом из вариантов построения дерева не обойтись одним запросом, собственно здесь есть parent_id по которому можно подняться до нужного уровня.
>Покупать VPS и заниматься администрированием на ламерском уровне не хочется.
Раньше тоже так рассуждал, но потом просто попробовал… Теперь кажется, что для покупки виртуального хостинга нужны обоснования (и, как правило, это различные «vip»-тарифы у хороших хостеров с грамотной, оперативной и просто адекватной поддержкой в том случае, если проект популярен, а нанять грамотный персонал не представляется возможным), а для хомяков, визиток и стартапов виртуальный сервер покупать нужно по умолчанию — гибкость настроек оправдывает недостатки «ламерского» администрирования :)
Раньше тоже так рассуждал, но потом просто попробовал… Теперь кажется, что для покупки виртуального хостинга нужны обоснования (и, как правило, это различные «vip»-тарифы у хороших хостеров с грамотной, оперативной и просто адекватной поддержкой в том случае, если проект популярен, а нанять грамотный персонал не представляется возможным), а для хомяков, визиток и стартапов виртуальный сервер покупать нужно по умолчанию — гибкость настроек оправдывает недостатки «ламерского» администрирования :)
> По поводу хлебных крошек в любом из вариантов построения дерева не обойтись одним запросом
Да ладно? www.google.ru/search?q=nested+set
Да ладно? www.google.ru/search?q=nested+set
Sign up to leave a comment.
Модель документо-ориентированной БД в реляционной СУБД