Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
c127
Любая задача, с необходимостью требующая для своего решения :
поля типа varchar длиной больше 8096 байт
или
вложенности представлений глубиной больше 16
или
объединения в одном запросе больше 256 таблиц
или
см. документацию, там есть много интересного;
на MSSQL2000-е не решается.

Поля типа varchar с длиной более 8096 байт - вообще то ограничение 8000 байт, 8096 байт это ограничение на суммарный размер записи. Неудобства от этого я не ощущаю, все очень просто и легко обходится. Когда писал на PL/SQL, этот момент там был удобнее, но было много других сложностей. Много что с трудом делается на PL/SQL, легко делается на TSQL. Хотя есть и обратное. Но мне TSQL больше нравится. Единственное чего мне не хватает в нем это пакетов, можно даже без переменных уровня пакета, просто чтобы группировать процедуры. Обработка ошибок в TSQL меня полностью устраивает - обработку ошибок я делаю на сервере приложений.

Представления глубиной больше 16 - У меня на всю программу, которую сейчас делаю, есть 2 представления. Мог бы вообще без них обойтись, просто не хотелось длинный запрос записывать в средний слой. Есть еще около сотни вьюшек для OLAP. Ни одна из вьюшек не вызывает другую. В предыдущих проектах тоже все аналогично.

Объединение в одном запросе больше 256 таблиц - это возможно. Нельзя сделать такую вьюшку, но вот селект можно.
Например,
select * from BigViewWith255Tables
union all
select * from AnotherBigView
Будет работать.

Что там еще говорят про Oracle? Терабайты данных, тысячи пользователей?
Из этого у меня в проектах на SQL Server не было лишь тысяч пользовалелей, сотни были. Все отлично работает.
11 май 04, 13:07    [671096]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Вы в курсе, что имеется некая концептуальная разница между join и union ???
11 май 04, 13:49    [671219]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649

Приведенные ограничения совершенно идиотские, причем тянутся из версии в версию, несмотря на многократное переписывание с нуля ядра SQL сервера.


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

Запрос же с 256 таблицами - это что-то вообще из области творчества пациентов Кащенко. Т.е. проблема не в том, что эти ограничения надо как-то обходить, к ним приближаться даже не стоит, точно так же как не стоит серьезно обсуждать те или иные достоинства баз данных с людьми, которым хочется запихнуть 256 таблиц в один запрос.
11 май 04, 13:50    [671225]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
2 Alexader_Chepak - подписываюсь :) Но мало ли на свете придурков?
11 май 04, 17:03    [671932]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
мне вчера жаловались на дб2 для мэйнфрема - у кентов злобный фреймворк, начинали писать его лет 10 назад, писали сотни людей ... короче сегодня как он работает не знает никто.
этот фреймфорк естественно генерит код сам, а дб2 (для мэйнфрема) говорит что не может кушать более 32 стайтментов в одном запросе ...

и не важно кто глупый - систему которую писали сотни 10 лет уже не переписать - можно только подпорки ставить.
11 май 04, 17:31    [672041]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
vitaly_p
Guest
andsm
Неудобства от этого я не ощущаю,

В Африке дети голодают, а Вы не ощущаете. Это не значит, что их голод не является проблемой.
andsm
все очень просто и легко обходится.

Вы невнимательно прочитали письмо c127, последний абзац
andsm
У меня на всю программу, которую сейчас делаю, есть 2 представления.

andsm
Из этого у меня в проектах на SQL Server не было лишь тысяч пользовалелей, сотни были. Все отлично работает.

Вместо того, чтобы сказать "у меня недостаточно опыта", Вы делаете глубокие выводы. Когда Вы начинали изучать программирование, у Вас было 0 представлений, 0 пользователей, 0 SQL-запросов, 0 таблиц. Вы, наверное, громогласно заявляли, что СУБД вообще не нужны ?
Alexander_Chepack
Приведенные ограничения заставляют людей хоть немного думать

Если для Вас раздумия над способами преодоления высосанных из пальца ограничений необходимы для нормальной работы, то это еще неповод объявлять ограничения благом.
11 май 04, 18:03    [672164]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 vitaly_p

Нуууу, тогда для вас что есть раздумия над запросом, в котором вам хочется видеть больше 256 таблиц.

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

Я даже не представляю, где нужно хотя бы 100 таблиц????????

-- Tygra's --
11 май 04, 18:22    [672230]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
добавок: :)

Когда вы начинали изучать, у вас было 0 таблиц в запросе.
Сейчас 256.
Что же будет лет через 10!!!!!!! Ни одна БД вам не подойдет - тысячи две-три таблиц в одном запросе это вам не тут

