Есть ли универсальный конструктор сущностей для Laravel?
Всем привет.
Есть какой-нибудь пакет для laravel в котором можно было бы создать сущность типа news и прописать в нее нужные поля типа дата, наименование, код и так далее, а потом например сделать другую сущность например project и прописать другие поля.
Ну в базе бы это все хранилось бы в такблицах типа: entity - сущность, entity_properties - свойства сущности, entity_properties_element_value - значенгия свойств для элементов, entity_elements - для самих элементо, т.е. новостей и проектов
Если знакомы с битриксом то хотелось бы сделать подобие инфоблоков, но более легковесный.
Антон Р., продумывать свои модели данных, конечно. EAV появился изначально как лень людей делать много таблиц и породил огромное число болей. Единственное место где его хоть как-то можно использовать - динамические характеристики различных товаров, но и то - потом все проходит экспорт в документы и поисковые индексы чтобы можно было с этим хоть что-то делать
Не делайте так, осильте динамическое создание таблиц и полей в базе данных, это просто. Какая разница что вы напишите в коде кнопки 'insert into entities ...' или 'create table / add field'? Зато итоговая производительность у вас будет максимальная и инструменты по работе с данными нативные.
Максимум будут проблемы - при частичном резервном копировании/восстановлении, настройке репликации и сложности поддержки клиентов с разными версиями (в веб это почти не актуально, кроме высоконагруженных сайтов высокой доступности)
Вячеслав Шевченко, точно так же, создаете одну две сто таблиц (список это связь 1 ко многим)
Вы же сейчас рассматриваете только один аспект - хранение данных в базе данных, но есть еще интерфейс и логика, ее то придется так или иначе реализовать, вне зависимости от того, как вы храните данные, в отдельных таблицах или запакуете в пару таблиц entity+value.
Моя логика в том, чтобы можно было создавать свойства для каких-либо сущностей интерфейсом системы (через админку).
В случае со списком мы создаем свойство и запись попадает в таблицу properties а возможные значение в properties_enum. И тут мы просто видим сразу что есть свойство с типом список и его значение, а нативного типа данных типа список не существует, если конечно я не ошибаюсь. А если мы говорим о множественном значении свойства, то тут уже не обойтись без отдельной таблицы element_properties_values со значениями свойств для элемента.
Да, логики тут будет вагон и маленькая тележка и выстрелить себе в ногу оооочень легко. Но пока мне не очень понятно как сделать так чтобы я могу получить список свойств различных типов и вывести их в админку используя поля таблиц базы.
Вячеслав Шевченко, во первых виды и структуру связей вы можете (но не обязаны) дублировать в соответствующих таблицах, а во вторых, никто вам не мешает вытаскивать всю информацию из самой базы данных, считывая наличие таблиц и полей в них, а необходимую информацию для отображения сериализовать в комментариях к полям и таблицам а так же в их именах, задав заранее структуру. Этот подход с точки зрения организации работы с базой более гибок, чем если бы вы дублировали всю эту информацию в записях в специальных структурах, а если данные в этих комментариях будут human readable, так и подавно удобнее.
Все дело в том что создавая свою структуру хранения данных entity-value, вы лишаетесь готовых и эффективных инструментов базы данных по оптимизации доступа к ним а так же контроль за целостностью (констрейнты, уникальные индексы и т.п.).
