1

Тема: Архитектурный вопрос ( произвольное доп. полей к записи )

Разрабатываю каталог объявлений. Клиент хочет, чтобы к объяве в конкретной категории можно было помимо стандартных полей ("заголовок", "тип предложения", "цена" и.т.п.) пришить ещё произвольное количество полей, списков, чекбоксов и.т.п. Потом эти данные будут выводится при просмотре объявления.

сразу напросилось такое решение - сделать дополнительную таблицу вида "id/category_id/field_type/". и таблицу со значениями "id/category_id/id объявления/значение".

Теперь предположим, что дополнительных полей у нас так штук по 5-20 в зависимости от категории. Получается что при вставке/обновлении значений в бд это ещё + 5-20 запросов. Тематика сайта, правда, такова, что вставок будет не так уж и много и на это дело можно, скрестив пальцы, закрыть глаза. Но что, если потом клиенту понадобится организовать поиск по этим "доп" полям или выводить их в общей таблице с объявлениями?

Вобщем вопрос сообществу форума - допустим ли такой подход, или же лучше поискать другой? Какие ещё варианты решения существуют?

2

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

Вариантов не особо много.

Наиболее распространенный это одна дополнительная таблица в которой и хранятся поле = значение
т.е.

id
notice_id
field_name
field_value

- и запрос один.

т.е. 1 запрос на основные поля + 1 запрос на дополнительные.

3

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

Ну к такому решению я и пришёл. На phpclub посоветовали то же самое, только долго и запутанно default/smile

4

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

тогда вопрос

зачем тебе рнрклуб? default/smile

5

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

я там и раньше не частый гость был - а уж после знакомства с Sf - и подавно.

Думал мож чего дельного подскажут default/smile

6

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

после знакомства с Симфони я например, понял, что все попытки писать "свою CMS" на РНР это хуйня на постном масле.

подозреваю что ребята, сидящие на РНРклубе занимаются  такой же хуйней

(я не говорю о всех, но подозреваю что как минимум половина таких там есть)

7

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

default/lol default/lol default/lol
но я согласен.

8

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

После знакомства с Sf я вообще не понимаю - как до сих пор живут многие CMS ))))

"Своя CMS" - это обязательный пункт в жизни каждого веб-программиста. Все через это должны пройти )

9

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

живут потому что можно нажать кнопку "сделать сайт"

многим это нравится

10

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

однако и к symfony уже есть готовые плагины, предоставлящие неплохой функционал )) Сам правда их не юзаю - люблю велосипеды мастерить default/smile

11

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

Symfony не есть коробочное решение полнофункциональной CMS default/smile

12

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

Готовые CMS - решение для юзеров, и копи-паст "программеров", делающих быстрые маленькие деньги, разводя незадачливых заказчиков и втюхивая им свое наколенные поделки default/lol . Тем самым, кстати, портя репутацию программистов, и опуская цены на разработку.
Нормальному же программеру, нужна CMF, как по мне - Symfony идеально подходит, и свой Over FrameWork, основанный на типизированных плагинах.
Потом просто выбираешь необходимые, подключаешь, соединяешь в приложении и получаешь готовую систему. Да, тут нужно немного поработать руками и головой, но это намного гибче чем CMS, и их системами подключения плагинов, которые только под эту CMS и заточены.

13

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

symfo пишет:

делающих быстрые маленькие деньги, разводя незадачливых заказчиков и втюхивая им свое наколенные поделки

С точки зрения бизнеса ЦМС тоже имеют свою нишу, и довольно большую. Когда вы делаете пилотный проект, с большими рисками - вы врядли станете (сможете) вложить в разработку сразу тысяч десять-двадцать-тридцать долларов, еще будучи неуверенным, пойдет ли вообще проект, или останется невостребованным и сразу провалится.
Реально же, шансов, что вам даже за 5к напишут что-то вменяемое на фреймворке - немного. И время - это тоже очень важный фактор в бизнесе. Бывает, что результат через полгода уже никому не нужен, ниша занята.

Также не нужно забывать малый бизнес. Там у клиентов просто нет таких денег, чтобы получить что-то вменяемое не на основе ЦМС. Поэтому они вынуждены пользоваться готовыми решениями с доработками или без. И ситуация эта не изменится, потому что хороший специалист (не говоря уже о команде оных) и индивидуальное программирование стоят дорого. Иногда они просто экономически не оправданы, проект не окупится.