-- Tygra's --
11 май 04, 18:24    [672236]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
vitaly_p
В Африке дети голодают, а Вы не ощущаете. Это не значит, что их голод не является проблемой.
Ни Oracle ни mssql не умеют лепить и варить пельмени "Малышок" (которые, как известно, и в Африке "малышок").
Я пробовал, действительно не умеют :( Это УЖАСНОЕ ограничение обоих серверов! Куда только проектировщики смотрели!!!

Я вот подумал, что языки программирования, причем все, проектировали криворукие проектировщики. Что за манера, в конце концов, ограничивать целое чило 32/64 разрядами. А если мне понадобится 1024 разряда, мне что извращаться? Нет, гнать их всех надо!
11 май 04, 18:24    [672237]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
vitaly_p
Guest
tygra
Нуууу, тогда для вас что есть раздумия над запросом, в котором вам хочется видеть больше 256 таблиц.

Какие раздумия ? Есть модель, есть реляционная алгебра, запросы рождаются волшебно.
tygra
Я даже не представляю, где нужно хотя бы 100 таблиц????????

Всего лишь 100 ? А ведь реальный мир гораздо сложнее.
tygra
Ни одна БД вам не подойдет - тысячи две-три таблиц в одном запросе это вам не тут

Буду пользоваться той, у которой ограничения меньше.
Leonid
Что за манера, в конце концов, ограничивать целое чило 32/64 разрядами. А если мне понадобится 1024 разряда, мне что извращаться?

Нормальная аналогия. Пользуясь ею, некоторые СУБД предоставляют библиотеку для работы с числами большой разрядности. А некоторые "защитники" MS утверждают, что 64 разряда достаточно, и приводят в пример свои проекты, где у них счетчики и до 16-го разряда не доходят.
11 май 04, 18:54    [672339]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
Я даже не представляю, где нужно хотя бы 100 таблиц????????

чистая инсталяция Oracle Collaboration suite:

SQL> select count(*) from all_tables ;

COUNT(*)
----------
1360

думаю стандартная инсталяция Oracle Apliactions зашкалит за милион
11 май 04, 19:12    [672377]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Gt
SQL> select count(*) from all_tables ;
COUNT(*)
----------
1360
Gt вы насчитали все таблицы по всем схемам. Переводя на идеологию MS вы насчитали суммарное кол-во таблиц по всем БД одного сервера включая master. Если так рассуждать, то на MS, при желании, их то же можно настругать еще в большем кол-ве.

Тем не менее, я видел рабочую БД на MS, где кол-во таблиц было несколько сотен 400-500. Подчеркиваю БД, а не общее кол-во таблиц на всем сервере, т.к. для идеологии проектирования на oracle, это лучше всего укладывается в схему.
11 май 04, 19:46    [672440]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Gt., vitaly_p и др. мегамозгам

а не кинете пример запросика с хотя бы 50-ю таблицами?
максимум что мне удавалось - это 30 таблиц, да и то задача была очень надуманная.

тока не просто кинуть, а и объяснить какой смысл запроса
просто вы ссылаетесь это как на жуткое ограничение, но извините самый сильный аргумент который я видел тут это select count(*) from all_tables
Земля тоже например ограничена радиусом в 6370 км, но мне это ходить как-то не мешает. А вам может уже мешает? А то есть планеты где и радиус побольше...
11 май 04, 19:57    [672459]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649

чистая инсталяция Oracle Collaboration suite:

SQL> select count(*) from all_tables ;

COUNT(*)
----------
1360

думаю стандартная инсталяция Oracle Apliactions зашкалит за милион


И что все эти таблицы включены в один запрос? Вы сами-то поняли, что ответ Ваш совершенно не в тему?
11 май 04, 20:37    [672504]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649
Относительно общего количества таблиц на SQL Server - я лично работал с базой данных SAP R/3 на MS SQL Server, в которой было 11 000 таблиц.
11 май 04, 20:43    [672512]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
vitaly_p
Guest
Leonid
Тем не менее, я видел рабочую БД на MS, где кол-во таблиц было несколько сотен 400-500.

Это что, мерянье ? Вон в соседней ветке пишут, что в SAP R/3 11000 таблиц.
SergSuper
2 Gt., vitaly_p и др. мегамозгам

Друг, остынь
SergSuper
а не кинете пример запросика с хотя бы 50-ю таблицами?

Думаю, Вы сами в силах написать
SergSuper
максимум что мне удавалось - это 30 таблиц, да и то задача была очень надуманная.

И, конечно, представить задачи мощнее Ваших - выше Ваших способностей. А если напрячься ?
SergSuper
тока не просто кинуть, а и объяснить какой смысл запроса

Вы SQL плохо понимаете ?
SergSuper
Земля тоже например ограничена радиусом в 6370 км, но мне это ходить как-то не мешает. А вам может уже мешает? А то есть планеты где и радиус побольше...

Вы так и проходите всю жизнь по Земле. А люди уже в космос летают.
11 май 04, 20:55    [672521]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
vitaly_p
Это что, мерянье ? Вон в соседней ветке пишут, что в SAP R/3 11000 таблиц.
Я рад за них :) Тем не менее, Gt написал не в тему, к кол-ву таблиц в запросе это не относится.

