EAV-характеристики

StalkerClasses

Новичок
Во многих фреймворках свойства таблицы (модели) описываются в файлах.
Соответственно с синхронизацией между отдельными разработчиками не возникает трудностей - git поможет и разрулит конфликты если они будут.

А как быть с актуализацией EAV-характеристик в БД?

10 разработчиков создадут свои характеристики в своих ветках. Git их не увидит, т.к. они в БД.
Как быть? Есть ли возможность EAV-характеристики также базировать на файлах?
 
Миграции и сиды не для вас придумали
 
Миграции и сиды не для вас придумали
Сиды это наполнение первоначальными данными. 10 разработчиков сделают разные данные.
Миграции отслеживают изменение структуры данных.

Мне же надо что бы таблица характеристик была актуальной постоянно.
 
Что мешает данные твои пихнуть в миграции?
 
Ну, если тебя смущает - не создавай через админку, или в миграции проверяй есть ли подобная пара key-value, если есть - не вставляй данные. Подходов море, надо лишь продумать логику работы, которая устроит тебя.
 
@StalkerClasses тебя не смущает, то что ты пришел к ситуации, когда любой чих приводит к конфликту?
добавил relation - конфликт трейтов, добавил значение в базу - конфликт атрибутов
может имеет смысл пересмотреть все?
 
Ну кстати хороший вопрос
Я об нем задумывался, в плане правда не еава а монги.
что в прочем по сути одно и то же, поскольку джейсон поля давно убили еав, которым сейчас пользуются только тормоза и некрофилы

В общем нужна метатаблица, в которой вся структура и описывается.
То есть если в одминке добавляется харя ктеристика, то добавление идёт не только в таблицу с данными но и в некое хранилище, которое хранит эталонную структуру
 
Последнее редактирование:
@StalkerClasses тебя не смущает, то что ты пришел к ситуации, когда любой чих приводит к конфликту?
добавил relation - конфликт трейтов, добавил значение в базу - конфликт атрибутов
может имеет смысл пересмотреть все?
Что мог уже пересмотрел.
Ну кстати хороший вопрос
Я об нем задумывался, в плане правда не еава а монги.
что в прочем по сути одно и то же, поскольку джейсон поля давно убили еав, которым сейчас пользуются только тормоза и некрофилы

В общем нужна метатаблица, в которой вся структура и описывается.
То есть если в одминке добавляется харя ктеристика, то добавление идёт не только в таблицу с данными но и в некое хранилище, которое хранит эталонную структуру
Что имеется в виду под эталонной структурой?

Ну, если тебя смущает - не создавай через админку, или в миграции проверяй есть ли подобная пара key-value, если есть - не вставляй данные. Подходов море, надо лишь продумать логику работы, которая устроит тебя.
Когда работал с битрикс была большая проблема переносить свойства инфоблока и потом сливать это все в продакт от разных разработчиков. Придумал в итоге скрипт где показывалось различие между моим и продактом. И то не на 100%. У одного свойства сортировка 10, у меня 15...
 
Когда работал с битрикс была большая проблема переносить свойства инфоблока и потом сливать это все в продакт от разных разработчиков. Придумал в итоге скрипт где показывалось различие между моим и продактом. И то не на 100%. У одного свойства сортировка 10, у меня 15...

ohQW4edPDMPNABvAh-9G5sneMfMZi4Zy32BrlX1rxoojfvSEr7Mxwkh0KpJAdZRr2_fANZ2e3IqAkc0FBS0FEApuaJk
 
в плане правда не еава а монги.
если в одминке добавляется харя ктеристика, то добавление идёт не только в таблицу с данными но и в некое хранилище, которое хранит эталонную структуру
Знаешь, я недавно общался с одним проектом, платежным аггрегатором, в котором вместо РСУБД - монга.
Я им сразу честно сказал, что в enterprise монги нет, и опыту с ней у меня взяться неоткуда.
Ребята вздохнули, наследие, говорят, неплохо бы реляционности, но перевести уже не получится...
Вот как-то жалко ребят стало сразу. Платежные данные без нормализации. Ты поосторожней там с ней, с монгой-то. Оно, вроде, всего разок-другой, друзья предложили попробовать, ты под MVP согласился, а потом и хочешь бросить, да не можешь.
 
Сверху