что то подсказывает мне что слова CCK+Views+Taxonomy для вас знакомы
В общем и целом - данная связка (а в 7м друпале уже и ССК внутри ядра если не видели) она конечно крутая,для создания произвольного контента и выборок
через веб формы
если я правильно понял - данный компонент не для пользователя а для прогера
а как ООП подход оно хорошо до момента осознания что куча данных хранится по куче ячеек кучи таблиц и при этом так нафиг не нужно,только лишняя нагрузка на базу и путанина в таблицах
конечно это ИМХО , но вот пара доводов:
1- менять структуру данных программисту надо не часто (и делать это через ООП API он не согласится,во всяком случае мне проще вбить пару SQL в консоль или покликать мышой в phpMyAdmin чем писать скрипт который дёргает апилку,но это при условии что данные хранятся вменяемым способом)
2-растягивание данных по куче таблиц приводит к куче JOIN ,не самая медленная операция,но если верить в п.1 - не то что бы нужная
3-а вот это самый главный минус - поиски,их нет,и если у меня будет стоять вопрос между UniCat и native MySQL для хранения данных скорее всего я решу в пользу 2го способа
да,ещё обратил внимание на то что у вас все данные свалены в таблицы по типам,в том же друпале это сделанно немного по другому (предлагается создавать таблицы под различные типы контента,хотя и такой способ тоже можно использовать),
я хз почему так , честно
мне сейчас думать на эту тему лениво а на практике такими делами не приходилось заниматься
возможно кто то из вас неправ xD ,я не знаю кто,и если вы выложите свои мысли почему так а не по другому я бы сказал спасибо
а,да,ещё пара замечаний общего характера (вообще не относящиеся к теме вопроса)
если документируете апилки то документируйте полностью,сейчас у вас не понятно что именно какой метод возвращает и вообще у какого класса их вызывать
иногда кучу слов можно заменить парой картинок
размер шрифта на вики крупный (я так вообще подумал что призумил страничку случайно) - напрягает
