Алексей Кулаков

Быстрым взглядом окинул вашу схему.
1) есть одно правило при построении ER-моделей, звучит оно как-то так "мертвые вороны летят на восток". смысл его в том что таблицы располагаются на диаграмме так что справочники и редко изменяемые таблицы скапливаются в правом нижнем углу, а, соответственно, наиболее изменяемые таблицы в левом верхнем. Если следовать этому правилу читаемость диаграммы базы данных улучшается в разы. Пример:

2)User. по правилам модель доводят до 3,5НФ (или Нормальная форма Бойса-Кодда).(Список нормальных форм). Так вот таблица User не нормализована должным образом.

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

3) Product. Обычно продукт это некоторая номенклатура, то есть описание свойств товара, его названия и прочего. Цена в него не входит. Что вы будете делать если придут продукты из разных партий и закупочная цена у них будет разная? Ваша модель этого не отражает. обычно есть некий прайс-лист в котором есть соответствие продукта и цены. прайс-листы в реальной жизни могут меняться и имеют дату на которую этот прайс-лист действителен. Тогда обозначенной мной ситуации не будет. Прайс лист оформляется как минимум двумя таблицами - собственно прайс-листом с общими параметрами как дата создания, составитель ect. и табличной частью, где записаны позиции всех прайс-листов (с ссылкой конечно же) с указанием продукта и его стоимости по конкретному прайс-листу. Валюту можно указать как в конкретных позициях прайс-листа так и глобально на прайс-лист.

"Для всех страниц страниц, таблица url является родителем, хотелось бы что бы удаляя например товар удалялся урл, сейчас на оборот."
Не совсем понял. у кого у всех? думаю у mysql есть настройки внешних ключей OnUpdate, OnDelete. можно через них организовать корректное удаление.

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

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

Упрямство это хорошо, но когда более опытный человек говорит вам это не правильно спроектированно, то стоит прислушиваться и не набивать кучу шишек на простых вещах.

Есть несколько Нормальных форм для баз данных. Каждая из них убирает некую избыточность. Минимум база должна соответствовать 3-ей нормальной форме, почитайте про 1НФ, 2НФ, 3НФ и 3,5НФ (или нормальная форма Бойса-Кодда или НФБК). Иногда проводят денормализацию, но для этого нужно понимать для чего и в каких случаях это делается.

Теперь о вашей структуре таблиц.
В вашем случае есть некий товар, есть категории (или группы, ваши видеокарты, кулеры и бог знает что еще) товаров. Вот вам две таблицы - Товар, Категория товара. Ну и связь между ними конечно же один ко многим так, что одной категории соответствует множество товаров, но один товар всегда соответствует одной категории. Если товар может быть в нескольких категориях (связь многие ко многим), то это делается через дополнительную таблицу. Итого имеем удобство добавления новых категорий товаров - добавляем новую категорию и при добавлении товара указываем к какой категории он относится. какие-нибудь теги тоже можно по такой же схеме организовать.

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

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

Свойства товаров, как сказали, можно хранить в json или в xml, но это не удобно для фильтров каких-нибудь да и добавлять/редактировать значения свойств как-то не удобно - загрузи, десериализуй, измени/добавь, сериализуй и сохрани. Если они никогда не меняются и по ним нет поиска, то я бы сохранил как сериализованный в json или xml объект. Иначе тоже через таблицы, связанные с товаром связью. тут можно накрутить много, и группы свойств для каждой категории и всякое другое.