Есть задание - для диплома надо написать интернет-магазин по продаже компьютеров и комплектующих. Реализовать надо на php+mysql. Под это дело была разработана схема БД.
Какие проблемы могут быть при ее использовании?

SenjaТаблица "покупатели" лишена смысла. "Продавцы" - по большому счету тоже. Если надо хранить, является ли субъект продавцом или покупателем, добавьте пару флагов в таблицу "Субъекты"

Проект делается "на вырост" , поэтому я полагаю , что таблицы "покупатели" , "перевозчики" , "продавцы" лучше не объединять в "субъекты". Если появятся дополнительные требования к набору атрибутов по этим сущностям, то придется таблицу "субъекты" резать на части. Так лучше уж сразу...

SenjaИ перевозчиков - туда же. Можно сделать столбец "роль субъекта" и писать туда покупатель/продавец/перевозчик, конечно при условии что каждый субъект выполняет одну роль

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

SenjaВ таблице "заказаные товары" явно не нужен столбец "Название товара", а торговую марку наверное стоит перенести в товары. Также вызывает сомнение столбец "Цена товара"

В "заказаных товарах" должна сохраняться цена на момент подтверждения заказа , впоследствии цена может измениться . Торговая марка и название товара тоже должны быть такими , как
в подтверждении , отправленным покупателем.

SenjaДля таблицы "Значения атрибутотв" будет довольно таки неудобно контролировать целостность данных - понадобится триггер, который будет проверять принадлежность товара к нужному классу.

Да , придется делать именно так.
Таблицы "Классы товаров", "Атрибуты классов", "Значения атрибутов" нужны для реализации некоего подобия "модели Тенцера" (она же EAV). Целостность данных - это ее слабое место.

Ennor TiegaelЗарегистрированный пользователь может состоять только в одной роли. Это требование ТЗ?
Не уверен, что миграция поля "Номер класса" в первичный ключ таблицы атрибутов обоснована. Часто вам будет нужен список атрибутов товара без описания, какие именно это атрибуты? Так что не надо экономить на лишнем джойне, все равно не сэкономите.
Не вижу смысла делать таблицу атрибутов дочерней относительно таблицы классов. Иначе у вас получается, что атрибуты Длина-Ширина-Высота придется повторять для каждого класса, и логически их объединить никак не получится, кроме как хардкодом.

1) Зарегистрированный пользователь может состоять только в одной роли.
2) "Номер класса" я уберу ,пожалуй.
3) В "Атрибутах классов" хранятся описания (названия) атрибутов класса, в "Значениях атрибутов" - их значения для каждого товара из класса. Как их можно свести в 2 колонки без дочерней связи?
4) Атрибуты "Длина-Ширина-Высота" по ТЗ являются обязательными для каждого вида товаров, и могут быть разными у объектов одного класса , поэтому их место в таблице "Товары".

BelyАдрес:
1) если это интернет-магазин, то в адресе кроме почтовой составляющей должна быть возможность добавлять описание для курьерской службы (выйти из метро, налево 300 м, серое здание, 5 этаж)
2) Строение возможно только одно (либо корпус, либо строение). но бывают адреса вида: д.5, кор.4, стр. 6

3) не понял зачем нужны "Продавцы" и почему товары завязаны на продавцов?
Или один товар может продавать только один продавец?
В жизни это не так.

Зачем нужна отдельная таблица "Покупатели" - тоже не ясно.
Заказ можно прицепить напрямую к субъекту.

4) Не раскрыта тема "Платежей". Как будет платить человек: карточкой, наличными курьеру, WebMony, наложенным платежом на почте?

5) Структура ролей-разрешений - плохая.
Я бы добавил еще одну таблицу: ROLE_PERMISSION_LINK, чтобы один и тот же пермишен можно было добавить в разные роли.

Почему ресурсы сайта как-то завязаны с разрешениями - тоже не очень понятно.
что этим хотелось изобразить?

1-2) Спасибо . Переделаю.
3) Предполагается , что один и тот же вид товара могут продавать разные продавцы со своих складов по разным ценам . Покупателей с субъектами объединять не хочется. См. выше.
4) Тема "Платежей" еще прорабатывается.
5) А что будет, если создать связь "Ресурсы сайта - Роли пользователей" как "M:N" через таблицу "Разрешения" ? Число ресурсов не велико , число ролей тоже . Можно ведь расписать все права напрямую , без ACL ?

СлимаЦена товара предполагается неизменной?

В таблице "Товары" цена может меняться, в таблице "Заказанные товары" цена фиксируется на момент подтверждения заказа покупателем.

BelyIMHO - ресурсы это лишнее, а ACL проще сделать, чем потом извращаться.
Уговорили , буду делать ACL.

Слима
1. Предположим, 1 сентября на товар А была назначена цена 2000 р. По этой цене товар никто не покупал, и 10 сентября цена была снижена до 1800 р. Информация о том, что товар А с 1 по 10 сентября стоил 2000 р. будет утеряна.
2. С 1 октября на 1079 товарных позиций вводятся новые цены. Ввод новых цен осуществляется в ночь с 30 сентября на 1 октября, ровно в полночь. Иначе - никак.


1) Зачем на сайте хранить информацию , которая нигде не сайте используется ?
2) Спасибо за замечание. Введу атрибуты "Будущая цена" и "Дата установки новой цены" в "Товарах".