Я разрабатываю страницу с C5, требующую привязки различных данных к учетным записям пользователей. Есть два типа пользователей с разными данными. Некоторые данные являются многомерными, и для этого требуются настраиваемые таблицы БД. У меня вопрос, есть ли смысл хранить все данные в настраиваемых таблицах БД или использовать пользовательские атрибуты для одномерных данных.
Наверное, на этот вопрос нет общего ответа, но, может быть, какие-то плюсы и минусы?
Я часто спрашиваю себя, где хранить данные в Concrete5, и мне было бы интересно, как решат другие ...
1 ответ
Ага. Я бы определенно сохранил как пользовательские атрибуты по тем же причинам, что и тот, который вы уже определили (видимый, доступный для поиска и т. Д.).
Бетон5 является расширяемым, но не супер расширяемым; вы можете прикреплять данные к пользователю с помощью атрибутов, но не через какую-то полностью настраиваемую таблицу объектов / баз данных, которая, как вы ожидаете, например, будет отображаться на странице профиля пользователя.
Часто в c5 (как и любой другой фреймворк) сделать это Правильно (атрибут) сложнее (особенно для первого «объекта», но также и для каждого дополнительного), чем просто создать таблицу db и привязать к идентификатору пользователя. Но, как и во всех фреймворках, в будущем вы получите преимущества, о которых даже не задумывались. Это поиск, возможность обновления и вещи, которые могут прийти в голову только тому парню, который возьмется за разработку в следующем году.
Итак, со всем сказанным, переходите к атрибутам. И не только для одномерных данных. Вы можете настроить контроллер атрибутов (и схему базы данных, стоящую за ним) для хранения любых данных, которые вы хотите. Посмотрите на атрибут Address. Он содержит несколько полей (хотя он все еще 1D). Я думаю, что есть атрибут «мультиадрес» с открытым исходным кодом, который хранит адреса 1-n как один атрибут. Вы можете сделать это с помощью дополнительной связанной таблицы, но я недавно поленился с c5 и сделал no-mysql, выгрузив json_encode()
ed (многомерные) массивы в поле "data". (В этом случае вашему атрибуту даже не нужна собственная таблица - он может использовать таблицу по умолчанию.) Затем вы можете настроить интерфейс редактирования, а также отображаемое значение (так, например, он просто показывает список каждого подзаголовка). -object свойство Name
). Точно так же вы можете настроить текст, который индексируется для целей поиска.
Вы спросили за / против. Выполнить этот обычай будет быстрее и проще. Расширение атрибута, особенно для создания чего-то сложного, непросто, и хорошей документации не так много. Кроме того, пользовательский интерфейс для редактирования атрибутов (на странице пользовательской панели) немного запутан. Да, вы можете «спроектировать» все, что захотите, в «ячейке таблицы», но вы по-прежнему ограничены тем, что можете заставить администратора щелкнуть имя атрибута, используя интерфейс редактирования в ячейке, а затем (в идеале) щелкнуть маленький значок диска. (Создание диалогового окна javascript может решить некоторые проблемы здесь.)
Похожие вопросы
Новые вопросы
php
PHP — это широко используемый язык сценариев общего назначения с открытым исходным кодом, мультипарадигмальный, динамически типизированный и интерпретируемый, изначально разработанный для веб-разработки на стороне сервера. Используйте этот тег для вопросов о программировании на языке PHP.