7 мая 2010 в 20:31
Например у нас есть материала Статья и материал Новость, к каждому материалу прилагаются поля Картинка (imagefield) и, например Важность (число), остальные поля разные.
Вопрос:
1) стоит ли создавать для Статьи: поля article_image & article_importance а для Новости: news_image & news_importan,
или
2) сделать поля node_image & node_importance и добавить в оба типа?
Интересует влияние на производительность(в т.ч. при использовании полей в выборках views) и дальнейшую доработку сайта.
Обычно для одной сущности атрибуты находятся в одной таблице, однако CCK работает не так, поэтому возникает такой философский вопрос.
Комментарии
Не в курсе, как-там-насчет-производительности, но вот вам философский ответ: не преумножай сущностей сверх необходимого
Просто будет влиять на производительность вашего труда - при настройке вьювс, скажем, нужно помнить что у вас 2 поля, а не одно, выводить одно если нет другого и т.п., цсс-стилей в два раза больше... и т.п.
Вообще, если учесть то, что присутствие поля только в одном типе материала гарантирует его представление в виде отдельной колонке в таблице материала, а присутстсвие в более чем в 1 типе материала гарантирует создание новой таблицы с вытекающими JOIN и, если так увлекаться, создание общих полей может привести к созданию большого числа доп таблиц => если потребуется выдернуть все данные - вуаля, мускл начнет ругаться на 61 таблице (да, да, бывает такое). + поддерживать тяжелее. Придется очень аккуратно следить за ревизиями и прочим, если таковые используются.... Итого - используйте 1 поле для нескольких типов материала, это необходимо из-за логики работы, а не лени создать еще 1 поле.
Ну, тут проблем особых я не вижу, скк документирую в стиле классов uml, а темизировать - далеко не всегда требуется отдельно поле...
Получается что если на каждый тип материала по своему полю - поля добавляются в таблицу ка поля таблицы, если же использовать 1 общее - тогда получим новую таблицу. Т.е. выгднее использовать 2 поля для 2-х материалов (экономим таблицы и joinы)...
Но тогда я запутался с вашим выводом:
Итого - используйте 1 поле для нескольких типов материала, если это необходимо из-за логики работы, а не лени создать еще 1 поле.
p.s.
извиняюсь
если оба материала могут присутствовать в одном запросе (и нет задачи тонкой настройки поля) - то стоит. Таким образом получится 1 JOIN вместо двух.
а если тимизировать это поле нужно в разных материалах по разному... то как тогда тут?
В одной из версий cck был такой косяк, что при удалении одного из полей терялись данные с этим полем во всех типах. С тех пор я всегда делаю разные поля.
edhel, и я на такое натыкался как-то давно) сейчас все норм.
т
иемизировать/*Стиль №1*/
}
.node-type-b .field-field-illustration {
/*Стиль №2*/
}
А вы правильно понимаете суть этого слова?
Я вот раньше делал одно общее поле cck для всех типов материала. А потом понял, что для меня лучше будет, если я для каждого типа материала создам свое поле. Но вот думаю, что на работающем сайте это надо сделать осторожно, чтобы не потерять данные
Насчет лишних джоинов. Тут я думаю, что их количество увеличивается, когда на странице выводятся разные поля разных типов материалов и мы определяем каждое поле в каждом типе материала. Так? (Вижу, что об этом уже написали). Мдя, я уже и сам не могу нормально составить предложение
Но. Если использовать общее поле для нескольких типов материалов, то тут при выводе на одной странице разных полей разных типов материалов лишних джоинтов не будет, а будет только один джоинт с таблицей content_field_название_общего_поля. Так?
Но. Как я понимаю, при загрузке конкретной страницы материала, мы будем наблюдать другую ситуацию. Тут, если я не ошибаюсь, все будет зависеть от количества самих полей в самом материале. Если количество полей велико, то при загрузке материала придется делать лишние запросы в каждую таблицу для каждого поля (это в случае, если поля общие для разных типов узлов, поэтому выносятся в другие таблицы). А если поля cck определены в одной таблице типа материала как составные поля этой таблицы, то все данные будут браться за один запрос...
Ух, во написал, сам могу не понять. Кто поймет - тому спасибо!
Если что-то не так, то поправьте меня...
Да, я знаю истинное значение этого слова в терминологии Друпала. Согласен, что одним css нельзя изменить внешний вид, если структура разметки этого не позволяет. Но товарищ не объяснил, что он понимает под темизацией. И хотелось бы увидеть от него пример, иллюстрирующий его вопрос...