|
|
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
есть табличка, типа есть группы в них группы или товары (как файлы-папки): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: plaintext для товаров (не групп) верно: LEFTBOUND=RIGHTBOUND требуется написать запрос, упорядочивающий записи по иерархии, а среди записей одного уровня должны вначале идти группы, например: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. смог построить запрос по-иерархии, но не добился чтобы группы в одном уровне были сверху: Код: plaintext 1. 2. 3. 4. поле glevel отвечает за уровень вложенности записи С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:05 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
> требуется написать запрос Исправьте структуру. Не читайте Celco, его примеры носят исключительно теоретический характер и на практике применяться не должны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:15 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621> требуется написать запрос Исправьте структуру. Не читайте Celco, его примеры носят исключительно теоретический характер и на практике применяться не должны. это эксперимет, при малом и неоперативном изменении данных удобно (структура в основном на чтение) выход видится один - при вставке новых групп анализировать и сдвигать LEVELBOUND вниз у элементов-не-групп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:21 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
> это эксперимет Как получить иерархию наиболее извращенным способом? Вы понимаете, что невозможно придумать условия, которым такая реализация будет удовлетворять? > при малом и неоперативном изменении данных удобно (структура в основном на чтение) Удобно - это когда все иерархии в базе данных имеют общую каноническую модель и когда view получаются простыми и безгеморройными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:30 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621> это эксперимет Как получить иерархию наиболее извращенным способом? Вы понимаете, что невозможно придумать условия, которым такая реализация будет удовлетворять? > при малом и неоперативном изменении данных удобно (структура в основном на чтение) Удобно - это когда все иерархии в базе данных имеют общую каноническую модель и когда view получаются простыми и безгеморройными. Прошу Вас предложить свой вариант иерархии ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:34 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621Сформулируйте задачу. Есть справочник товаров, он должен быть иерархический. У одного элемента может быть только один владелец-группа. Вложенность не ограниченная. Необходимо простым способом (одним запросом желательно) выводить его в иерархическом виде (это текущий топик). Также соединять другие таблицы с ней, выводя данные по записям справочника и агрегирующие по группам. Например (упрощенно) есть также таблица Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:47 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
> Есть справочник товаров Характер справочника? Правила классификации? Предмет классификации? Область применения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:53 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Есть справочник товаров Характер справочника? Правила классификации? Предмет классификации? Область применения?Правила и остальное на усмотрение пользователей оставляются. Для примера, посмотрите 1С, вот аналог справочника Номенклатура там. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 15:55 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
н-да, не все так просто внутри одной группы нужно сортировать более хитро: сначала группы потом остальные записи, но и те и те по алфавиту С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 16:22 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
> Правила и остальное на усмотрение пользователей Тогда задача не имеет простого решения. Невозможно классифицировать все, что угодно, каким угодно образом. А если не париться, то три подзадачи: собственно классификатор (включая зависимости и пр.), предмет классификации (в данном случае товары) и собственно связи между классификатором и предметами классификации. > посмотрите 1С Не напрягайте модератора. Одинце - то же самое, что и писанина Celco: для практического применения это непригодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 16:25 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Правила и остальное на усмотрение пользователей Тогда задача не имеет простого решения. Невозможно классифицировать все, что угодно, каким угодно образом. А если не париться, то три подзадачи: собственно классификатор (включая зависимости и пр.), предмет классификации (в данном случае товары) и собственно связи между классификатором и предметами классификации. > посмотрите 1С Не напрягайте модератора. Одинце - то же самое, что и писанина Celco: для практического применения это непригодно. Не надо все, надо - товары. каким образом? ну допустим по номенклатурным группам, заданным на предприятие. Например: группа "Молочные продукты" включает в себя группы "Молоко", "Кефир"... Группа "Молоко" состоит из товаров "Молоко 3%", "Молоко 6%" ... Товары могут иметь произвольное число вложений. Например "Молоко 3%" - 3 уровня вложенности, а "Хлеб форомовой" - 2 уровня. А насчет непрактичности 1С, жизнь показывает обратное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 16:32 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
> группа "Молочные продукты" включает в себя группы "Молоко", "Кефир"... Так и делайте, какие проблемы? Классификатор - отдельно, товары - отдельно, связи - отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 16:43 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621> группа "Молочные продукты" включает в себя группы "Молоко", "Кефир"... Так и делайте, какие проблемы? Классификатор - отдельно, товары - отдельно, связи - отдельно.Я думал над этим, чтоб группы вынести в отдельную таблицу, но что это дает, если число вложений групп заранее неизвестно? тоже самое, что они в общей таблице. В смысле та же проблема упорядочивания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 16:53 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
> что это дает Корректную модель. > число вложений групп заранее неизвестно И? Для каждого элемента классификатора храните уровень и глубину, если всегда нужно это знать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 17:07 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621> что это дает Корректную модель. > число вложений групп заранее неизвестно И? Для каждого элемента классификатора храните уровень и глубину, если всегда нужно это знать."уровень и глубину" а простите что есть глубина? уровень я определял количество вложений записи в другие. Эти данные я и так вытащить могу. Мне нужна упорядоченность: - по иерархии, внутри нее - по признаку группа или нет (сначала группы), среди них по алфавиту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 17:12 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
в общем, вы можете конкретный (достаточно простой) пример привести желательно без рекурсивного вызова процедур С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 17:13 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
В общем задача такая: какая наиболее оптимальная структура таблицы справочника, чтобы наиболее просто получать иерархический список (упорядоченность по иерархии и доп. полю, например наименованию или признаку группы + наименованию) Соответственно, достаточно просто получать агрегатные функции из других таблиц с учетом иерархии. Достаточно просто - это одним запросом и без рекурсии хранимых процедур. С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2009, 17:32 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Когда в практике ты "ноль" можно по теоретизировать. Итак, пусть есть таблица представляющая собой некое множество записей, на котором хотим задать отношение полного порядка (а попросту, упорядочить каким-то способом). Обозначим A>>B если в нашем упорядочивании запись A идет раньше B. Введем функцию r(A,B) =1, если A>>B и =0 иначе. Очевидно, что r(A,A)=0; r(A,B)=1-r(B,A); если r(A,B)=r(B,C)=1 тогда r(A,С)=1. Тогда функция R(A)=Sum(r(A,B),B-пробегает все множество) принимает различные значения 0,1,...,Count(*)-1 и задает тот же порядок на целых числах. Переводя в SQL, получаем запрос "универсального" упорядочивания: Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. Вернемся к текущей задаче. Необходимо упорядочить множество по-иерархии (обозначим >>) и внутри одной ветки иерархии по другому признаку, например паре IsGroup,Name (обозначим >). Итак, для каждой записи можно указать "родительскую", на которую ссылается Parent. Для каждой записи A можно записать родительский ряд: A=A0<<A1<<...<<An=NULL где Ai.Parent = A(i+1). Для пары (A,B) минимальным предком X назовем запись наибольшего уровня вложенности, одновременно встречающееся в родительских рядах A и B (возможно NULL). Если A и B не расположены в одном родительском ряду, то минимальные индивидуальные родители относительно A и B это элементы в родительских рядах An<<X и Bm<<X (предшествующие X непосредственно). Тогда введенная ранее функция r(A,B) равна 1 тогда и только тогда, когда: 1. B!=A и A лежит в родительском ряду B. либо 2. An>Bm (верно второе упорядочивание). Как видно из написанного нам понадобится использование LEFTBOUND и RIGHTBOUND, но придется использовать многократное соединение таблицы самой с собой. А именно: найти минимального предка, найти индивидуальных предков и сравнить их. Но, зачастую, практика это не теория, надеюсь на более простое решение задачи. С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 09:16 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Вы не имеете ни малейшего представления ни о классификации, ни о проектировании, ни о теории множеств. Я не могу тратить свое время на глупые измышления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 11:08 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
guest_20040621Вы не имеете ни малейшего представления ни о классификации, ни о проектировании, ни о теории множеств. Я не могу тратить свое время на глупые измышления.От Вас я тоже никакой конкретики не увидел. Можете не тратить свое время на меня, а я свое на Вас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 11:12 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Вывод дерева с сортировкой внутри каждого уровня: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 12:50 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
н-да, без специфики серверов, то есть максимально переносимо между СУБД вышло вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 14:13 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
интересно насколько это хуже рекурсии? С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 14:14 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
поправить упорядочивание на: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2009, 15:08 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
улучшил: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2009, 09:42 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Наконец, допустим есть таблица продаж (очень упрощенно) Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2009, 12:00 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Nafесть табличка, типа есть группы в них группы или товары (как файлы-папки)Не самая подходящая аналогия, IMHO. Не стоит смешивать группы и товары в одной таблице. Этим, как минимум, усложняется проверка корректности данных. Например, группа может оказаться потомком товара, да и иерархичность товара вызывает сомнения. Хранение иерархии "методом Селко" может показаться привлекательным чисто теоретически, но, как показала практика, он больше вызывает проблем, чем их решает. Разумеется, никто не может помешать проверить это утверждение самому. Какой метод выбрать взамен него, трудно сказать однозначно. Для некоторых задач вполне достаточно стандартной пары (ID, ParentID) и рекурсивных запросов. Иерархия групп товаров - вещь, как минимум, очень неудобная, хотя бы по причине "жёсткости". В данном случае, IMHO, стоило бы применить "теговый" подход, когда к товару можно "прицепить" какие угодно теги, каждый из которых представляет собой ссылку на некий классификатор, в том числе и иерархический, если возникнет острая необходимость. Т.е., классический вариант связи M:N, реализованный через дополнительную таблицу, где с одной стороны товары, а с другой - теги(ссылки на классификаторы). Такой подход позволит строить "визуальные" иерархии, наиболее уместные в конкретной ситуации или для конкретного пользователя простым выбором последовательности тегов. Например, сначала по производителям, а потом по видам продукции, а можно наоборот, сначала по видам продукции, а потом по производителям. P.S. Хотелось бы отметить, что на практике, IMHO, часто тяготеют к иерархическим структурам, где их наличие совершенно неоправданно. "Истинных" иерархий, подобно генеалогическому дереву, на практике не так уж и много. В таких случаях обычно подразумеваются, что все элементы этой иерархии однотипны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2009, 14:00 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
ChAХранение иерархии "методом Селко" может показаться привлекательным чисто теоретически, но, как показала практика, он больше вызывает проблем, чем их решает. Хмм... голословное утверждение. Знаю как минимум два случая из личной практики, когда применение метода Селко избавило от необходимости приобретения дорогущего железа. При этом сложность добавления/удаления/изменения данных для процедур, которые с этим деревом работали, ни как не изменилась. Вместо корявых и медленных циклов / курсоров / CTE для выборки данных из деревянной структуры, были написаны однопроходные запросы и построены индексы. При этом, скорость работы увеличилась на несколько порядков, а нагрузка на железо упала в несколько раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2009, 23:51 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Roman S. Golubinголословное утверждение.Роман, могу ответить в том же духе, твои примеры тоже являются голословным утверждением. Дабы избегать ненужного эпатажа и сосредоточиться на сути, предлагаю в дальнейшем исключить подобные формулировки. Мои утверждения основаны на моей практике, твои на твоей, давай исходить из этого. Roman S. GolubinЗнаю как минимум два случая из личной практики, когда применение метода Селко избавило от необходимости приобретения дорогущего железа. При этом сложность добавления/удаления/изменения данных для процедур, которые с этим деревом работали, ни как не изменилась.Разумеется, если использовать метод вложенных множеств(Селко) в качестве альтернативы дилетантским решениям, то не исключаю, что он может выиграть по некоторым пунктам. Но от его родового проклятия, пересчёта и модификации LR-значений, в среднем затрагивающих до половины узлов дерева, увы, не избавиться. Если использовать большую разреженность значений, чтобы снизить объем модификаций, то мы теряем некоторые преимущества, которые даёт непрерывность LR-последовательности, при этом дополнительная проверка на предмет нахождения внутри псевдофиксированных границ остаётся. Даже для простейшего поиска всех потомков узла необходимо использовать слияние, для получения по идентификатору узла его LR-значений, чтобы выбрать потомков, чьи LR-значения находятся внутри LR-границ предка. Причем сами LR-значения мы не можем использовать в качестве ключа в связи с их потенциальной изменчивостью. Поиск всех предков листа приводит к сканированию всех узлов дерева, что с учётом потенциальной перестройки дерева при модификации может породить немало проблем. То же самое произойдёт при попытке вычислить уровень листа. Слишком часто используется between, что мешает использованию merge- и hash-алгоритмов при различных выборках. Да и с индексом есть проблемы, так как у нас для каждого узла есть 2 совершенно независимых друг от друга значения. В результате, польза от индекса (L,R) невелика, а использование 2 отдельных индексов по L и R сервером запросто игнорируется с точки зрения IO. Дешевле сделать seek+scan по какому-либо одному из них. Roman S. GolubinВместо корявых и медленных циклов / курсоров / CTE для выборки данных из деревянной структуры, были написаны однопроходные запросы и построены индексы. При этом, скорость работы увеличилась на несколько порядков, а нагрузка на железо упала в несколько раз.Я тоже видел много ужасных реализаций, но это говорит лишь об уровне их авторов. Тем более, что ты упомянул создание индексов, исключение курсоров. Так зачем же противопоставлять заведомо плохую реализацию работы с деревом и метод вложенных множеств, который при реализации тем же программистом мог бы точно так же, если не хуже, похоронить сервер ? Цикла в случае стандартных (ID, ParentID) может и не избежать, но без курсоров можно запросто обойтись, этот способ был предложен в BOL еще к MS SQL версии 4.21. Почти уверен, что нормальная реализация такого подхода не сильно бы уступала методу вложенных множеств. В случае неглубоких деревьев(2-3 уровня, что нередко бывает на практике) не думаю, что CTE принципиально проигрывает методу вложенных множеств при "правильных" индексах. Впрочем, это моё голословное, умозрительное, утверждение, сам экспериментов не ставил. Если есть обратная статистика, а ещё лучше, воспроизводимый пример, то был бы рад ознакомиться. IMO, метод вложенных множеств может использоватся в случае не очень больших и редкоизменяющихся деревьев. Лично я исключил его из своей практики, предпочитаю развёртывание иерархии в дополнительных полях и/или таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2009, 02:22 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
ChA, По поводу использования LR в качестве ключа - это жестко :) Я использовал все ту же старую модель ID/ParentID в связке с LR - индекс позволяет выбрать пару с помощью Seek. И да, в обоих случаях имелось очень большое, основательно развлетвленное и не очень активно (примерно 2-3 раза в час) изменяющееся дерево, управление структурой которого было отдано пользователям. При этом затык производительности был именно на получении потомков / путей к корню - множество поисковых запросов через web. Перед началом перехода на метод Селко рядом стоял костыль в виде отдельного сервера Oracle, на котором курсоры (по непонятной мне причине - ни разу не пользовался ораклом ) работали на порядок быстрее, чем на MS SQL. На этом оракле и крутилось дерево. На счет ужасности реализации - не знаю, как все это было реализовано до того, как перестало хватать железа и был установлен оракловый сервер - история об этом умалчивает :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2009, 03:11 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
а вы еще добавте одно поле "уровень иерархии", оно может и лишнее но поможет Вам и сейчас и в будующем. CREATE TABLE GOOD ( --товары ID Integer NOT NULL, --первичный ключ LEFTBOUND Integer NOT NULL, RIGHTBOUND Integer NOT NULL, PARENT Integer,--сылка на группу владельца, для первого уровня NULL NAME Varchar(50) NOT NULL, --наименование группы или товара ISGROUP Integer NOT NULL --признак группы: 0,1 LEVEL Integer NOT NULL ); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 16:14 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Борис Бритваа вы еще добавте одно поле "уровень иерархии", оно может и лишнее но поможет Вам и сейчас и в будующем. CREATE TABLE GOOD ( --товары ID Integer NOT NULL, --первичный ключ LEFTBOUND Integer NOT NULL, RIGHTBOUND Integer NOT NULL, PARENT Integer,--сылка на группу владельца, для первого уровня NULL NAME Varchar(50) NOT NULL, --наименование группы или товара ISGROUP Integer NOT NULL --признак группы: 0,1 LEVEL Integer NOT NULL );возможно, но в тоже время оно легко вычисляется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 16:31 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Naf, c таким же успехом Вы можетесказать, что поля PARENT и ISGROUP - излишества) и вообще табличку надо нормализовать) Вам не кажется что для таких запрросов используется подход, который позволяет оптимизировать время выполнения запроса, и позволяет строить интутивно понятные с первого взгляда простые запосы. Представляете себе запрос такого вида как Вы предложили хотя бы для 5 измерений? =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 11:37 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Подумайте, может Вам в условии JOIN юзать BETWEEN и тогда будет удобней? SELECT GOOD.NAME, SUM( SALE.AMOUNT ) AS AMOUNT FROM GOOD LEFT OUTER JOIN SALE ON ( SALE.GOOD BETWEEN GOOD.LEFTBOUND AND GOOD.RIGHTBOUND) GROUP BY GOOD.NAME ORDER BY GOOD.LEFTBOUND ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 12:18 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Борис БритваNaf, c таким же успехом Вы можетесказать, что поля PARENT и ISGROUP - излишества) и вообще табличку надо нормализовать) Вам не кажется что для таких запрросов используется подход, который позволяет оптимизировать время выполнения запроса, и позволяет строить интутивно понятные с первого взгляда простые запосы. Представляете себе запрос такого вида как Вы предложили хотя бы для 5 измерений? =)нормализовать можно, но денормализация специально внесена для ускорения выборок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 15:30 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Борис БритваПодумайте, может Вам в условии JOIN юзать BETWEEN и тогда будет удобней? SELECT GOOD.NAME, SUM( SALE.AMOUNT ) AS AMOUNT FROM GOOD LEFT OUTER JOIN SALE ON ( SALE.GOOD BETWEEN GOOD.LEFTBOUND AND GOOD.RIGHTBOUND) GROUP BY GOOD.NAME ORDER BY GOOD.LEFTBOUNDмне не нужны все товары, а только которые есть в SALE. Да и сортировки требуемой нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 15:32 |
|
||
|
Иерархия
|
|||
|---|---|---|---|
|
#18+
Naf, у меня с сортировкой все в порядке. Может у Вас в данных неправильно указаны левые и правые границы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 16:17 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1543092]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
203ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
87ms |
get tp. blocked users: |
2ms |
| others: | 205ms |
| total: | 542ms |

| 0 / 0 |
