Я разрабатываю страницу с C5, требующую привязки различных данных к учетным записям пользователей. Есть два типа пользователей с разными данными. Некоторые данные являются многомерными, и для этого требуются настраиваемые таблицы БД. У меня вопрос, есть ли смысл хранить все данные в настраиваемых таблицах БД или использовать пользовательские атрибуты для одномерных данных.

Наверное, на этот вопрос нет общего ответа, но, может быть, какие-то плюсы и минусы?

Я часто спрашиваю себя, где хранить данные в Concrete5, и мне было бы интересно, как решат другие ...

1
johjoh 1 Май 2013 в 16:22
Одно преимущество для атрибутов, которые я уже обнаружил: они видны, доступны для поиска и экспортируются через панель управления. Возможно, полезно для управления пользователями.
 – 
johjoh
1 Май 2013 в 16:40

1 ответ

Лучший ответ

Ага. Я бы определенно сохранил как пользовательские атрибуты по тем же причинам, что и тот, который вы уже определили (видимый, доступный для поиска и т. Д.).

Бетон5 является расширяемым, но не супер расширяемым; вы можете прикреплять данные к пользователю с помощью атрибутов, но не через какую-то полностью настраиваемую таблицу объектов / баз данных, которая, как вы ожидаете, например, будет отображаться на странице профиля пользователя.

Часто в c5 (как и любой другой фреймворк) сделать это Правильно (атрибут) сложнее (особенно для первого «объекта», но также и для каждого дополнительного), чем просто создать таблицу db и привязать к идентификатору пользователя. Но, как и во всех фреймворках, в будущем вы получите преимущества, о которых даже не задумывались. Это поиск, возможность обновления и вещи, которые могут прийти в голову только тому парню, который возьмется за разработку в следующем году.

Итак, со всем сказанным, переходите к атрибутам. И не только для одномерных данных. Вы можете настроить контроллер атрибутов (и схему базы данных, стоящую за ним) для хранения любых данных, которые вы хотите. Посмотрите на атрибут Address. Он содержит несколько полей (хотя он все еще 1D). Я думаю, что есть атрибут «мультиадрес» с открытым исходным кодом, который хранит адреса 1-n как один атрибут. Вы можете сделать это с помощью дополнительной связанной таблицы, но я недавно поленился с c5 и сделал no-mysql, выгрузив json_encode() ed (многомерные) массивы в поле "data". (В этом случае вашему атрибуту даже не нужна собственная таблица - он может использовать таблицу по умолчанию.) Затем вы можете настроить интерфейс редактирования, а также отображаемое значение (так, например, он просто показывает список каждого подзаголовка). -object свойство Name). Точно так же вы можете настроить текст, который индексируется для целей поиска.

Вы спросили за / против. Выполнить этот обычай будет быстрее и проще. Расширение атрибута, особенно для создания чего-то сложного, непросто, и хорошей документации не так много. Кроме того, пользовательский интерфейс для редактирования атрибутов (на странице пользовательской панели) немного запутан. Да, вы можете «спроектировать» все, что захотите, в «ячейке таблицы», но вы по-прежнему ограничены тем, что можете заставить администратора щелкнуть имя атрибута, используя интерфейс редактирования в ячейке, а затем (в идеале) щелкнуть маленький значок диска. (Создание диалогового окна javascript может решить некоторые проблемы здесь.)

3
James S 2 Май 2013 в 03:02
Спасибо за информативный ответ! добавлю несколько мыслей на следующей неделе.
 – 
johjoh
3 Май 2013 в 15:35
2
Это отличный ответ! У меня есть начальный код для создания настраиваемых атрибутов - может помочь вам разобраться в нем (как и в случае с большинством продвинутых вещей в C5, атрибуты ужасно недокументированы): c5blog.jordanlev.com/blog/2012/03/minimal-attribute-type-code
 – 
Jordan Lev
3 Май 2013 в 19:07
Еще раз спасибо, Джеймс, ваш ответ был очень полезным. Я помещаю все 1d-данные в атрибуты, что кажется очень правильным! к сожалению, у меня не было возможности поэкспериментировать с настраиваемыми типами атрибутов, потому что крайний срок слишком короткий.
 – 
johjoh
8 Май 2013 в 20:31
И два других преимущества для настраиваемых таблиц: 1. Он предлагает больше свободы для запроса данных с помощью sql-операторов ... пока я не проверял подробно модель ItemList, которая также предлагает функции для настраиваемых запросов. 2. В один прекрасный день легче снять границу между пользователями и данными, если это потребуется.
 – 
johjoh
8 Май 2013 в 20:46
ItemList довольно продвинутый, за исключением предложений OR, но вы всегда можете добавить ручной SQL. Однако обратите внимание, что вы будете запрашивать не список атрибутов ItemList, а список пользователей и значения отдельных индексированных атрибутов для пользователей.
 – 
James S
9 Май 2013 в 10:44