|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Drema 2:5020/400 03 Apr 2001 13:17:16
To : Ilya Zvyagin
Subject : RE: Дремина хитрость 2
--------------------------------------------------------------------------------
>From: news [mailto:news@host.talk.ru]On Behalf Of Ilya Zvyagin
>>Да. А ссылки (целочисленные ключи) запоминаются в другой таблице.
>Это денормализация, ты в курсе ? Со всеми вытекающими ...
Конечно в курсе! Более того - это осознанная денормализация.
...
>>будет быстрее выполнятся?
>Быстрее будет выполняться
>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
Да было у меня так, пол года поработали, база стала расти,
отклик сервера (момент выдачи первых строк запроса) стал
медленным, поэтому и переделал.. (сейчас и уже года 2 появляется
моментально)
Много быстрее будет выполнятся:
SELECT Pole1, Pole2
FROM Table
>и при этом у тебя в базе не будет избыточных данных ( которые надо хранить,
>а хранят их на дисках ... ).
>Я конечто не знаю, но все люди, которых нам приходилось тестировать
>для приема на работу и которые говорили что-то про денормализацию данных
>в их проектах, очень сильно плавали в вопросах оптимизации запросов.
>Были правда и работающие на каких-то дремучих серверах, но у тебя же
>нормальный сервер, с нормальным оптимизатором.
>Короче, медленно работающие запросы не есть причина для денормализации,
>надо запросы оптимизировать.
Сделай таблицу с 10000 строками (Справочник Клиентов) и соедини ее с 10-ю
таблицами (в каждой по 100 строк), составь SELECT по своему варианту.
Засеки время когда начинаю лезть первые строки...
Теперь замерь скорость в моем случае...
Если вы боитесь термина денормализация (кстати это вполне официальный и науке
известный способ оптимизации), то можете называть это простым кешированием
данных.
>>>>См. выше :) Посоветуй лучше способ как получить уникальный счетчик не для
>>>>одной таблицы а сразу для всех.
>IMHO лучше IDENTITY ничего нет. У нас в Sybase есть одно неудобство,
>с ним связанное, которое просто сводит на нет возможность его применения.
>Если бы не оно - везде бы применяли его.
А поподробнее можно? Что за неудобность? Из-за клиента?
>Это самый лучший и штатный способ генерации ключей.
>У нас же (пока по крайней мере) применяется
>select isnull( max(id), 0 ) + 1
>from theTable
...
>Кстати, не понятно, почему тебе его нельзя использовать.
>Ааа, из-за EXEC-а, да ?
Мне нужена глабальная последовательность (уникальный во всем
множестве всех ПК). Кстати, IMHO, такая задача вообще не имеет решения без
блокировки, едиственный выход - уменьшить размер блокировки,
то есть сделать транзакцию как можно меньшей.
>>Я делаю курсор, а в нем вставляю.
>Вот именно, что приходиться только ради генерации ключа курсор делать.
Особых неудобностей не ощущаю :)
>>А вам часто нужны массовые вставки?
>Иногда все же нужны. Hаверное, процентов в 20 случаев вставки.
>Бывают неидентифицируемые в предметной области сущности, которые нужно
>генерировать пачками - это типичный случай, когда нужно IDENTITY,
>и без него просто никак. Ключ на 1000 записей не сгенерируешь.
Конкретный пример можно какой-нибудь?
--
Drema. mailto:dremkin@avtlg.ru
http://i.am/dremkin
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Talk.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
RE: Дремина хитрость 2