21 марта 2013 в 17:56
Привет всем.
Есть некий тип материала, у которого набралось со временем куча полей (порядка 30). Понятное дело, при выборке ноды с таким количеством полей запрос выглядит мягко говоря странно - целый ворох JOIN`ов.
90% полей заполняется всегда. Т.е. не бывает пустых не заполненных полей.
Логично было бы создать новый тип Entity с набором свойств, перекрывающим потребности.
Т.е. одна запись в таблице, содержала бы все необходимые данные. Тогда и производительность вырастет, и кол-во таблиц БД заметно сократиться.
Но, есть ещё один вариант - создать комплексное поле. Определить новый тип поля, со всеми требуемыми полями (смешно получилось:)).
В общем надеюсь достаточно понятно изложил мысль:)
Что вы думаете по этому поводу, уважаемые? Создавать ли новый Entity, или добавить новый тип поля?
Буду рад услышать ваши мнения.
Комментарии
Свою сущность проще и логичней.
field collection , который создаёт свою сущность
О, это интересно:) Спасибо.
Интересная тема, я вот раньше как-то даже не интересовался этим вопросом, не приходилось столкнуться
Есть интересный модуль Entity Construction Kit (ECK). С его помощью можно легко сущности создавать и управлять ими.
Да, но внутри опять же поля определяем мы сами, а это
Проблема не решается.
Такие вот мысли... Кто сталкивался - делитесь опытом, не жадничайте
Тут все просто: поля нужны там, где нужны или могут понадобиться несколько значений. Свойства (properties) нужны наоборот там где они всегда будут в единичном экземпляре.
Например у нас есть сущность Foo. У неё допустим есть следующие характеристики: color, size, fruits.
То есть:
$color = 'red';
$size = 10;
$fruits = array('apple', 'banana', 'lemon');
}
color и size должны быть свойствами (лежать в базовой таблице foo), а fruits полем.
Это понятно, но мой вопрос был немного в другом.
Вот пример: Нужно что бы пользователи заполняли паспортные данные в некоторой форме, в которой помимо паспортных данных есть какие-то ещё данные (к примеру параметры заказа). Для хранения паспортных данных что лучше, создать Entity или создать новый тип поля?
По топику прослеживается мнение, что наверное всё-таки entity.
Не знаю. Форма что создаёт? Заказ? Логично предположить, что паспорт это характеристика человека, делающего заказ.
То есть есть 2 сущности: заказ и человек, который заказ делает. Соответсвенно паспорт - это поле сущности человек (пользователь?), а "какие-то ещё данные" это вероятно поля заказа. Кажется излишним создавать сущность для паспорта, это ненужное усложнение.
Я так понимаю, проблема в том, что паспорт имеет несколько полей (серия, номер, кем и когда выдан)? Логичным решением было бы программно создать своё поле, которое будет хранить в своей таблице сразу все эти значения в разных колонках. Ну и виджет/форматтер к нему тоже надо писать свой.
Тоже озадачен аналогичным вопросом. Если говорить про связку из своих кастомных Entity и Entity reference. Говорят Entity reference войдет в ядро 8 , получается более перспективное решение?
С одной стороны если использовать свое, созданное программно Entity, получаем все поля в одной таблице и меньше запросов. Но с другой стороны если хотим решение масштабируемое через юзер интерфейс, типа конструктор, хотим предоставить конечному пользователю возможность добавлять поля - опять делаем fieldable Entity, начинаем добавлять поля через бывший cck (field api) и опять получаем поля в разных таблицах со всеми вытекающими и все идет по кругу.
Вопрос - насколько критична проблема производительности в этом случае?
Но ведь помимо производительности еще беспокоит вопрос экспорта, импорта, обмена интеграции, в случае если боле сложная структура БД - все усложняется.
Да,я пример видимо не удачный выбрал.
Но в целом вашу мысль я понял. И для себя сделал такой вывод:
Если нечто (А), используется только в составе какого-то другого нечто (Б) - это нечто (А) претендует на хранение в поле.
Если нечто является само по себе "конечным продуктом", то это Entity.