|
|
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Подскажите, кто знает, как решить следующую проблему: Cуществует таблица с данными, например TBL1. Она связана с справочниками STBL1, STBL2, STBL3... Связь TBL1->STBL1 = 1-ко многим, TBL1->STBL2 = 1-ко многим ... Но особенность ситуации заключается в следующем: каждай запись таблицы TBL1 связана ИЛИ c STBL1 ИЛИ с STBL2 ... Такой случай часто возникает, например, когда нужно бухгалерский журнал операций связать с различными справочниками. Вопрос состоит в следующем: ~~~~~~~~~~~~~~~~~~~ 1. Как правильно построить структуру БД для данного случая, в принципе, можно рассматривать несколько вариантов, но мне почему-то ни один не нравится :) 2. Как построить эффективный SELECT для вибора данных с таблиц TBL1, STBL1 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 18:39 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Одно и тоже поле связано в одной и той же таблице связано с несколькими справочниками? Т.е. выбор значения поля одно из значений хотя бы в одной справочной таблице? Я правильно понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 18:49 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
В принцыпе да. Но в вашем вопросе - содержится сразу и предложение определенной структуры (одного из вариантов) Но логически - именно так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 18:53 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Несколько сущностей например с двумя полями: ссылка на журнал операций и ссылка на требуемый справочник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:07 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Не совсем понятна ситуация когда это необходимо. На вскидку в журнал попадают счета и платежки и те и другие имеют разные структуры но должна попадать в одно и тоже поле идеологически правильно было бы создать общий тип "документ" и таблицу для него. И при работе с каждым типом документов открывать вьюхи. Однако это испортит производительность ввода документов. Второй вариант вешать триггер на обновление журнала и в нем разбирать является ли данное значение допустимым или нет. Программный форейн констрент. Ухудшает скорость внесения в журнал. Третьий вариант. Наплевать на непрерывную целостность данных и отлавливать некорректные строки через JOB. Это в принципе хорошо прокатывает только когда журнал и заполняется пакетными заданиями а не по пользовательскому произволу. По моему так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:08 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Но вообще это плохо. Самым правильным вариантом был бы один большой справочник в котором было бы всё, но бог велел делиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:10 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Браво ! (на счет общего справочника) Во многих случаях так и решают. Но это несколько сложно в случае если справочники имеют совершенно различние структуры (сущности), например: Люди Предприятия Материалы ... Именно так дела обстоят на практике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:20 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А что это за поле где хранятся и люди и материалы и предприятия Я просто ТАКОГО представить не могу. Опиши бизнесс процесс. Может что придумать можно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:23 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Чем не устраивает предложенный мной вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:24 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
2 MW Не как связать это просто. Длается поле указатель на соответсвующую сущность и через него коннектишся. Здесь все согласны. На это завязаны все возможные варианты. Другое дело где эту сущность хранить и как обрабатывать. Думаю имелось ввиду что-то вроде Junction Table но в данном случае от её наличия или отсутствия ничего не меняется. Грабли всё равно остаются. Или я чего не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:28 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Приведу простой пример: Он хорошо известен разроботчикам различных учетных задач: cуществует "журнал операций" 1.Количество (Дебет, Кредит) 2.Сума (Дебет, Кредит) 3.Аналитика (Люди,Предприятия,Материалы и т.д) В эту таблицу попадают бухгалтерские проводки, которые формируются различными документами (чево-то типа таблицы фактов OLAP). Аналитика- это различные справочныки (в т.ч. многоуровнивые). Вот и весь бизнес-процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:31 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Тут все просто. Если я правильно понял проблема в подцеплении аналитического учета? В журнал операций добывляется код аналитики (1-материалы, 2 - персонал и т.п), и поле которое будет содержать значение аналитики (код из справочника никак не привязанный к нему, но это для ускорения, т.е. можно и не делать). Далее делается по промежуточной таблице для каждого справочника запись в этих таблицах содержит ссылку на строку журнала операций и на требуемую строку справочника. И заполняется триггером при вставке записи в журнал операций (отношение один к одному). Ведь выборки по разным аналитическим данным _обычно_ не делаются. В данном случае выборку по журналу операций указав код аналитического учета сделать очень просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:38 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Тогад MW наверное прав 1) Сделать Junction TABLE в ней хранить все возможные типы аналитики много строк, мало собственно информации. 2) заполнять Junction TABLE пакетным заданием из нормальных справочников 3) и классический FK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:38 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Наверное я или немогу описать проблему или она действительно неразрешима ???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:40 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Последний раз мы с MW поняли тебя одинаково. Задача красиво действительно неразрешима. Но решение работающее вполне есть см выше. Чем не устраивают предложенные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:44 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>> Eter Panji Еще раз браво ! Это очень близко к решению, к которому я пришел. Но я извеняють за невежество, что такое Junction TABLE ? Как сопровождать Junction TABLE ? Триггерами ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:45 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
"Ключевая фраза": Промежуточная таблица не одна а несколько: MAINBOOK( ID, VID) -- журнал операций VID = 1 для персонала, =2 для материалов LINK_PERSONAL( PERSONAL_ID, MAINBOOK_ID) LINK_MATERIAL( MATERIAL_ID, MAINBOOK_ID) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:46 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
в данном случае JUNCTION TABLE - журнал всех типов аналитики Если исходные таблицы-справочники заполняются редко то самое лучшее поставить JOB который с какой-то периодичностью будет синхронизировать справочники и JUNCTION TABLE Если часто тогда действительно лучше триггерами на справочниках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:49 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А зачем несколько? Выигрыш будет небольшой, или ... это получится отношение многие ко многим? А зачем оно вообще нужно в данном контексте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:51 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>All Спасибо огромное ! Мне действительно некоторые вещи стали более понятны. В особенности, у меня исчезно какоето-болезненное впечатление, что я никак не могу просто и эффективно (без промежуточных таблиц ) решить это проблему. На самом деле, наверное действително так ее решить невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:53 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А невозможно разные сущности свести к одной ссылке, нарушается целостность данных. И скажите мне в каких случаях может потребоватся запрос на одновременный вывод данных по разным видам аналитического учета? И даже в этом случае можно выйти из положения по предложенной схеме. И не требуется никаких обновлений. Отношение один к одному, вставка в промежуточную таблицу при сохранении документа и создании записи в журнале операций, ведь заранее известно какой документ какие виды аналитики на себе несет. А если схема данных организована еще грамотнее (на полупроводках), то это еще снимет массу головной боли в последствии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:07 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>И скажите мне в каких случаях может потребоватся запрос на >одновременный вывод данных по разным видам аналитического учета? Просто вывести на экран (отчет) журнал операций. И все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:13 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Там требуется вывод аналитики? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:14 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
В принципе, да. Т не только там. То же самое - любой бухгалтерский документ: например, акт о приеме материалов - там тоже присутствует аналитика. И когда необходимо высести "журнал документов", в нем есть поле : от кого получено, кому передано и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:18 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Да не вопрос: select m.id, m.vid, m.summa, mt.name from mainbook m, link_material lm, material mt where m.id = lm.mainbook_id and m.vid = 1 and lm.material_id = mt.id union select m.id, m.vid, m.summa, p.name from mainbook m, link_personal lp, personal p where m.id = lp.mainbook_id and m.vid = 2 and lp.personal_id = p.id union и т.п ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:23 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW Ес ! Да...Это просто супер ! UNION !!!!! Но есть одна проблема - ПРОДУКТИВНОСТЬ = 0 !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:25 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
MW тот же разрыв только у меня он между общим справочником и отдельными справочниками а у вас между журналом и всомогательными справочниками. То время которое у меня тратится на обновление общей таблицы аналитики у вас пойдет на обновление вспомогательных таблиц в момент добавления записи в журнал Я же говорю это разница между первым и вторым из моего поста от 19-08 Где хочешь иметь тормоза там и имеешь. Мне всё таки кажется что мой вариант здесь удачнее поскольку справочники меняются относительно редко а вот журнал обновляется на порядок чаще. А то что могут удалить строку справочника, так это варварство. По бизнесс логике неположено. Значить можно просто запретить на уровне базы удалять строки и изменять ключевые поля в справочниках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:27 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Вы не правы! Если вы повнимательнее взглянете на условие каждого запроса то поймете что тем не менее одна запись таблицы обрабатывается один раз и если построить индекс на ID и VID вы получите более высокую производительность чем если возметесь совмещать справочники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:30 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW А что если результат нужно отсортировать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:32 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
И лучше пусть оператор подождет полсекунды при записи документа в базу чем по пол секунды при выборке каждой строки из 20 тысяч например ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:32 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW поправочка : 20 миллионов, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:34 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Тем более... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:37 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW Так ка на счет select * from ( select m.id, m.vid, m.summa, mt.name from mainbook m, link_material lm, material mt where m.id = lm.mainbook_id and m.vid = 1 and lm.material_id = mt.id union select m.id, m.vid, m.summa, p.name from mainbook m, link_personal lp, personal p where m.id = lp.mainbook_id and m.vid = 2 and lp.personal_id = p.id union и т.п ) t order by 0,1,... ???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:39 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>Eter Panji Дело в том, что сейчас наша система работает так, как предложил MW. А собираемся перейти на вариант, предложенный вами. Но... очень большие сомнения существуют :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:42 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А побробовать сначала и посмотреть на план запроса и скорость исполнения? Вашу модель данных это никак не нарушит. В реальности полный журнал операций с выложенной разношерстной аналитикой никогда не требуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:44 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW На счет планов запросов - все глаза просмотрели :) Как-то по дурацки получается : если присутствует UNION добится использования индексов никак не получается. Что касается остального - пост 14 ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:48 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW Я не согласен, что "В реальности полный журнал операций с выложенной разношерстной аналитикой никогда не требуется". Достаточно посмотреть любую готовую систему, ту же 1С, например : первое, что мы видим, это как-раз "журнал операций с выложенной разношерстной аналитикой" !!! Там даже монятие есть такое : "виды субконто" (читай : виды аналитики). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 21:02 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Ludi!! Ispol'zyite Oracle's analytic functions i ne stroite problemy, kotorye potom neobhodimo geroicheski preodolevat'! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 08:02 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
to ov >ту же 1С, например : первое, что мы видим, это >как-раз "журнал операций с выложенной разношерстной аналитикой" !!! А вы пробовали 1с на 20 млн записей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 08:58 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>>MW Да, 1С на 20млн - это нонсенс. Дело в том что там не существует так называемой "виртуализации", тоесть весь журнал выбирается за один раз. Но то же самое - любой бухгалтерский документ: например, акт о приеме материалов - там тоже присутствует аналитика. И когда необходимо высести "журнал документов", в нем есть поле : от кого получено, кому передано (Аналитика) и т.д. Что в этом случае делать ? >Oracle X-pert Просветите, если можно, что такое "analytic functions". С удовольствием исползуем, если в природе такое есть :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 09:22 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
> ov >Что в этом случае делать ? Дальнейшее продолжение спора _здесь_ сильно отвлекает от основной работы. :((( Если у вас есть желание можно продолжить по e-mail или ICQ. merlinw@yandex.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 09:38 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>MW Да, согласен. По емайлу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 09:42 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
SELECT channel_desc, calendar_month_desc, TO_CHAR(TRUNC(SUM(amount_sold),-6), '9,999,999,999') SALES$, TO_CHAR(SUM(quantity_sold), '9,999,999,999') SALES_Count, RANK() OVER (ORDER BY trunc(SUM(amount_sold), -6) DESC, SUM(quantity_sold) DESC) AS col_rank FROM sales, products, customers, times, channels WHERE sales.prod_id=products.prod_id AND sales.cust_id=customers.cust_id AND sales.time_id=times.time_id AND sales.channel_id=channels.channel_id AND times.calendar_month_desc IN ('2000-09', '2000-10') AND channels.channel_desc<>'Tele Sales' GROUP BY channel_desc, calendar_month_desc; ----- SELECT channel_desc, calendar_month_desc, TO_CHAR(TRUNC(SUM(amount_sold),-6), '9,999,999,999') SALES$, RANK() OVER (ORDER BY trunc(SUM(amount_sold),-6) DESC) AS RANK, DENSE_RANK() OVER (ORDER BY TRUNC(SUM(amount_sold),-6) DESC) AS DENSE_RANK FROM sales, products, customers, times, channels WHERE sales.prod_id=products.prod_id AND sales.cust_id=customers.cust_id AND sales.time_id=times.time_id AND sales.channel_id=channels.channel_id AND times.calendar_month_desc IN ('2000-09', '2000-10') AND channels.channel_desc<>'Tele Sales' GROUP BY channel_desc, calendar_month_desc; ---- SELECT channel_desc, country_id, TO_CHAR(SUM(amount_sold), '9,999,999,999') SALES$, RANK() OVER (PARTITION BY GROUPING_ID(channel_desc, country_id) ORDER BY SUM(amount_sold) DESC) AS RANK_PER_GROUP FROM sales, customers, times, channels WHERE sales.time_id=times.time_id AND sales.cust_id=customers.cust_id AND sales.channel_id= channels.channel_id AND channels.channel_desc IN ('Direct Sales', 'Internet') AND times.calendar_month_desc='2000-09' AND country_id IN ('UK', 'US', 'JP') GROUP BY CUBE( channel_desc, country_id); ------ SELECT calendar_year AS YEAR, calendar_quarter_number AS QTR, calendar_month_number AS MO, SUM(amount_sold), RANK() OVER (ORDER BY SUM(amount_sold) ASC NULLS FIRST) AS NFIRST, RANK() OVER (ORDER BY SUM(amount_sold) ASC NULLS LAST) AS NLASST, RANK() OVER (ORDER BY SUM(amount_sold) DESC NULLS FIRST) AS NFIRST_DESC, RANK() OVER (ORDER BY SUM(amount_sold) DESC NULLS LAST) AS NLAST_DESC FROM ( SELECT sales.time_id, sales.amount_sold, products.*, customers.* FROM sales, products, customers WHERE sales.prod_id=products.prod_id AND sales.cust_id=customers.cust_id AND prod_name IN ('Ruckpart Eclipse', 'Ukko Plain Gortex Boot') AND country_id ='UK') v, times WHERE v.time_id (+) =times.time_id AND calendar_year=1999 GROUP BY calendar_year, calendar_quarter_number, calendar_month_number; ----- SELECT calendar_month_desc AS MONTH , TO_CHAR(SUM(amount_sold), '9,999,999,999') SALES$, NTILE(4) OVER (ORDER BY SUM(amount_sold)) AS TILE4 FROM sales, products, customers, times, channels WHERE sales.prod_id=products.prod_id AND sales.cust_id=customers.cust_id AND sales.time_id=times.time_id AND sales.channel_id=channels.channel_id AND times.calendar_year=1999 AND prod_category= 'Men' GROUP BY calendar_month_desc; ----- SELECT c.cust_id, t.calendar_month_desc, TO_CHAR (SUM(amount_sold), '9,999,999,999') AS SALES , TO_CHAR(AVG(SUM(amount_sold)) OVER (ORDER BY c.cust_id, t.calendar_month_desc ROWS 2 PRECEDING), '9,999,999,999') AS MOVING_3_MONTH_AVG FROM sales s, times t, customers c WHERE s.time_id=t.time_id AND s.cust_id=c.cust_id AND t.calendar_year=1999 AND c.cust_id IN (6380) GROUP BY c.cust_id, t.calendar_month_desc ORDER BY c.cust_id, t.calendar_month_desc; ------ etc.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 09:57 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>Oracle X-pert Да, интересно. Очень даже. Но для какой версии Oracle это работает ? (хотябы в каком разделе догументации искать ?) Analytic SQL Features in Oracle9i ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 10:19 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Razdel - Oracle Data warehouse. Version:: SQL:: 8i/9i PLSQL - 9i ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2003, 11:15 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
2 ov, MV: Глупый вопрос -- а почему UNION, а не UNION ALL ??? Ведь по сути, m.id + m.vid -- это unique key? Тогда каждый из подзапросов возвращает непересекающийся набор записей -- а значит дубликаты отфильтровывать не нужно. А сортировка в приложении к запросам типа UNION ALL работает по совсем другим правилам нежели для UNION... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2003, 20:33 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1990730]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
167ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 533ms |

| 0 / 0 |
