Я ищу более простое или элегантное решение в объектно-ориентированном (C #) или функциональном (F #) языке программирования для решения следующей проблемы.
Учитывая наличие тысяч продуктов со спецификациями на веб-сайте электронной коммерции, рассмотрите возможность изменения спецификации. В частности, каков наименьший набор спецификаций, которые дают различные наборы продуктов, которые могут заинтересовать клиента.
Пользователям предоставляется возможность делать покупки по любой спецификации. Например взять болты. У них есть размер сверла, отделка (обычная, цинковая и т. Д.), Тип головки, высота головки, класс, длина, количество упаковок и т. Д.
В средней товарной категории, скажем, 1000 товаров и 10 спецификаций. Если каждая спецификация может быть добавлена к URL, каковы возможные страницы. Тем не менее, я не просто заинтересован во всех перестановках. Рассмотрим следующие моменты:
- выбирая одну спецификацию, выбираются и многие другие, поскольку они совместно используются оставшимся набором продуктов и могут быть показаны пользователю веб-сайта, как и для перечисленных продуктов.
- если указан только один продукт, все остальные характеристики выбираются естественным образом
- помещая спецификацию в строгом порядке (например, в алфавитном порядке) в URL, это уменьшает ненужное повторение
Во-первых, проблема была решена с помощью рекурсивного SQL (синтаксис CTE), и это стало громоздким, приводя к миллионам комбинаций на категорию, прежде чем можно было начинать очистку дубликатов.
Теперь я исследую C #, который принимает категорию за раз.
1) типы спецификаций упорядочены по алфавиту
2) все наборы продуктов сравниваются со всеми остальными с помощью следующего кода для автоматического выбора / автоматического определения дополнительных характеристик:
public bool DefinesThisValue(CategoryValue value)
{
if (this.ProductIds.Count > value.ProductIds.Count) return false;
var intersect = this.ProductIds.Intersect(value.ProductIds);
return intersect.Count() == this.ProductIds.Count;
}
2) затем он пытается пройти все последовательности выбора, соблюдая вышеизложенное, после каждого выбора узел пути добавления является дополнением к объектам коллекции и пути копирования / разделения, если существует несколько дополнительных выбираемых спецификаций
Мое текущее решение требует много отладки и стало слишком сложным. Возможно, кто-то, знакомый с теорией множеств и F #, мог бы предложить что-то удивительное. Спасибо за ваше внимание.
В ответ Даниэлю приведен макет данных SQL.
СТРУКТУРЫ ДАННЫХ:
ТАБЛИЦЫ:
CREATE TABLE Category
(
Id int identity not null,
PRIMARY KEY CLUSTERED (Id)
)
CREATE TABLE Spec
(
Id int identity not null,
CategoryId int not null REFERENCES Category(Id),
Name varchar(100) not null,
PRIMARY KEY CLUSTERED (Id)
)
CREATE TABLE SpecValue
(
Id int identity not null,
SpecId int not null REFERENCES Spec(Id),
Value varchar(200) not null,
PRIMARY KEY CLUSTERED (Id)
)
CREATE TABLE Product
(
Id int identity not null,
PRIMARY KEY CLUSTERED (Id)
)
CREATE TABLE SpecValueProduct
(
Id int identity not null,
SpecValueId int not null REFERENCES SpecValue(Id),
ProductId int not null REFERENCES Product(Id),
PRIMARY KEY NONCLUSTERED (Id)
)
Простой пример может включать следующие данные примера:
Product 1: Coffee Maker A, Color: Black, Cups: 2
Product 2: Coffee Maker B, Color: Black, Cups: 4
Product 3: Coffee Maker C, Color: Grey, Cups: 4
В этом примере, если выбран Цвет: Серый, то также определяется Чашки: 4. Но, если выбран Цвет: Черный, пользователь может выбрать Чашка: 2 или Чашки: 4.
URL может выглядеть так: 'site.com \ кофеварки? Color = Black & Cups = 4