В первую очередь результат зависит не от использованного решения, а от менеджмента и качества специалистов. Хороший специалист на друпале конфетку сделает, хоть и будет блевать периодически от копания в говнокоде.

14

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

Малый бизнес как раз хотелось бы забыть default/smile. От бакланов, которые хотят получить нормальный инет-магазин за 500у.е., меня уже давно просто воротит. Работать на таких - тратить свое время впустую, создавая проект, который через полгода-год будет никому не нужен, т.к. такие люди обычно ничерта не понимают в инет-бизнесе, не представляют какие вложения нужны в рекламу, и слушать ничего не хотят default/smile.

Кстати, по теме default/smile. Писал я подобные вещи. Систему подбора и сравнения товаров по характеристикам(которую потом яндексмаркет благополучно передрал, спасибо хоть сами и бесплатно добавили сайт в яндекскаталог default/smile ). Характеристики могут добавляться, удаляться, редактироваться, переноситься из группы в группу и т.д.

Использовал несколько таблиц:
measures - единицы измерения
parameters_fields - поля класса параметров, такие как класс товара, группа, тип, ед.измерения и т.д...
parameters_fields_description - текстовые, языкозависимые поля
parameters_groups - группы для параметров
parameters_groups_description
products_classes - классы параметров (ноутбуки, фотокамеры, видеокамеры....)
products_classes_description
products_parameters_[product_class_name] - для каждого нового класса создается таблица, для хранения параметров товаров этого класса

При добавлении класса товаров создается новая таблица products_parameters_название_класса, и название_класса заносится в products_classes. Затем для класса создается группа, а затем в нее добавляются соответствующие параметры, которые являются полями в таблице products_parameters_название_класса. В таблице товаров хранится только ID класса.
Такая система позволяет автоматически создавать формы добавления/редактирования параметров, а так же подбора и сравнения, выводить таблицы с параметрами и строить краткие описания товаров. Естественно, для увеличения производительности, использовалась система кеширования объектов, таблиц характеристик и кратких описаний.
Ну и система управления всем этим хозяйством, с копированием полей из другого класса, и экспортом/импортом всего этого через XML. Сами значения характеристик, точно так же импортируются/экcпортируются с товаром через XML, причем без зависимости от каких-либо ID, кроме класса товара. В новом товаре можно было выбрать класс и товар, из которого скопировать значения характеристик, а потом лишь подправить отличающиеся.
Почти все с использованием AJAX default/smile.
Потом еще написал генератор сателлит-сайтов, где создается один текстовый конфиг-файлик, для каждого класса, и каждое поле названий групп и параметров легко переопределяется и меняется местами, или исключается. После генерации получаются таблицы характеристик, которые методом шинглов не распознаются как копии оригинала default/smile.

15

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

symfo пишет:

От бакланов, которые хотят получить нормальный инет-магазин за 500у.е.

Проблема в том, что на Симфони (как и на любом другом высокоуровневом фреймворке) совершенно нереально получить нормальный инет-магазин даже за 5000 у.е. И это не учитывая других расходов, которые тоже немаленькие (особенно контент-менеджмент), только девелопмент. А это немалая сумма, для многих в малом бизнесе неподъемна и будет очень долго окупаться. Поэтому ниша оскоммерца, шопскрипта и прочего говна существует и будет существовать. Тем более что адекватных опенсорс или коробочных решений пока что не наблюдается. Маженто, хоть и построен на базе ZF, но по качеству кода и главное - архитектуры недалеко ушел. И ресурсоемкость у него мягко говоря немаленькая.

С чем работать - это конечно каждый программист решает для себя сам (если конечно не подневольный). Лично я последние три года работаю исключительно с Симфони.

16 Отредактировано symfo (2011-01-14 12:43:52)

Re: Архитектурный вопрос ( произвольное доп. полей к записи )

Я и не говорю, что малый бизнес должен умереть default/smile. Я же не чивокунЯ и его команда default/big_smile.
Просто для себя решил, что хватит с меня уже этого малого бизнеса. Пусть CMS остаются пользователям и студентам-программистам, а профессионал должен работать с профессиональными решениями. И симфони как раз то, что нужно.
Своей CMS я не написал, хотя было такое желание раньше default/smile. Теперь и не хочу писать. А вот создать свой набор плагинов, которые можно собирать в различные варианты CMS(и не только), - это задел на будущее. Как закончу первый проект, поднатаскаюсь в симфони, и займусь созданием такого набора.