В соответствии с тем, что описал Гилберт Ле Блан, вы можете сделать это более масштабируемым и эффективным следующим образом:
A. Каждый раз, когда вы обнаруживаете, что добавляете столбцы для элементов, представляющих возможные варианты выбора пользователя, подумайте, должны ли они быть смоделированы как строки в новой таблице. Это называется «нормализация» (это еще не все, но для этой цели она должна охватывать то, что я пытаюсь сказать ...) и является ключом к правильному проектированию базы данных. Если вы не сможете нормально нормализоваться, вы будете испытывать сильную боль и сожаление в будущем. Представьте, что один из ваших поставщиков представляет новый цвет через 6 месяцев после запуска вашей базы данных. Вам нужно будет перекодировать свои процедуры доступа к данным, чтобы добавить этот цвет в любую внешнюю презентацию, которую вы создаете.
B. Возможно, вы захотите объединить некоторые из вашей категории / подкатегории / структуры классов в одну или две таблицы. Хотя у меня нет конкретного предложения, не зная больше о бизнесе розничной торговли, кажется, что в зависимости от продукта может быть любое количество иерархических элементов. Теоретически, вы могли бы получить одну таблицу для этого:
**tblCategories**
CategoryID Int PK
ParentCategoryID Int FK on tblCategories CategoryID
CategoryName
Записи с ParentCategoryID> 0 являются подкатегориями.
Я собираюсь попытаться прикрепить изображение (я не делал этого здесь на SO ранее) того, что я только что описал. Предостережения:
Я работаю в SQL Server, поэтому все может выглядеть немного иначе.
Я упростил модель для целей этого примера. Но это иллюстрирует отношения, которые я описываю.
Могут быть и другие с лучшими предложениями для моделирования Продукта / Категории. Концепция, которую я представил, может быть сложной, чтобы держать ее в голове, но использует рекурсивные отношения для создания очень гибкой / масштабируемой структуры таблицы.
Я думаю, вы на правильном пути. Тем не менее, есть некоторые области для (потенциально) значительного улучшения вашей нормализации. Я говорю потенциально, потому что я не знаю достаточно о бизнесе спортивной одежды, размере и тому подобном. Однако некоторые наблюдения:
A. Я вижу одни и те же сущности, представленные в нескольких разных таблицах, то есть Nike, Adidas и т. Д. Хотя я понимаю, что у одного поставщика может быть несколько разных брендов, структура вашей таблицы может прояснить это. Если «Nike» является поставщиком, то возможные бренды Nike могут быть Nike, Converse, какими бы ни были другие бренды Nike. Если это то, что делает твой стол, то прости.
B. Ваша таблица размеров одежды может иметь некоторый потенциал для дополнительной нормализации, а может и нет. Кажется сложным, и опять же, я недостаточно знаю об отношениях, представленных там. Я действительно вижу, что, как представляется, повторение данных в полях, которые могут быть лучше представлены в виде строк в других таблицах.
C. Пример того, что я описываю в Б., можно привести с размером обуви. ЭТО можно нормализовать более эффективно. Обратите внимание, что я довольно произвольно поместил FK для GenderCategory в tblFootwear_Sizing_Index, он МОЖЕТ принадлежать к tblFootwearSizes. Опять же, не знаю достаточно об обувной промышленности. Но помимо этого спора, вы найдете следующую схему более эффективной и управляемой:
В вашей модели есть и другие области, которые могут подражать реструктуризации. Однако, как я уже сказал, мне становится трудно это видеть, учитывая мое незнание вашей отрасли. Я ВСЕ ЕЩЕ думаю, что вы, возможно, захотите пересмотреть множество разновидностей «Категория» и «Класс». Кроме того, вам определенно следует найти более описательные имена для некоторых из этих таблиц категорий / классов (или любой таблицы, на самом деле). Подумайте о «ProductCategory», «GenderCategory», «FootwearCategory» и т. Д. Кроме того, не бойтесь слишком длинных имен таблиц, если вам будет легче (или, что более важно, ваш преемник сформируется через четыре года), чтобы понять происходит в вашем коде. Возможно, печатать сейчас будет более обременительно, но через 6 месяцев после запуска, и вы пытаетесь выяснить, почему один из ваших запросов не возвращается так, как ожидалось, вы будете рады, что сделали это. В конце концов, вы всегда можете использовать псевдонимы таблиц в общем использовании.
Я настоятельно рекомендую проверить некоторую информацию о нормализации базы данных, а затем попробовать применить ее к вашей модели. Правильно подобранная модель БД прямо из Jump может создать или сломать ваше приложение. Вот одна из многих статей, которые я получил, прибегая к помощи «Нормализации базы данных»:
http://databases.about.com/od/specificproducts/a/3nf.htm
Эта статья посвящена третьей нормальной форме (3NF), но содержит ссылки на 1NF и 2NF, которые являются предварительными условиями для 3NF.
Вы всегда должны стремиться к минимуму 3NF в дизайне базы данных.
Надеюсь, что это поможет, и я хотел бы услышать, как вы продвигаетесь в этом.