|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 03 Apr 2001 10:49:55
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Drema* wrote in message <9aaiqg$pbj$1@host.talk.ru>...
>Да. А ссылки (целочисленные ключи) запоминаются в другой таблице.
Это денормализация, ты в курсе ? Со всеми вытекающими ...
>:) Ок, что будет быстрее выполнятся вот это:
>SELECT
> (SELECT FNAME FROM Table1 T WHERE T.KEY=main.ref1) as PoleRef1,
> (SELECT FNAME FROM Table2 T WHERE T.KEY=main.ref2) as PoleRef2,
> (SELECT FNAME FROM Table3 T WHERE T.KEY=main.ref3) as PoleRef3,
> (SELECT FNAME FROM Table4 T WHERE T.KEY=main.ref4) as PoleRef4,
> (SELECT FNAME FROM Table5 T WHERE T.KEY=main.ref5) as PoleRef5
> pole1,
> pole2,
> poleN
>FROM TAbleMain main
>
>или вот это:
>
>SELECT
> PoleRef1,
> PoleRef2,
> PoleRef3,
> PoleRef4,
> PoleRef5,
> pole1,
> pole2,
> poleN
>FROM TAbleMain main
>А теперь еще добавьте возможность фильтрации и сортироки по вычисляемым
полям, что
>будет быстрее выполнятся?
Быстрее будет выполняться
SELECT
Table1.FNAME as PoleRef1,
Table2.FNAME as PoleRef2,
...
pole1,
pole2,
poleN
FROM TAbleMain main, Table1 , Table2, Table3
where Table1.KEY=main.ref1
and Table2.KEY=main.ref2
...
и при этом у тебя в базе не будет избыточных данных ( которые надо хранить,
а хранят их на дисках ... ).
Я конечто не знаю, но все люди, которых нам приходилось тестировать
для приема на работу и которые говорили что-то про денормализацию данных
в их проектах, очень сильно плавали в вопросах оптимизации запросов.
Были правда и работающие на каких-то дремучих серверах, но у тебя же
нормальный сервер, с нормальным оптимизатором.
Короче, медленно работающие запросы не есть причина для денормализации,
надо запросы оптимизировать.
>>>См. выше :) Посоветуй лучше способ как получить уникальный счетчик не для
>>>одной таблицы а сразу для всех.
IMHO лучше IDENTITY ничего нет. У нас в Sybase есть одно неудобство,
с ним связанное, которое просто сводит на нет возможность его применения.
Если бы не оно - везде бы применяли его.
Это самый лучший и штатный способ генерации ключей.
У нас же (пока по крайней мере) применяется
select isnull( max(id), 0 ) + 1
from theTable
Это вобщем то же самое узкое место (потенциальное), но железо сервера
пока тормозит больше.
Кстати, не понятно, почему тебе его нельзя использовать.
Ааа, из-за EXEC-а, да ?
>>Кстати, еще для чего все эти счетчики не годяться ни в какую -
>>для массовых вставок. Так что лучше IDENTITY ничего придумать нельзя.
>Я делаю курсор, а в нем вставляю.
Вот именно, что приходиться только ради генерации ключа курсор делать.
>А вам часто нужны массовые вставки?
Иногда все же нужны. Hаверное, процентов в 20 случаев вставки.
Бывают неидентифицируемые в предметной области сущности, которые нужно
генерировать пачками - это типичный случай, когда нужно IDENTITY,
и без него просто никак. Ключ на 1000 записей не сгенерируешь.
--------------------
Ilya Zvyagin
e-mail: masterziv@mail.ru - personal, ziv@fct.ru - business.
ICQ UID: 29427861(MasterZIV)
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
