Я проектирую базу данных с нуля из производственных продуктов. Ключевой дизайн выглядит следующим образом:
(В настоящее время я работаю над MS Access 2007, но моей последней реализацией является SQL Server, то есть SQL Server 2008, являющийся последней версией. Кроме того, я буду использовать только Express Edition в этом движении. Приложение будет использовать витрину .NET, сопряженную с этой базой данных).
[1]. Каждый товар можно разделить на несколько категорий.
(Я решил предположить, что если у продукта нет категории, я принудительно вставлю категорию с именем «ПУСТО», вместо того, чтобы называть ее НЕДЕЙСТВИТЕЛЬНОЙ, таким образом я могу добавлять категории к продукту в будущем при необходимости )
1 Товар может иметь много категорий.
1 категория может принадлежать более чем 1 продуктам.
Категории могут также быть изменены, чтобы принадлежать другому продукту в будущем.
[2]. Каждая категория продуктов может быть разделена на различные подкатегории.
(Опять же, я решил предположить, что если категория продукта не имеет подкатегории, я принудительно вставлю подкатегорию с именем BLANK, а не NULL, таким образом я могу добавить подкатегории в категорию продукта. в будущем, если потребуется)
1 Категория продукта может иметь много подкатегорий.
1 подкатегория может принадлежать более чем 1 категории продукта.
Подкатегории также могут быть изменены, чтобы в будущем принадлежать к другой категории продуктов.
[3]. Каждый продукт будет иметь различное количество атрибутов.
Каждый атрибут будет иметь разные значения атрибута
Значения некоторых атрибутов будут зависеть от значений других атрибутов
Значения некоторых атрибутов, которые могут не зависеть напрямую от значения других атрибутов, все равно будут косвенно зависеть от доступности значений других атрибутов.
Дизайн, который я разработал, выглядит следующим образом:
0000_Product_Line
ProductLineID (ПК)
ProductLineName
0001_Product_Line_Category
ProductLineCategoryID (ПК)
ProductLineCategoryName
0002_Product_Line_Category_Association
[PK] ProductLineID (FK ссылается на ProductLineID из таблицы 0000_Product_Line)
[PK] ProductLineCategoryID (FK ссылается на ProductLineCategoryID из таблицы 0001_Product_Line_Category)
0003_Product_Line_Sub_Category
ProductLineSubCategoryID (ПК)
ProductLineSubCategoryName
0004_Product_Line_Category_And_Sub_Category_Association
[PK] ProductLineCategoryID (FK ссылается на ProductLineCategoryID из таблицы 0001_Product_Line_Category)
[PK] ProductLineSubCategoryID (FK ссылается на ProductLineSubCategoryID из таблицы 0003_Product_Line_Sub_Category)
0005_Product_Line_Attributes
AttributeID (ПК)
Имя_атрибута
0006_Product_Line_Attribute_Values
[PK] AttributeID (FK ссылается на AttributeID из таблицы 0005_Product_Line_Attributes)
[PK] AttributeValues
0007_Product_Line_Attributes_Association
[PK] ProductLineSubCategoryID (FK ссылается на ProductLineSubCategoryID из таблицы 0003_Product_Line_Sub_Category)
[PK] AttributeID (FK ссылается на AttributeID из таблицы 0005_Product_Line_Attributes)
Теперь самые большие проблемы, с которыми я сталкиваюсь, это как мне управлять атрибутами для различных продуктов (наконец, подкатегорий продуктов, поскольку я сопоставляю все с подкатегориями продуктов, потому что даже если продукт имеет или не имеет категорию или подкатегорию, я все равно буду принудительно введите ПУСТО (категория и подкатегория)
Предположим, у меня есть следующие значения:
Линия продуктов:
A
B
Категории продуктов
A A1
A A2
A A3
B B1
B B2
Линия продуктов подкатегории
A A1 a
A A1 b
A A1 c
A A2 x
A A2 y
B B1 м
B B1 n
B B2 p
B B2 q
B B2 r
Атрибуты
att1
att2
att3
b att2
b att4
c att1
c att3
c att4
x att2
x att3
y att4
y att5
m att3
m att7
n att1
n att7
p att2
p att3
p att5
q att4
q att6
r att1
r att6
Значения атрибутов
att1 Значение1
att1 Значение2
att1 Значение3
att2 Value1
att2 Value2
att2 Value3
att2 Value4
att3 Value1
att3 Value2
att4 Value1
att4 Value2
att4 Value3
att4 Value4
att4 Value5
......
Now Например: att1 и att2 связаны Так, если пользователь выбирает значение для att1, он определяет, какие все значения att2 должны быть доступны дляпользователь Аналогичным образом, если пользователь выбирает значение для att2, он определяет, какие все значения att3 должны быть доступны пользователю
Не существует иерархии, которая, если att1 и att2 связаны, пользователь должен сначала выбрать att1 и att2.далее ИЛИ Viceversa Пользователь может выбрать значение для att1 ИЛИ att2, и оно должно отфильтровать остальные
Другой пример: att2 и att3 и att4 связаны. Так что, если пользователь выбирает значение для att2, он будет определять, какие все значения для att3 и att4 должны быть доступны для пользователя.Аналогично, если пользователь выбирает значение для att3, он будет определять, какие все значения для att2 и att4 должны быть доступны пользователю.Аналогично, если пользователь выбирает значение для att4, он будет определять, какие все значения для att2 и att3 должны быть доступны пользователю.
Здесь также нет иерархии, которая, если att2 и att3 и att4 связаныпользователь должен сначала выбрать att2, а затем att3, а затем att4, ИЛИ наоборот. Пользователь может выбрать значение для att2, ИЛИ att3 ИЛИ att4, и он должен отфильтровать другие связанные атрибуты
Как мне установить связь между различнымиатрибуты, чтобы мой фильтр, используя предложение, где будет работать должным образом?Если бы все они были столбцами, я мог бы легко использовать group by, но это строки.
Я провел много исследований в Интернете и предложил следующие варианты: 1. Использовать одну большую таблицу для всех продуктов.и их атрибуты.Но размер этой таблицы будет очень велик с бесчисленными нулевыми значениями в различных столбцах, и это не соответствует цели, так как чтение с использованием селекторов сильно повлияет на производительность.
Используйте разреженные столбцы в SQL Server 2008, чтобы избежать влияния нулевых значений.Однако, хотя разреженные столбцы сохраняют пространство для значений, которые являются нулевыми, им требуется больше, чем обычное пространство хранения для значений, которые не являются нулевыми.Кроме того, размер таблицы по-прежнему огромен, и неисчислимые столбцы влияют на производительность чтения.
Я должен использовать XML для хранения данных.Я не уверен в том, как бы я это реализовал и какие у него были бы преимущества или недостатки.
Я должен разбить его на отдельные небольшие таблицы для каждой подкатегории, представляющие только свои атрибуты в виде столбцова не весь продукт или его категорию.Тогда я бы передал имя таблицы в качестве параметров в код моего приложения.Однако это будет иметь проблему инъекции SQL.Решение будет использовать хранимую процедуру с параметризованными запросами.Однако на производительность все равно будет влиять то, что ядро базы данных не сможет оптимизировать планы запросов для таких запросов, где объединения выполняются только для достижения подкатегории, но после этого имя таблицы вызывается параметром, передающим подкатегорию.
Я должен написать SQL-запросы, чтобы подготовить представление каждой подкатегории, представляющей ее собственные атрибуты (вместо того, чтобы иметь отдельную таблицу для каждой подкатегории). Однако для создания представлений мне нужно где-то хранить отношения, потому что некоторые атрибуты зависят друг от друга напрямую на основе значений, а некоторые атрибуты косвенно зависят друг от друга на основе доступности значений. Таким образом, у меня будет эта таблица атрибутов и значений (как я уже разработал), а затем мне понадобится таблица рекурсивных отношений «многие ко многим». Но эта таблица рекурсивных отношений «многие ко многим» будет очень большой, и количество выполненных самосоединений существенно повлияет на производительность. Также снова необходимо будет передать имя представления в качестве параметра динамической SQL или параметризованной хранимой процедуре.
Последним вариантом, с которым я столкнулся, был дизайн базы данных EAV, который имеет свои плюсы и минусы, включая написание сложных запросов, а также мониторинг производительности самостоятельно, потому что ядро базы данных не может оптимизировать планы запросов для такой базы данных. Кроме того, такая база данных EAV теряет большую часть своей реляционной сущности, и ограничения на различные значения трудно применить, что потребует большого количества триггеров.
Я не уверен, что будет лучшим вариантом для разработки моей базы данных.
База данных будет в основном доступна по запросам SELECT через приложение. Любая вставка для продукта или его категории или подкатегории, или его атрибутов или значений будет производиться путем ввода данных. (Прямые вставки будут сделаны для регистрации клиентов и поставщиков / производителей продуктов, которые, как я предполагаю, в данный момент будут отдельной базой данных. Затем мне потребуется разработать какое-то отображение, чтобы сопоставить поставщиков / производителей с продуктами, которые они предоставляют, или производство)
Пользователи смогут фильтровать до подкатегории, выбирать значения атрибутов и покупать продукт онлайн.
Также существует необходимость в фильтре (под фильтром, я имею в виду запросы с использованием условия where), когда пользователь не будет знать, какой продукт ему нужен, поэтому он выберет атрибуты, по которым он хочет отфильтровать, и он должен соответствовать одному. из подкатегорий и, наконец, пользователь должен иметь возможность выбрать значения для атрибутов.
Я действительно смущен тем, как реализовать свою базу данных, и сталкиваюсь с множеством проблем, будучи одиноким в команде ИТ в небольшой компании.
Любая помощь от всех вас будет высоко оценена и оценена как огромный актив.