Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 можно ли сделать лучше  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 2040
в общем проблема в том как я вижу решение, есть таблица товара, есть таблица справочник свойств, есть таблица справочник значении свойств и еще одна таблица для связи товар - значение свойства
TABLE [dbo].[Product](ProductId] [int] IDENTITY(1,1) NOT NULL,	[Name] [nvarchar](255) NOT NULL)
TABLE [dbo].[MapProductPropertyValue]([ProductId] [int] NOT NULL,[PropertyValueId] [int] NOT NULL)
TABLE [dbo].[Property]([PropertyId] [int] IDENTITY(1,1) NOT NULL, [Name] [nvarchar](100) NOT NULL)
TABLE [dbo].[PropertyValue]([PropertyValueId] [int] IDENTITY(1,1) NOT NULL,[PropertyId] [int] NOT NULL,[Value] [nvarchar](255) NOT NULL)

задача сделать в клиентке уточняющий фильтр, к примеру выбрали свойство "цвет" со значениями "белый" и "черный" , а также выбрали свойство размер "46" и я вижу решение через intersect
select * from dbo.Product where productId in ( select productId from  dbo.MapProductPropertyValue where PropertyValueID in ('белый','черный')
intersect select productId from  dbo.MapProductPropertyValue where PropertyValueID in ('46') и т.д.
)

но я думаю чем больше будет выбранных свойств тем будет хуже с intersect, т.к. ограничения на кол-во выбранных свойств нет. Подскажите можно ли как то по другому решить задачу,может организовать таблицы по другому?
п.с. в запросах "PropertyValueID in" естественно id значений.
14 окт 13, 00:09    [14964170]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
Baal
Member

Откуда:
Сообщений: 44
select * from dbo.Product as p
inner join dbo.MapProductPropertyValue p1 on (p.productId = p1.productId and p1.PropertyValueID in ('белый','черный'))
inner join dbo.MapProductPropertyValue p2 on (p.productId = p2.productId and p2.PropertyValueID in ('46'))
и т.д.
14 окт 13, 08:27    [14964543]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
qwerty112
Guest
select p.[ProductId], p.[Name]
from [dbo].[Product] p
inner join [dbo].[MapProductPropertyValue] mppv
  on p.[ProductId]=mppv.[ProductId]
inner join [dbo].[PropertyValue] pv
  on mppv.[PropertyValueId]=pv.[PropertyValueId]
where pv.[PropertyId]=@PropertyId1 and pv.[Value] in ('белый','черный')
   or pv.[PropertyId]=@PropertyId2 and pv.[Value] in ('46')
group by p.[ProductId], p.[Name]
having count(distinct pv.[PropertyId])=2
14 окт 13, 10:01    [14964848]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
Baal
Member

Откуда:
Сообщений: 44
qwerty112,

Это если значение свойства для продукта только одно.
14 окт 13, 11:45    [14965640]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
qwerty112
Guest
Baal
qwerty112,

Это если значение свойства для продукта только одно.

having count(distinct pv.[PropertyId])=2

вопросы ?
14 окт 13, 11:51    [14965690]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
Baal
Member

Откуда:
Сообщений: 44
qwerty112,

Нету. Пропустил.
14 окт 13, 12:36    [14966098]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 2040
спасибо. я попробую предложенные варианты.
14 окт 13, 13:49    [14966759]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
Cygapb-007
Member

Откуда:
Сообщений: 1677
вот тут: Вредные советы по SQL (часть 2)
такое решение квалифицируется как "вредное" (совет № 3)
14 окт 13, 17:34    [14968662]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 2040
Cygapb-007,
по моему вы не правы так как у меня есть 4-я таблица, которая решает все минусы в указанной ссылке
14 окт 13, 19:30    [14969239]     Ответить | Цитировать Сообщить модератору
 Re: можно ли сделать лучше  [new]
Cygapb-007
Member

Откуда:
Сообщений: 1677
Четвертая таблица делает схему работоспособной. Минусов она не снимает.

Повторю аргументацию

