13 сентября 2013 в 0:26
Есть материалы разных типов, в каждом из них 20-30 полей.
Типов материалов для старта 6 штук, планируется расширение до 30-50.
Поля в основном цифровые или краткий текст. Где-то 1/3 таксономия.
Нужно:
-Фильтровать по некоторым полям
-Хранить поля (само собой)
-Импортировать материалы (ячейка - поле)
Посещаемость сайта планируется хорошая. Я пока не знаю точно какая, в этом и вопрос (см. ниже).
1)Как сделать это на нодах я знаю. Выдержит ли Друпал такую реализацию про бОлшой посещаемости.. Ведь для каждого поля он создает свою таблицу, подвязывает ее в запрос при выборке..
2)В чем может быть преимущество реализации подобного на entity? С какой посещаемости это будет оправдано (думаю это главный вопрос сейчас) ? C чего начать в работе с entity для такого проекта?
Комментарии
Друпалу откровенно по фиг, зависит от хостинга.
Если Вам требуется только выводить поля этих сущностей через вьювс(или еще через что), хранить и создавать(неважно массово или не очень), и при этом таких сущностей будет вагон и маленькая тележка, то смысл использовать свои сущности есть - при работе с ними не будет задействован ненужный Вам функционал нод, в том числе node api, который при любом обращении к ноде будет вызывать соответствующий хук, что при большом числе левых модулей может вызывать довольно сильные тормоза, особенно при сохранении, а так же создавать путь к каждой ноде и делать прочую ненужную фигню.
Однако использование своих сущностей подразумевает кодинг, и, соответственно, более высокий ценник, потому, если у Вас их планируется всего 100-200шт или около того, а так же по фиг, что их можно будет найти по адресу node/%, то проще хранить информацию в нодах и не заморачиваться.
g85, спс. Я б с удовольствием склонился к варианту реализации на нодах. Так быстрее и проше.
Адрес ноды может и не нужен, но он не смущает.
А если нод будет 5000?
Выделенный сервер возможен.
P.S. Большая часть времени пользователя (нагрузки на сервер)будет при отборе строк материалов по разным комбинациям фильтров.
5000 выдержит и шаред, однако импорт, скажем, 1000 нод за 1 раз может оказаться довольно тормозным, в сравнении с сущностями.
Если у Вас кроме этих 5000 нод, будет еще 100500 других нод, то, возможно, ввиду того, что все сущности одного типа(в данном случае ноды) хранятся в одной таблице, все это дело может не очень хорошо сказаться на Вашей субд.(хотя, если используете, например, солр, то глубоко по барабану)
Планируемое кол-во нод 800000 (восемьсот тысяч).
Типов материалов 120.
Остальное выше.
У кого-то есть мысли по этому поводу?))
Хоть 8 миллиардов, надо понимать каким будет размер бд и осознавать последствия, в случае с нодами операции по загрузке\сохранению\выводу будут несколько дольше, ибо они унифицированны