Структура БД и её описание

[boxfrommars]

в laravel достаточно магии, зависящий от именования полей в бд, поэтому нужно где только возможно следовать именованиям, которые позволяют это магии работать.

также в laravel присутствуют генераторы, которые генерируют файлы миграции, так что, даже если вы создаёте файлы вручную, необходимо описывать миграции так, как они были бы описаны в сгенерированном файле миграции.

структура базы данных должна быть описана в виде диаграммы таблиц и должен быть предоставлен как исходный файл диаграммы, доступный для редактирования, так и экспорт этого файла в png или jpg.

вопросы для обсуждения:

• описать требования к структуре бд (именование таблиц/полей)
• привести классические схемы бд для отдельных сущностей
• в чём рисовать диаграммы (сейчас мы используем Dia -- кроссплатформенный редактор)
• стандартный вид диаграммы (обозначения цветом, выделением)

[boxfrommars]

примеры:
https://bitbucket.org/rutorika/compasspools/src/562987012b52e2cf9f550a0737adb720721944c4/docs/?at=master

https://bitbucket.org/rutorika/awi/src/8de4dc91ddf0/docs/?at=master

[boxfrommars]

Я заметил, что у нас сейчас два разных подхода к миграциям:

В миграциях -- схема, в сидерах -- данные

Пример: awi Миграции, Сидеры

В миграциях только схема базы данных. в сидерах -- данные, которые в свою очередь делятся на две точки входа: необходимые для работы приложения (DefaultSeeder) и тестовые данные (TestSeeder). Таким образом при разработке мы делаем

$ php artisan migrate
$ php artisan db:seed # запускает DefaultSeeder
$ php artisan db:seed --class="TestSeeder" # запускает TestSeeder в котором прописаны остальные сидеры

на продакшене при разворачивании

$ php artisan migrate
$ php artisan db:seed # запускает DefaultSeeder

В миграциях -- схема и необходимые для работы приложения данные, в сидах -- тестовые данные или сиды вовсе отстутствуют

Пример: scrooge Миграции

в этом случае при разработке:

$ php artisan migrate # тут уже есть необходимые данные
$ php artisan db:seed # запускает DefaultSeeder, в нём тестовые данные

в продакшене

$ php artisan migrate

Плюсы первого подхода: разделение схемы и данных

Минусы первого подхода: нет простого способа обновить необходимые данные, потому что нельзя снова выполнить php artisan db:seed, в котором мы удалим предыдущие данные и добавим отредактированные новые, т.к. это приведёт к некосистентности ключей. с другой стороны, даже если мы не отредактируем файл сидов, а добавим новый, в котором без удаления изменим текущие данные, нет простого способа "распространить эти изменеия", т.к. в сидерах нет механизма "запустить только новые сидеры" (какой например есть в миграциях) и придётся вручную на всех установках запускать отдельный конкретный сидер.

Плюсы второго подхода: легко изменять необходимые данные, просто дописав новую миграцию. Для тестовых данных остаются сидеры, которые всегда можно перезапускать полностью с очисткой базы и созданием новых записей.

Минусы второго подхода: нет разделения схемы и данных

Мне на первый взгляд больше нравится второй подход, когда необходимые данные кладутся в миграции. Но нужно обсудить, может я что-то упускаю из вида

[boxfrommars]

И нужно чётко разделить. какие данные являются необходимыми (требующимися на продакшене), а какие нет.

Пример необходимых

Состояние кваритры: продана, доступна, забронирована
Роль пользователя: администратор менеджер

Пример тестовых

Квартиры
Пользователь-администратор

[DexinDev]

Я за второй подход.

[boxfrommars]

Насчёт пользователя-администратора, я сейчас использую такой способ для добавления такого пользователя на продакшен (указываю в ридми):

Create Manager

open tinker repl

xu@calypso:~$ php artisan tinker

in tinker type

>>> $user = new \App\User;
>>> $user->email = 'admin@example.ru';
>>> $user->password = Hash::make('somePassword'); # replace somePassword with some strong manager password
>>> $user->name = 'Administrator Name';
>>> $user->save();
>>> \q # quit tinker

[boxfrommars]

@DexinDev так как @demidovich и так использует этот подход, то единогласно принимаем :)

[DexinDev]

Я админа в миграцию добавляю. Если он используется на сайте, то зачем делать его добавление опциональным?

[boxfrommars]

@DexinDev и получается. что пароль администратора и его емейл лежит в репозитории, что плохо. а так тестовый админ лежит в тестовых сидерах и на проде не появится. а на проде генерируешь уже настоящего админа и отдаёшь заказчику

[DexinDev]

Ну обычно же делается форма для смены пароля в админке? Если нет, то ок. У меня везде есть.

[demidovich]

Логин и пароль админа в репозитории можно сделать абсолютно простыми, чтобы просто первый раз залогиниться в системе и потом изменить через форму редактирования пароля. Извиняюсь, что пропустил мегадискуссию.

[boxfrommars]

@demidovich @DexinDev ну так получается, что это не продакшен данные, если мы их сразу меняем на продакшене? и на всех ли сайтах вы делаете форму изменения пароля? и сразу ли вы знаете email будущего администратора?

[DexinDev]

Форму я делаю на всех, это же не сложно. Имейл - да, надо подгонять.
Но твой вариант подходит только если у клиента есть компетентный сотрудник, который сможет выполнить тинкер. Иначе мы будем делать это сами и будем знать доступы.

[DexinDev]

Может сделать универсальный сценарий создания админа? Даем клиенту ссылку со специальным токеном и он заводит первого юзера...

[boxfrommars]

@DexinDev

Но твой вариант подходит только если у клиента есть компетентный сотрудник, который сможет выполнить тинкер. Иначе мы будем делать это сами и будем знать доступы

это делается в момент разворачивания на продакшене, тот кто разворачивает в любом случае имеет доступ и умеет пользоваться консолью

Может сделать универсальный сценарий создания админа? Даем клиенту ссылку со специальным токеном и он заводит первого юзера...

как вариант. но усложнённый вариант