Зачем в reviews есть ФИО, если они есть в persons? И не стоит где-то называть person, а где-то user. Если их функции различаются, то это должны быть разные сущности. Возможно расширение функций, когда, например, user может быть клиентом магазина, а может быть владельцем/менеджером, тогда это могут быть таблицы с допсвойствами и ссылкой на первичную таблицу по id (user-shop_client и user-shop_manager).
У сообщения стопудово должно быть время отправки, по которому надо будет сортировать чат. Или можно по id сообщений сортировать, если id будут возрастать со временем. id и получателя, и отправителя не имеют смысла, если чат тет-а-тет, тут имеет смысл id только отправителя, который может совпадать с user_id в чате, а может быть user_id менеджера магазина (заодно можно, чтобы в магазине работали разные люди и могли независимо общаться с пользователями). Клиенту магазина можно не показывать имя менеджера, а показывать название магазина.
Хорошо бы навести порядок в английском. Massage - это массаж, правильно message; magazine - это журнал, правильно shop. ФИО лучше сортировать нормально (а не ставить отчество первым, хотя, конечно, в базе порядок столбцов неважен, но если уж проектировать, то аккуратно) и быть готовым к тому, что многие категорически не хотят его заполнять и будут ставить минусы или "нет" везде, кроме имени - короче, лучше разрешать их пустые значения. Вместо patronymic чаще всего поле называют middle name - это покрывает и понятие отчества, и дополнительные имена, существующие во многих культурах и странах.
products_id - почему во множественном числе? Лучше вообще единообразие: либо таблицы называются единственным числом (тогда красиво выглядят отсылки user.id, user.name), либо множественным (users), а ссылки как раз через единственное число.
При именовании таблиц и колонок не стоит использовать разный регистр и лучше воздерживаться camelCase. Всё равно большинство баз имеют регистронезависимые имена сущностей (и из-за этого приходится дополнительно напрягаться иногда). И не надо пробелов в именах. Названия типа name magazine тоже плохие, так как (на этом примере): 1. пробел вместо подчёркивания; 2. и так понятно, что магазин, по имени таблицы; 3. порядок в названии лучше более естественный; 4. это вообще-то магазин, а не журнал (см. выше) - короче, правильно просто name, даже не shop_name и уж тем более не name_shop. Вообще, это тот случай, когда уместен некоторый перфекционизм.
У покупателей часто бывает больше одного адреса: они могут заказывать домой, на работу, на дачу, в квартиру родителей итд. Имеет смысл также вынести в отдельную таблицу. Также часто выносят названия городов и областей в отдельные таблицы (словарь), а в адресе указываются id (через выпадающий список). Но если это учебная задача или проект небольшой, то можно не заморачиваться. Всё равно часто изменения таких вещей происходят с пониманием масштабов и специфики работы. Например, московские магазины могут при выборе Москвы предлагать улицу из списка, а при выборе подмосковных населённых пунктах - позволять вводить улицу вручную, так как база улиц каждого областного СНТ - это нереально.
Короче, улучшать можно почти до бесконечности. Особенно если дорасти до уровня всяких авито.
shurshur, абсолютно прав, докину свои предложения
- убери разделение ФИО по полям, в магазине и в чате нет никакой необходимости в этом, просто строки как зовут более чем достаточно
мало того на практике ФИО нужно только для заключения договора по доставке, чтобы проверяющий смог проконтролировать по документам принимающего и не выдать оплаченный товар левому чуваку - а это значит ФИО должно быть часть ордера, т.е. быть в таблице order
- нет нужды в чатах создавать отдельные диалоги, таблица chat(dialog) не нужна - чат лучше привязать к ордеру или лучше просто к пользователю, т.е. каждый пользователь только один чат, с какого бы браузера ты не зашел, с единой историей сообщений,.. можно в чат закидывать события с ордером (изменения статуса) не больше
- связь между корзиной ордером и товарами у тебя неправильная
есть ордер - это фактически корзина (каждый заказ на покупку это одна запись в таблицу order), т.е. тут поля дата и связь с user
есть список товаров в корзине, это связь M-M между order и product, у которой должно быть поле цена (фиксируется на момент создания ордера) и связи с order и product
есть продукты - это твой прайс лист на товары, можешь сюда добавить категорию (связь с таблицей категории) в 99% случаев такого двух уровневого списка более чем достаточно
- ордер должен иметь еще статус - не оплачен, оплачен, отдан на доставку, завершен, ошибка
события по ордеру (изменения статуса) можно хранить в доп таблице или просто докидывать спец сообщения в чат пользователя со сгенерироавнной ссылкой на ордер в интерфейсе, оба варианта имеют плюсы и минусы
- отзывы это сообщения пользователя на товары, поэтому тут нужна связь с product и user, дата, сообщение, оценка но у тебя там еще таблица магазинов есть (shop само собой) значит отзыв должен быть и на магазин, в таких случаях либо добавляют еще поле связь на order (т.е. shop_id и product_id могут быть null) либо заводят отдельно таблицы типа product_review и shop_review
Простой
