Э-э-э-э, вы щас научите мол чела!
Вот так:
SELECT g.Good_id
FROM Goods g
KEY JOIN Goods_Properties gp1
KEY JOIN Goods_Properties gp2
WHERE
gp1.Property_id = '0006' AND gp1.PropertyValue = 'red' AND
gp2.Property_id = '0007' AND gp2.PropertyValue = '10x10';Будет тормозить.А
вот так:SELECT gp1.goods_id as g
FROM Goods_Properties gp1,Goods_Properties gp2WHERE
gp1.Property_id = '0006' AND gp1.PropertyValue = 'red' AND
gp1.good_id=gp2.good_id AND
gp2.Property_id = '0007' AND gp2.PropertyValue = '10x10'group by g;Не
будет. Поверьте мне при такой структуре самый производительный
вариант.Почему так утверждаю? Потому что у самого реализована на АСА система
полнотекстового поиска.И там использована аналогичная структура хранения
данных, ведь в каждом тексте имеется заранее неопределенное кол-во
слов(словоформ), как и здесь разное кол-во атрибутов у товаров. Перепробовал
множество вариантов, в том числе и с использованием INTERSECTа, EXISTа,
DISTINCTа, вложенных запросов.И только в приведенном выше варианте будет
нормально работать оптимизатор, и будут использованы индексы
(подразумевается что goods_id и property_id есть ПК).В моем случае все
усугублялось еще и тем, что использовался динамический SQL, и кол-во
экзепляров таблицы свойств товара было переменным(gp1, gp2, ... gpN). И даже
с динамическим SQL все нормально функциклирует.


Posted via ActualForum NNTP Server 1.3

При всем уважении к вам ребята, не могу не ответить.
MasterZiv: Я говорю про АСА, поэтому спорить с Вами даже и не собираюсь. В прошлый раз Вам доказал, что на счет АСА Вы ошиблись, в этот раз тоже самое будет.

ASCRUS:
В который раз убеждаюсь, что Вы относитесь с предвзятым отношением к высказываниям большинства участников форума. И занимаете позицию "Я тут самый главный и умный".

По существу:
1) Я в своем высказывании указал, что мои выводы являются результатом практической работы(т.е. не являются никаким гаданием, тем более на гуще).

2) Также в своем утверждении я указал, что направление, заданное ASCRUS, при выборе вида селекта является самым правильным, за исключением наличия третьей таблицы Goods. И отличие моего селекта - это отсутствие сканирования таблиц, полное отсутствие. А при связи через третью таблицу (как у ASCRUS) и отсутствии индекса по свойствам естественно будет сканирование, вот и разница.

3) Группировку следует вводить только в случае, когда у одного товара, может быть несколько значений одного свойства. Если (Товар,свойство) уникальная пара, то группировку нужно исключить.

4) ASCRUSMasterZiv: в ASA 9 запрос с 2 EXISTS в WHERE будет равнозначен моему запросу с 2-мя JOIN-ами.
Что значит равнозначен? По результату? Или по плану?
По результату да. По плану нет.

5) ASCRUSразличные варианты записи одних и тех же запросов на уровне оптимизатора будут иметь одинаковый план запроса - на моей памяти это утверждение верно всегда, кроме случая использования подзапроса в SELECT (т.е. SELECT (SELECT ...) FROM ...), который будет всегда выводится оптимизатором в плане запросов как Subquery по отношению к главному запросу. Так что я к примеру уже давно с таким оптимизатором бросил привычку изголятся куда поставить соединения - в JOIN, IN, EXISTS, DT, LATERAL - толку то, если оптимизатор все равно переделывает в запросе соединения и условия по наиболее оптимальному варианту - нам остается только выбирать форму записи руководствуясь читабельностью запроса и более краткой формой записи.
План разный. Привычку бросил - значит не возникает в этом потребности. Но я не говорю, что это плохо.
В доказательство приведу варианты одного и того же запроса (по смыслу) с планами:
( Plan [ Total Cost Estimate: 2.472059344 ]
( WorkTable
( Intersect *HashIntersect
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ t2.flag_locate = 1 : 100% Statistics ] )
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ t2.flag_locate = 1 : 100% Statistics ] )
)
)
)
( Plan [ Total Cost Estimate: 13.14004362 ]
( Keyset
( HashDistinct
( NestedLoopsJoin[ TRUE ]
( *HashJoin
( HashFilter
( HashFilter
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ t2.flag_locate = 1 : 100% Statistics ] )
)
)
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ ( hash( t2.tovar_id ) in hashmap( t2.tovar_id ) : 100% Guess ) AND ( hash( t2.flag_locate ) in hashmap( t2.flag_locate ) : 100% Guess ) AND ( t2.flag_locate = 1 : 100% Statistics ) ] )
)
( IndexScan ( tovar_spell_words t1 ) tovar_fk[ t1.tovar_id = t2.tovar_id : .0001358127% Column-Column ] )
)
)
)
)
( Plan [ Total Cost Estimate: 2.491508344 ]
( WorkTable
( *HashJoin
( HashFilter
( HashFilter
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ t2.flag_locate = 1 : 100% Statistics ] )
)
)
( IndexScan ( tovar_spell_words t1 ) spell_word_forms_fk[ ( hash( t1.tovar_id ) in hashmap( t2.tovar_id ) : 100% Guess ) AND ( hash( t1.flag_locate ) in hashmap( t2.flag_locate ) : 100% Guess ) AND ( t1.flag_locate = 1 : 100% Statistics ) ] )
)
)
)
Может показаться, что INTERSECT самый лучший вариант, но есть нюансы по которым выбор в его пользу неудачен.
Что касается distinct и group by, то выбор group by является более предпочтительным, ввиду природы алгоритма. Distinct это более уверсальное решение, но и менее гибкое и как следствие, возможно, менее производительное.
( Plan [ Total Cost Estimate: 2.802156594 ]
( WorkTable
( HashDistinct
( *HashJoin
( HashFilter
( HashFilter
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ t2.flag_locate = 1 : 100% Statistics ] )
)
)
( IndexScan ( tovar_spell_words t1 ) spell_word_forms_fk[ ( hash( t1.tovar_id ) in hashmap( t2.tovar_id ) : 100% Guess ) AND ( hash( t1.flag_locate ) in hashmap( t2.flag_locate ) : 100% Guess ) AND ( t1.flag_locate = 1 : 100% Statistics ) ] )
)
)
)
)
( Plan [ Total Cost Estimate: 2.696584094 ]
( WorkTable
( HashGroupBy
( *HashJoin
( HashFilter
( HashFilter
( IndexScan ( tovar_spell_words t2 ) spell_word_forms_fk[ t2.flag_locate = 1 : 100% Statistics ] )
)
)
( IndexScan ( tovar_spell_words t1 ) spell_word_forms_fk[ ( hash( t1.tovar_id ) in hashmap( t2.tovar_id ) : 100% Guess ) AND ( hash( t1.flag_locate ) in hashmap( t2.flag_locate ) : 100% Guess ) AND ( t1.flag_locate = 1 : 100% Statistics ) ] )
)
)
)
)
Оптимизатор у АСА умный, и даже очень, поэтому хочу повторить, что планы разные, и в некоторых случаях принципиально. Конечно смысла так ковырятся в широкораспространненых задачах - нет. Но у читателей форума может сложиться впечатление, что АСА и впрямь всемогущ и сделает все за нас, но это не так. Когда речь встает о базе объектов для поиска в 2 млн записей, и справочнике свойств в 10 млн все планы становятся очень даже принципиально разными, и это нужно помнить.

P.S.: К примеру есть еще один нюанс, связанный с тем, что например товаров с свойством 006 может быть много, а товаров с свойством 007 может быть один. И вот тут при построении запроса через JOIN оптимизатор это заценит, и воспользуется внешним ключом по товару, а в случае с запросом с применением EXIST или INTERSECT (а тем более вложенных селектов) его план будет менее гибким, ввиду вида запроса и будет тупо пересекать большие массивы данных.

ASCRUS (как и следовало ожидать, в плане запроса не было таблицы Goods, так как использовалось всего одно ключевое поле, так что Ваши выссказывания о дополнительном сканировании таблицы абсолютно беспочвенны).
Пардон, но я этого не проверял, я доверился Вам:
ASCRUSДумаю не стоит говорить, сколько будет длиться поиск, если будет много товаров и свойств - на каждое условие поиска будет идти дополнительное сканирование таблицы Goods_Properties
Но может и не будет скана.
ASCRUS
Почитайте пожалуйста в BOL все главы: ASA SQL User's Guide/Query Optimization and Execution и заодно узнаете, что такое семантическое преобразование запроса перед его оптимизацией, почему и когда JOIN = EXISTS, почему DT может быть вынесен в основной план запрос и много еще интересных вещей.

Читал естественно, и Вы правильно подметили "почему и когда JOIN = EXISTS". Именно это я и говорю, что не всегда существует однозначное преобразование JOIN<->EXISTS.
ASCRUS
P.S. Я вообще глядя на Ваши планы запросов ужасаюсь, почему в планах везде сплошные хэш алгоритмы обработки данных. Обычно оптимизатор использует их только в случае работы с большими обьемоми данных и отсутствием подходящих индексов на таблицах - здесь может быть действительно есть разница по планам запросов. У Вас вообще какая точная версия ASA используется ?
Да, данных много, очень много. Индексы есть, точнее в качестве них ипсользуются внешние ключи и именно их АСА использует (в плане видно). Версия АСА902.3221(вроде). Раз АСА решил использовать хэш алгоритмы, значит ему так нужно, главное направить в нужное русло. На серваке стоит кэш еще не слабый, но это так, к слову пришлось.

P.S.: Мне вот не подходит вариант, с отдельными таблицами для каждого типа товара, т.к. нет такого понятия тип, т.е. он один этот тип, но при том раскладе, что одно свойство может иметь несколько значений. В качестве значения свойства товара выступает словоформа (т.е. в одном свойстве(текстовые данные) может встречаться несколько словоформ). Либо, если посмотреть иначе, словоформа это и есть свойство товара, а его значение это его позиция, тогда набор свойств(словоформ) для каждого товара в основном будет различным и сделать для каждого набора словоформ отдельную таблицу нереально. Резюме: в моей задаче возможен путь только с одной таблицей значений свойств товара, а поскольку такой вариант совпадает с вопросом автора, то я ему сообщаю, что лучше примененять запросы с JOINами, как наименее опасный путь(в этом случае мы меньше всего связываем руки оптимизатору АСА).

Да все нормально.)))
Обычное обсуждение в рабочем порядке.