vitaly_p
Думаю, Вы сами в силах написать
Не ответ.
Мы Вам пытаемся объяснить, что на практике такая необходимость сомнительна. Вы считаете по-другому, приведите пример из своей практики.

vitaly_p
А если напрячься ?
Вот и напрягитесь... ;)

vitaly_p
Вы так и проходите всю жизнь по Земле. А люди уже в космос летают.
Простите, незаметили, как Вы только что в орбитальной станции над головой пронеслись
11 май 04, 23:39    [672622]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
В догонку:
Нет, в принципе, можно представить необходимость объединения по union достаточно большого количества таблиц, но по join врядли...
11 май 04, 23:49    [672627]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
"640K ought to be enough for anybody." --Bill Gates, 1981

"DOS addresses only 1 Megabyte of RAM because we cannot imagine any applications needing more." --Microsoft, 1980, on the development of DOS.

"Windows NT addresses 2 Gigabytes of RAM which is more than any application will ever need." --Microsoft, 1992, on the development of Windows NT.

... точно так же как не стоит серьезно обсуждать те или иные достоинства баз данных с людьми, которым хочется запихнуть 256 таблиц в один запрос.

ЗЫ. не заметил про джоин, но сути в принципе это мало меняет. :)
12 май 04, 00:24    [672641]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
c127
Guest
2 ALL

Почитайте вопрос, почитайте ответ и не спрашивайте "зачем" нужны такие таблицы и представления, это лежит вне постановки задачи.

Из всех ограничений я лично столкнулся только с длиной строки (начальство изменило первоначальное ТЗ) и проблемой на вложенные представления. MSSQL2000 погиб когда глубина достигла 6, в техсаппорте сказали, что больше трех вообще не рекомендуют. Кто же мог ожидать, до объявленного числа 16 было еще так далеко. Слияние уровней и разворачивание представлений в запросы (код при этом возрос неменяно) не помогло. Проблемы конечно были решены, но пришлось поработать сверхурочно. А вы говорите "нужно продумывать заранее".

Еще (ИМХО) легко достижимо ограничение на глубину рекурсии SP, там по-моему не больше 6.

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

Например Watcom SQL сервер (теперь Sybase ASA) их не имел подобных ограничений даже когда помещался на дискету 1.44 и работал в win3.1 (еще он мог работать в OS/2 и новеле, поддерживал ссылочную целостность и SP). Из всего преречисленного была ограничена только длина строки, но это немного из другой оперы.

Так что в мелкософте системы проектируют или очень пожилые специалисты или очень плохие в прошлом студенты.
12 май 04, 02:11    [672663]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
vitaly_p
Вы SQL плохо понимаете ?

Знаете, я его понимаю настолько, что у меня есть сомнения что человек, которому мало 256 таблиц в одном запросе, сам чего-то в SQL понимает.

2 c127
оракловый оптимизатор в данной ситуации выбирает не лучший план.
(прим: по сравнению с MSSQLвским)

Так что в мелкософте системы проектируют или очень пожилые специалисты или очень плохие в прошлом студенты.


Страшно представить кто ж тогда в Оракле работает :)
12 май 04, 10:40    [673021]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 Gt.

Я то про 100 таблиц в join, а не об общем количестве. :)

У нас больше 500 - однако в join-ах больше 20 не бывает, да и 20 редкость.

2 vitaly_p

Ну так что, представите сюда в студию запрос с 50 таблицами? Или лучше 100?

По поводу ограничений - ну, по всякому бывает.
Вот вертолеты же умеют делать. А почему пропеллеры на автомобили не приделывают? Ограничение, блин!!!

-- Tygra's --
12 май 04, 11:02    [673094]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
2 Gt:
Про 640Кб и т.д. - это ваши самые серьезные и коренные претензии к MS? ;)