За:
  • Универсальное решение
  • Отлично масштабируется

    Сложно ответить на вопросы:
  • Как обработать разные атрибуты в одном запросе (как раз обсуждаемый случай)
  • Как обеспечить целостность данных
  • Как обеспечить наличие всех обязательных атрибутов у продукта (NOT NULL)
  • Какой типы у атрибутов
  • Где внешние ключи
  • Как контролировать правильность названий атрибутов (например, реально набрано "чёрный")
  • Как восстановить "эталонную" таблицу ("товар-список атрибутов")

    развернутое обсуждение - по приведенной ранее ссылке
  • 15 окт 13, 09:48    [14970885]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31948
    handmadeFromRu
    но я думаю чем больше будет выбранных свойств тем будет хуже с intersect, т.к. ограничения на кол-во выбранных свойств нет. Подскажите можно ли как то по другому решить задачу,может организовать таблицы по другому?
    Нет, по сути сколько параметров, столько и пересечений множеств нужно найти, это же естественное следствие модели EAV.
    15 окт 13, 10:03    [14970989]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    handmadeFromRu
    Member

    Откуда: родина Ленина!
    Сообщений: 2040
    я понимаю может я не компетентен но:
    Cygapb-007
    Как обработать разные атрибуты в одном запросе (как раз обсуждаемый случай)

    обрабатываются не значения а id
    Cygapb-007
    Как обеспечить целостность данных

    все завязано на связывание ключей и проблем нет
    Cygapb-007
    Как обеспечить наличие всех обязательных атрибутов у продукта (NOT NULL)

    в моей задаче если нет обязательные атрибуты, просто они либ есть ли б нет
    Cygapb-007
    Какой типы у атрибутов

    опять ж в моей задаче тип не важен, важно отобразить пользователю, он выберет, а поиск по id
    Cygapb-007
    Где внешние ключи

    4 таблица решает это (MapProductPropertyValue)
    Cygapb-007
    Как контролировать правильность названий атрибутов (например, реально набрано "чёрный")

    легко так как выбирается связка из справочника
    Cygapb-007
    Как восстановить "эталонную" таблицу ("товар-список атрибутов")

    а что сложного ?

    alexeyvg,
    а есть альтернатива?
    15 окт 13, 14:37    [14973295]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31948
    handmadeFromRu
    alexeyvg,
    а есть альтернатива?
    Альтернатива модели EAV?

    Ну конечно, это обычная модель данных.

    Естественно, у неё тоже есть недостатки, так что нужно выбирать между сложным поиском в EAV и сложной моделью без EAV

    Выбор зависит от бизнес-задачи.

    Непонятно, у вас в бизнес-задаче для каждого продукта свой уникальный набор свойств? Или есть группы продуктов со своим набором?

    Далее, у вас запросы неправильные и сильно упрощены, почему это вы пишите "where PropertyValueID in ('белый','черный')", тогда как PropertyValueID - это целое IDENTITY поле?

    Вообще непонятно, почему выбрана такая схема, а не классический EAV?
    18 окт 13, 16:40    [14999417]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    handmadeFromRu
    Member

    Откуда: родина Ленина!
    Сообщений: 2040
    alexeyvg,вы не внимательны, у меня там именно числа, смотрим первый пост. написал значения для понимая
    handmadeFromRu
    п.с. в запросах "PropertyValueID in" естественно id значений.


    alexeyvg
    Непонятно, у вас в бизнес-задаче для каждого продукта свой уникальный набор свойств? Или есть группы продуктов со своим набором?

    да можно наборы делать, можно делать уникальные. В общем понял за универсально придётся платить именно так.
    19 окт 13, 13:39    [15002025]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31948
    handmadeFromRu
    alexeyvg,вы не внимательны, у меня там именно числа, смотрим первый пост. написал значения для понимая
    handmadeFromRu
    п.с. в запросах "PropertyValueID in" естественно id значений
    Да, действительно пропустил...

    handmadeFromRu
    alexeyvg
    Непонятно, у вас в бизнес-задаче для каждого продукта свой уникальный набор свойств? Или есть группы продуктов со своим набором?

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

    Например, в яндекс-маркете есть некое количество групп товаров. У каждой группы есть набор свойств, пользователь может отобрать товары по значению атрибутов только внутри группы (нельзя отобрать товары с атрибутом "размер" = 50 дюймов одновременно из групп "телевизоры" и "окна")

    Можно так же делать гибрибную модель, делая такие таблицы как кеширующие для поиска, получая значения и структуру из EAV
    19 окт 13, 19:53    [15002858]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    гневный_оптимизатор
    Guest
    handmadeFromRu

    Вот сейчас я е$$сь с такой же схемой, чтобы сформировать элементарные отчеты, только в моем случае все еще печальнее. Автор я бы проделал в вас половую щель и е$$л бы до тех пор, пока вы бы не осознали масштабов п$$$$ца.
    19 окт 13, 20:01    [15002885]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31948
    гневный_оптимизатор
    handmadeFromRu

    Вот сейчас я е$$сь с такой же схемой, чтобы сформировать элементарные отчеты, только в моем случае все еще печальнее. Автор я бы проделал в вас половую щель и е$$л бы до тех пор, пока вы бы не осознали масштабов п$$$$ца.
    Ну, если есть такое бизнес-требование - у каждого элемента может быть свой произвольный и неограниченный набор свойств, то что делать? :-(

    Другое дело, что часто "произвольный и неограниченный" этот набор не в бизнесе, а только в головах программистов.
    19 окт 13, 21:40    [15003164]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    гневный_оптимизатор
    Вот сейчас я е$$сь с такой же схемой, чтобы сформировать элементарные отчеты
    Большинство "разработчиков" (которые я встречал) - проходимцы. Ну в смысле они никогда не видят сделаную ими систему после сдачи проекта.
    Ну, а если надо что-то допилить, то пишется на скорую руку костыль.

    Хотишь понимающего своё дела разраба - спроси сколько лет он поддерживал и модифицировал очень активные системы.
    Но и этого мало.

    alexeyvg
    "произвольный и неограниченный" этот набор не в бизнесе, а только в головах программистов
    Да не только, и в бизнесе тоже. Предметную область в целом бывает что вообще никто не видит и не знает.

    Вообще детальное и обзорное мышление - редкость. Возможно это вообще "болезнь".
    19 окт 13, 22:44    [15003320]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    handmadeFromRu
    Member

    Откуда: родина Ленина!
    Сообщений: 2040
    гневный_оптимизатор,
    да я смотрю вы не адекват..я чтоль виноват что вы паритесь? себя в уголке е.

    тема затеяна чтоб направить в нужную сторону. и да я уже эту систем 4 год поддерживаю, и видел все проблемы со скоростью в запросах и прочее, но чертов маркетинг и клиенты хотят.
    20 окт 13, 11:04    [15003977]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    handmadeFromRu
    но чертов маркетинг и клиенты хотят.
    Вообще-то ни маркетинг ни клиенты тут совершенно не причём.
    Это IT решение. И EAV это одно из возможных решений для динамических параметров.
    21 окт 13, 12:17    [15007224]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    Александр Бердышев
    Member

    Откуда: Санкт-Петербург
    Сообщений: 400
    handmadeFromRu
    ограничения на кол-во выбранных свойств нет


    В этой ситуации поступил бы так:
    1. Оформил процедурой
    2. Завёл бы 2 временных таблицы:
    #Result - с результатами отбора
    #RequestParam - с условиями. В ней храним значение с условием для отбора и тип поиска по этому условию: "ИЛИ" или "И"

    3. Курсор по таблице с условиями. Сначала проходимся по всем условиям "ИЛИ" и по каждому условию отбираем данные в таблицу результатов, если там этих данных ещё нет. Потом проходимся по условию "И" - выкидываем из таблицы результатов лишнее.
    Если условий "ИЛИ" нет - то первый проход должен быть с условием "И" по таблице с данными, а потом так же опять по таблице с результатами отбора ходим.

    Плюсы такого подхода: вообще нет ограничения на кол-во выбранных свойств. Не надо ,как с динамическим SQL, пытаться всё впихнуть в 4000 символов.
    Минусы такого подхода:
    1. Использование курсора. Хотя здесь курсор не по таблице с данными, а по таблице с условиями - скорее всего их не будет много, так что и минус не особо ощутимый.
    2. Для каждого условия с "ИЛИ" надо делать полный проход по большой постоянной таблице и по временной таблице с результатами - это очень плохо, долго будет работать.
    21 окт 13, 14:52    [15008545]     Ответить | Цитировать Сообщить модератору
     Re: можно ли сделать лучше  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31948
    Александр Бердышев
    Плюсы такого подхода: вообще нет ограничения на кол-во выбранных свойств. Не надо ,как с динамическим SQL, пытаться всё впихнуть в 4000 символов.
    Не буду комментировать это абсурдное "решение", но заинтересовали слова про "впихнуть в 4000 символов". Размер запроса ограничен 256 мегабайтами, разве нет?
    21 окт 13, 15:58    [15009168]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить