Какая схема MySQL наиболее элегантна для продуктов, опций и категорий?

Question

Я работал с дюжиной шаблонных систем (Zen Cart, Cube Cart и т. Д.).У каждого из них есть свой причудливый способ структурирования продуктов, опций и категорий.Все дополнительные функции приводят к ситуации со стеком карточек McGuyver, что делает работу с кодом очень сложной задачей.

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

Примечания:
option_types = цвета, размеры, материалы
options = красный, белый, синий, S, M, L, хлопок, спандекс, кожа

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

Answer 1

Вот мои заметки / мнения по этому вопросу. У вас нет кардиналов, но я сделаю все возможное, чтобы угадать их.

• Categories в порядке.

• Удалите id из item_categories, поскольку вы его не используете. Создайте составной первичный ключ для category_id и item_id.

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

Какой поиск вы бы сделали по этому идентификатору? Запросы, которые вы запустите: «Получение всех категорий для элемента» и «Получение всех элементов для категории». Я не понимаю, почему было бы безопаснее удалить. Тем не менее, я бы сказал, что добавление id может быть небезопасно для вставки, поскольку у вас могут быть разные идентификаторы, но одинаковые пары category_id и item_id. Вы должны будете проверить ограничения там и убедиться, что пары уникальны (и разве это не то, к чему привыкли PK?)

• items в порядке ... (см. Комментарии ниже)
• Удалить id из item_options (тот же случай, что и выше и см. Комментарии ниже)
• option_types в порядке

Теперь я думаю, что взаимосвязь предметов и опций потребует больше размышлений. Кажется, это отношения многие ко многим. Поскольку предмет, например футболка, может иметь много размеров, имеет смысл сказать, что каждая пара предметов и вариантов должна иметь разный размер. Но что происходит, когда помимо размера у вас также есть другой материал, например хлопок и кожа. У вас будет информация о парах хлопок-S, хлопок-М, хлопок-L и кожа-S, кожа-М и кожа-L. Это имеет смысл, так как я уверен, что все они будут иметь разную цену и вес. Но теперь давайте добавим 2 цвета к нашим футболкам. Вам нужно будет добавить цену и вес для каждой из 12 комбинаций, которые у нас сейчас будут.

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

Просто несколько необработанных мыслей перед сном:

• option_types может быть какая-то иерархия
• Тщательно подумайте, как бы вы справились с stock, учитывая этот дизайн У вас будет 10 предметов для Черной футболки ... но сколько предметов у вас будет для Черной кожаной футболки? Как это число связано с 10 оригинальными?

Answer 2

Таблица параметров Я бы добавил значение под именем.то есть черный L черный M черный S синий L синий M синий S и т. д. как ответ на идею Мости.