JhaoDa

Потому что за использование float для хранения денег давно пора отрубать руки. Используй хотя бы decimal, а в идеале надо хранить деньги как целые числа — в копейках, центах и прочем. Ларавел тут совершенно ни при чём.

Кому-то надо пойти почитать про тип float и проблемы, с ним возникающие, а то, не дай Ктулху, он ещё и деньги в нём хранить будет...

При чём тут ларавел? Надо SQL изучать.

->nullable(), а не ->default(null)

В JSON может поместиться всё, что вы захотите в него поместить, mysql не волнует, сколько там «полей».

Размер JSON-поля определяется переменной max_allowed_packet.

Ну и лучше юзать PostgreSQL, там с JSON'ом всё лучше (в JSONB-варианте) — например, нормальные индексы.

Я брал за основу компонент Promotion из екоммерс-фреймворка Sylius. Есть доки такие и ещё чуток вот таких.

MySQL 5.7.8 и новее умеет делать запросы по содержимому json-полей.

Да, правильным будет избавиться от енумов, создать отдельную модель Social и с помощью связей соединить соцсеть и юзера.

Нет, не всё в БД должно быть сущностями, но в данном случае это удобно.

Надо создавать новую миграцию, добавляющую эту пару полей, а не править существующую.

К предложенным вариантам можно добавить очереди: создали заказ, добавили в очередь задание с нужной задержкой. Задание срабатывает, помечает заказ и отправляет уведомление. Если заказ доставлен до того, как сработало задание, то задание можно удалить (не все серверы очередей поддерживают).

См. правильный ответ выше. Если что-то мешает (странное ТЗ, религия, тимлид, начальство), то:
1.

Guides::where('categories_id', 'LIKE', "%\"{$cat_id}\"%")

2. Перейти на PostgreSQL, он умеет искать в json'е.

Если я правильно понял мануал, то M это «display width» и «display width does not constrain the range of values that can be stored in the column». Т.е. под BIGINT всегда будет отведено 8 байт.