Вопрос архитектуры.

[pilot911]

Вопрос архитектуры.

Называется "Лавры Битрикса покоя не дают". В Битриксе у сущности есть (упрощенно) два постоянных свойства (Заголовок, Описание) и множество произвольных свойств, которые создаются пользователем.

Понятно, что эта архитектура неоптимальна, поскольку не всегда нужно для сущности добавлять динамические свойства. Например, у "Новости" мы могли бы создать постоянное свойство "Краткое описание" в той же SQL таблице "news", чем городить выборку с INNER JOIN чтобы выбрать все то же "Краткое описание" из динамической таблицы свойств.

Но тут возникает проблема другого характера, что называется "В одном месте прибавилось, в другом - убавилось". Как теперь сделать выборку свойств "Новости" ?

С динамическими свойствами понятно - их описание хранится в отдельной таблице, по которой можно сделать выборку для сущности "Новость". А как быть в случае, когда мы жестко прописали в таблице "news" свойство "Краткое описание" ?

Как это свойство извлечь и добавить в массив коллекции свойств "Новости" ?

 

[vovanium]

Ты хочешь обогнать битрикс по тормознутости?

 

[AmdY]

в чём проблема можно объяснить как-то понятнее для тех, кто не знает битрикса?

 

[Crys]

Где это в битриксе есть такое понятие, как "сущность"? Если имеется ввиду модуль инфоблоки, то как-бе там в постоянных свойствах краткое описание присутствует.

В тоже время, битрикс не запрещает написание своего модуля, который будет работать с определенной таблицей, не затрагивая пачку других. И запросы будут простыми, и производительность высокой. Мы так лет пять назад дублировали таблицу пользователей и набивали дополнительными свойствами (требовался отдельный "подвид" пользователей не конфликтующий с системными).

Ты хочешь обогнать битрикс по тормознутости?

Да не настолько он тормозной... Просто в нем хватает модулей с большой универсальностью, за которую нужно платить ресурсами. Ну возможно там на минимальной редакции на одном модуле быстро и просто создать новости/статьи/блог/форум/хрен_знает_еще_что.. Но все данные будут храниться в одной таблице, что и приведет к "тормозам битрикса".

Тут выбор - делаем быстро, просто и с тормозами... либо делаем как обычно - и работать будет "как обычно".

 

[pilot911]

Автор оригинала: AmdY
в чём проблема можно объяснить как-то понятнее для тех, кто не знает битрикса?

проблема в получении коллекции свойств сущности - жестко прописанных в таблице и динамических... их надо как-то вложить в один массив, чтобы затем отобразить в
HTML SELECT ... вот в чем затык

ПС. как это делается в нормальных фреймворках, если вообще делается? создается конфигурационный массив, описывающий таблицу в модели ?

 

[AmdY]

посмотри xs2, как там организовано, есть дерево объектов и пару типов данных в них (строка, число, связь 1-1 и 1-*). данные о основном дереве со списком обязательных свойст храни в отдельной таблице, список дополнительных свойств храни в отдельных таблицах сущность_<тип_сущности>
данные можно получать сущность left join сущность_<тип_сущности>, а можно выгребать отдельным запросом (мне так больше нравится). в итоге получится 20-60 запросов на страницу, но все по ключу и весьма шустро.

 

[pilot911]

AmdY, ты гений... действительно, что может быть проще хранить описание жестко прописанных свойств в отдельной таблице

будем считать, что пока вопрос снят