Я Вам уже говорил, что основатель IBM Томас Дж. Ватсон заявлял, что мировая потребность в компьютерах ограничится цифрой, меньшей 50. Вот такие "дураки" основали IBM ;)

Скоро и терабайтов мало будет...

Gt
ЗЫ. не заметил про джоин, но сути в принципе это мало меняет. :)
Меняет и координально.
12 май 04, 12:40    [673433]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Join из около 50-55 табличек (на самом деле это вьюшки на таблички, но роли это не играет)
select {field list}
from Specif f03030101__01
		join dv050103__01[Ac206] on [Ac206].doc=@doc and [Ac206].specif=f03030101__01.[id]
			left join ep02010204[Ac206_CodeAcFull] on [Ac206_CodeAcFull].element=[Ac206].le_id
			left join ep029901[Ac206_Name] on [Ac206_Name].element=[Ac206].le_id
		join dv050301[Contr] on [Contr].doc=@doc and [Contr].specif=f03030101__01.[id]
			left join ep029901[Contr_Name] on [Contr_Name].element=[Contr].le_id
			left join ep02011502[Contr_OKPO] on [Contr_OKPO].element=[Contr].le_id
		join dv040101[Date] on [Date].doc=@doc and [Date].specif=f03030101__01.[id]
		join dv050302[Dept] on [Dept].doc=@doc and [Dept].specif=f03030101__01.[id]
			left join ep02011505[Dept_CodeDep] on [Dept_CodeDep].element=[Dept].le_id
			left join ep01990103[Dept_MaskDep] on [Dept_MaskDep].element=[Dept].le_id
			left join ep029901[Dept_Name] on [Dept_Name].element=[Dept].le_id
		join dv06030102[Doc03030102] on [Doc03030102].doc=@doc and [Doc03030102].specif=f03030101__01.[id]
		join dv06030103[Doc03030103] on [Doc03030103].doc=@doc and [Doc03030103].specif=f03030101__01.[id]
		join dv06070101[DocSupplier] on [DocSupplier].doc=@doc and [DocSupplier].specif=f03030101__01.[id]
			left join dv020102[DocSupplier_Заголовок_DocNum] on [DocSupplier_Заголовок_DocNum].doc=[DocSupplier].doc_id and [DocSupplier_Заголовок_DocNum].specif=[DocSupplier].specif_id
			left join dv040102[DocSupplier_Заголовок_PDate] on [DocSupplier_Заголовок_PDate].doc=[DocSupplier].doc_id and [DocSupplier_Заголовок_PDate].specif=[DocSupplier].specif_id
			left join dv030105[DocSupplier_Заголовок_Sum] on [DocSupplier_Заголовок_Sum].doc=[DocSupplier].doc_id and [DocSupplier_Заголовок_Sum].specif=[DocSupplier].specif_id
			left join dv030124[DocSupplier_Заголовок_Sum_Operation] on [DocSupplier_Заголовок_Sum_Operation].doc=[DocSupplier].doc_id and [DocSupplier_Заголовок_Sum_Operation].specif=[DocSupplier].specif_id
			left join dv030106[DocSupplier_Заголовок_SumVAT] on [DocSupplier_Заголовок_SumVAT].doc=[DocSupplier].doc_id and [DocSupplier_Заголовок_SumVAT].specif=[DocSupplier].specif_id
		join dv06070201[GTD] on [GTD].doc=@doc and [GTD].specif=f03030101__01.[id]
			left join dv050603[GTD_Заголовок_Currency] on [GTD_Заголовок_Currency].doc=[GTD].doc_id and [GTD_Заголовок_Currency].specif=[GTD].specif_id
				left join ep029901[GTD_Заголовок_Currency_Name] on [GTD_Заголовок_Currency_Name].element=[GTD_Заголовок_Currency].le_id
			left join dv040101[GTD_Заголовок_Date] on [GTD_Заголовок_Date].doc=[GTD].doc_id and [GTD_Заголовок_Date].specif=[GTD].specif_id
			left join dv020102[GTD_Заголовок_DocNum] on [GTD_Заголовок_DocNum].doc=[GTD].doc_id and [GTD_Заголовок_DocNum].specif=[GTD].specif_id
			left join dv030119[GTD_Заголовок_Rate_C] on [GTD_Заголовок_Rate_C].doc=[GTD].doc_id and [GTD_Заголовок_Rate_C].specif=[GTD].specif_id
		join dv051110[IncomeType] on [IncomeType].doc=@doc and [IncomeType].specif=f03030101__01.[id]
			left join ep020199[IncomeType_Code] on [IncomeType_Code].element=[IncomeType].le_id
			left join ep01990113[IncomeType_MaskIncomeType] on [IncomeType_MaskIncomeType].element=[IncomeType].le_id
			left join ep029901[IncomeType_Name] on [IncomeType_Name].element=[IncomeType].le_id
			left join ep020419[IncomeType_P0199020419] on [IncomeType_P0199020419].element=[IncomeType].le_id
			left join ep030203[IncomeType_PercentNDS] on [IncomeType_PercentNDS].element=[IncomeType].le_id
		join dv050103[IncomeTypeAcTax] on [IncomeTypeAcTax].doc=@doc and [IncomeTypeAcTax].specif=f03030101__01.[id]
		join dv05111001[IncomeTypeGroup] on [IncomeTypeGroup].doc=@doc and [IncomeTypeGroup].specif=f03030101__01.[id]
			left join ep020199[IncomeTypeGroup_Code] on [IncomeTypeGroup_Code].element=[IncomeTypeGroup].le_id
			left join ep029901[IncomeTypeGroup_Name] on [IncomeTypeGroup_Name].element=[IncomeTypeGroup].le_id
			left join ep019807[IncomeTypeGroup_P0199019807] on [IncomeTypeGroup_P0199019807].element=[IncomeTypeGroup].le_id
			left join ep01990118[IncomeTypeGroup_P019901990118] on [IncomeTypeGroup_P019901990118].element=[IncomeTypeGroup].le_id
		join dv050303__01[MOL] on [MOL].doc=@doc and [MOL].specif=f03030101__01.[id]
			left join ep029901[MOL_Name] on [MOL_Name].element=[MOL].le_id
			left join ep02011507[MOL_TabNum] on [MOL_TabNum].element=[MOL].le_id
		join dv040303[NNDate] on [NNDate].doc=@doc and [NNDate].specif=f03030101__01.[id]
		join dv020113[NNNum] on [NNNum].doc=@doc and [NNNum].specif=f03030101__01.[id]
		join dv01039907[NNNumNot] on [NNNumNot].doc=@doc and [NNNumNot].specif=f03030101__01.[id]
		join dv010101[Num] on [Num].doc=@doc and [Num].specif=f03030101__01.[id]
		join dv050303[Person] on [Person].doc=@doc and [Person].specif=f03030101__01.[id]
			left join ep029901[Person_Name] on [Person_Name].element=[Person].le_id
			left join ep02011507[Person_TabNum] on [Person_TabNum].element=[Person].le_id

		join dv030119[Rate_C_St] on [Rate_C_St].doc=@doc and [Rate_C_St].specif=f03030101__01.[id]
		join dv030420[STax] on [STax].doc=@doc and [STax].specif=f03030101__01.[id]
		join dv050302__07[Store] on [Store].doc=@doc and [Store].specif=f03030101__01.[id]
			left join ep02011505[Store_CodeDep] on [Store_CodeDep].element=[Store].le_id
			left join ep01990103[Store_MaskDep] on [Store_MaskDep].element=[Store].le_id
			left join ep029901[Store_Name] on [Store_Name].element=[Store].le_id
