-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
текстовые сущности
- Автор темы Redjik
- Дата начала
Redjik
Я использую смешенный подход, для нормальных модулей завожу свои таблицы, свои модели.
В тоже времени для сайтов визиток есть модуль Page, где одна модель у которой есть тип, название, краткое описание, красивый урл, seo заголовок, боди, мастер и слейв шаблоны, набор блоков. Соответственно сущности в виде дерева. ПОнятное дело, что много сущностей в такой системе не очень хорошо, т.к. могут быть проблемы с производительностью. Похожая система в ModX.
В CRM-ке у нас одна основная сущность, набор полей, связи, отображение и т.д. задаётся через конфиги. Хранится всё в разных конфигах, но генерируется на основании этих конфигов. Сейчас по дефолту все связи строятся по схеме много ко многим, чтобы не было проблем при модификации. От этой сущности наследовались другие модули, но сейчас используем декораторы и проксируем неовервраёженные методы на основную, т.к. наследование удобно, но какашка для конфигурирования и апгрейд сейф.
Я использую смешенный подход, для нормальных модулей завожу свои таблицы, свои модели.
В тоже времени для сайтов визиток есть модуль Page, где одна модель у которой есть тип, название, краткое описание, красивый урл, seo заголовок, боди, мастер и слейв шаблоны, набор блоков. Соответственно сущности в виде дерева. ПОнятное дело, что много сущностей в такой системе не очень хорошо, т.к. могут быть проблемы с производительностью. Похожая система в ModX.
В CRM-ке у нас одна основная сущность, набор полей, связи, отображение и т.д. задаётся через конфиги. Хранится всё в разных конфигах, но генерируется на основании этих конфигов. Сейчас по дефолту все связи строятся по схеме много ко многим, чтобы не было проблем при модификации. От этой сущности наследовались другие модули, но сейчас используем декораторы и проксируем неовервраёженные методы на основную, т.к. наследование удобно, но какашка для конфигурирования и апгрейд сейф.
Redjik
Джедай-мастер
alekciy
так как Amdy сказал - у меня так же есть в одном проекте сущность Page которая может быть как новостью, так и статьей или даже текстом категории товаров.
AmdY
я столкнулся не с проблемами производительности, а с расширяемостью - много костылей и зависимостей, пробовал так же декоратором решить, получилось получше, но каша образовалась.
так как Amdy сказал - у меня так же есть в одном проекте сущность Page которая может быть как новостью, так и статьей или даже текстом категории товаров.
AmdY
я столкнулся не с проблемами производительности, а с расширяемостью - много костылей и зависимостей, пробовал так же декоратором решить, получилось получше, но каша образовалась.
Redjik
Джедай-мастер
Сейчас вот хочу попробовать вообще сделать своеобразную прослойку из роутера.
В бд хранится url UNIQUE, module, controller, action.
Минус - + 1 запрос к бд (на небольших сайтах решается кешем)
Плюс - уникальный урл минимальной длинны
При таком подходе можно наплодить сущностей для каждого текстового типа, не опасаясь, что что-то где-то упадет из-за несовместимости...
В бд хранится url UNIQUE, module, controller, action.
Минус - + 1 запрос к бд (на небольших сайтах решается кешем)
Плюс - уникальный урл минимальной длинны
При таком подходе можно наплодить сущностей для каждого текстового типа, не опасаясь, что что-то где-то упадет из-за несовместимости...
alekciy
Новичок
Тогда, имхо, это не вопрос разбиения сущности, это вопрос использования некоего "общего" объекта в котором могут храниться разные типы данных. Как node в Drupal в который пихают все что можно. Текстовая же сущность "новость" ни как не делится.
На уровне же кода лично я использую базовый класс "объект" от которого наследуются нужные типы "новость", "топик" и прочее. Причем у базового класса может быть любой набор свойств которые можно динамически менять через админку. Профит в том, что структура таблиц одна и таже, код один и тот же (т.к. в дочерних классах переопределяется лишь пара методов, весь остальной код используется из базового класса). Как результат меньше ошибок при добавлении новых сущностей (ибо в базовом классе отловлено и исправлено много багов; новая сущность приносит мало нового кода, а меньше кода, меньше ошибок). Поэтому я за "смешанный" подход: несколько сущностей - несколько классов, но при этом их код через наследование по сути базируется на одном базовом классе (т.е. фактически несколько сущностей - один класс).
alekciy
Новичок
Имена? Абсолютно одинаковые. Структура одна и та же, там EAV использую. Плюс подхода в том, что с какой бы сущностью я не работал на уровне структуры таблиц и их логических связей я имею дело с одним и тем же. Т.е. для каждой новой сущности/модуля при супорте кода не нужно вспоминать/разрабатывать все с нуля, достаточно знать работу базового класса. Я за максимально простой и удобный в супорте код. У подхода конечно же есть минус. По сравнению с хранением свойств в столбцах, а не строках такой код работает медленее. SQL запрос на таблице в 100 тыс. записей отрабатывает в 3-4 раза медленее. Но для веба это в принципе не важно, т.к. между запросом в 0.1 мс и 0.3 мс в контексте всего приложения разница не ощущается. Страница все равно генериться ~10-30 мс. Вся система в целом (СУБД, кэш, веб сервер) берет под себя около 1,5-2 ГБ ОЗУ выдавая в номинальном режиме более 20 миллионов хитов в сутки, что для моих задач более чем достаточно. Поэтому в контексте упрощения супорта системы данный оверхед нахожу несущественным.
Наверное возникает вопрос, как же могут быть таблицы с одинаковыми именами и не возникать коллизий? А все просто, у меня Postgresql и я использую schema. Каждый модуль с сущностью находится в отдельной schema. Имя schema формируется из php-ого namespace-а. Т.е. движок берет и транслирует /alekciy/Mod/User в alekciy_mod_user, а /alekciy/Mod/News в alekciy_mod_news. Как результат с СУБД может работать один и тот же код базового класса. В результате того, что код базового класса юзается всеми остальными в нем отловлены все основные баги. А т.к. взаимодействие происходит только через API класса, то в базовом классе можно оптимизировать sql запросы и это ни как не сказывается на дочерних классах. Теоретически возможно будет даже отказаться от EAV, но я пока этим не замарачиваюсь, т.к. против преждевременной оптимизации.
Redjik
Джедай-мастер
но! таблицы разные все равно ... у меня то гемор весь начался, когда я в одну спихал и добавил поле category_id, который в последствии вообще переименовал в module
в итоге на весь CRUD - мне пришлось навешивать в AR обработчики
А с именами твой подход легrо решается и в mysql - просто в потомках оверрайдим $this->getTableName()
в итоге на весь CRUD - мне пришлось навешивать в AR обработчики
А с именами твой подход легrо решается и в mysql - просто в потомках оверрайдим $this->getTableName()
alekciy
Новичок
Физически да, таблицы разные.
С именами все решается в рамках PHP, но на уровне MySQL имеем огромную партянку с таблицами разделенную на namespace-ы через префиксы/постфиксы. Не-не-не, чур меня, мне Битрикс с over 300 таблиц нафиг не нужен. У меня сейчас коннектимся к базе, задаем schema и копаемся в пяти таблицах связанных с текущем модулем. И ни на что больше не отвлекаемся. Перед глазами должны быть только данные связанные с решением текущий задачи.
С именами все решается в рамках PHP, но на уровне MySQL имеем огромную партянку с таблицами разделенную на namespace-ы через префиксы/постфиксы. Не-не-не, чур меня, мне Битрикс с over 300 таблиц нафиг не нужен. У меня сейчас коннектимся к базе, задаем schema и копаемся в пяти таблицах связанных с текущем модулем. И ни на что больше не отвлекаемся. Перед глазами должны быть только данные связанные с решением текущий задачи.