>делающий nosql на базе реляционки
я в шоке)) А можно подробнее?))
МИГРАЦИИ и устройство БД.
Платформа стримс имеет свой расширенный мигратор, который способен читать миграции, заданные в декларативном стиле. Файлы миграций создаются автоматически, при скаффолде аддонов определенных типов, а также при скаффолде стрима(модели).
The best practice, если мы говорим о модуле, ИМХО - иметь один файл миграции для модуля, в котором описываются все используемые поля, и по одному на каждую модель - в них описываются параметры моделей и принадлежность к ним полей. Важно, что в любой миграции, могут быть использованы стандартные для Ларавел up() и down() методы.
БД имеет в названиях своих таблиц жесткую зависимость $app_reference, неймспейса и модели.
Структура такова:
applications - "корневая" таблица, она имеет связь с applications_domains и это единственные таблицы, имеющие название без префикса. Все другие таблицы имеют в качестве префикса в названии "{$app_reference}_"
streams, fields и assignments - это "служебные" таблицы. Они содержат информацию о:
- других таблицах с базе и их свойствах (streams)
- полях, которыми имеют возможность обладать таблицы (fields)
- реальных фактах обладания каких-то таблиц, какими-то полями (assignments)
Остальные таблицы имеют жесткую зависимость от описаных выше!
"{$app_reference}_{$namespace_slug}_{$stream_slug}"
А если стрим (ряд) имеет поле translatable === true, то еще и
"{$app_reference}_{$namespace_slug}_{$stream_slug}_translations"
Это не все - могут быть еще вариации конфигураций. Не будем на них останавливаться.
Когда меняется содержимое служебных таблиц (а это модели ларки), наблюдатель триггерит событие Eloquent, которое, в свою очередь, запускает команду - одну из команд - проводящих маленькую миграцию, соответствующую изменениям.
Любые другие таблицы могут быть безболезненно созданы в базе, если только их имена не имеют конфликтов со схемой описанной выше.