where f03030101__01.doc=@doc and f03030101__01.type='03030101__01'
Зачем нужно? Выборка строк документов. Структура хранения документа - см. А. Тенцер "База данных - хранилище объектов"
Случай, конечно, самый тяжелый, В среднем табличек в join около 10-11, сервер ведет себя весьма кошерно.
select count(*) from sysobjects where type in ('U','V')

----------- 

6089
До 256 табличек еще далеко - один join (иногда бывает до 3) - одна колонка в логической "табличке".
2c127
а в Sybase, по моему, ограничение на кол-во табличек в join - 50, а не то, что Вы сказали :-)
12 май 04, 13:26    [673623]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
vitaly_p
Guest
Похоже, "защитники" MS могут воспринимать информацию только на реальных примерах. Главный аргумент - "покажи".

- Зачем нужна кредитка, у меня все деньги в карман помещаются. И у всех должны
помещаться. А у кого не помещается - жить не умеют.
- Не совсем так...
- Ну, покажи свою кучу денег.

То ли от отсутсвия знакомства с концепциями реляционной алгебры (не понимают, что такое эти таблицы, join в СУБД), то ли от слабости воображения они не могут понять, откуда могут взяться десятки тысяч таблиц в БД и join из сотен таблиц в одном запросе. Аргументы вроде "больше я не видел", "у меня в системе такого нет" - неужели вы считаете их весомыми ? На таком уровне разговаривать нет смысла.
12 май 04, 14:20    [673778]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить