|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 03 Apr 2001 16:07:17
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Drema wrote in message <9ac4e8$3u4$1@host.talk.ru>...
>Да было у меня так, пол года поработали, база стала расти,
>отклик сервера (момент выдачи первых строк запроса) стал
>медленным, поэтому и переделал.. (сейчас и уже года 2 появляется
>моментально)
Вв-во, типичная, честно говоря, аргументация не умеущего оптимизировать
запросы программиста.
Запросы надо было оптимизировать, индексы строить нужные.
>Сделай таблицу с 10000 строками (Справочник Клиентов) и соедини ее с 10-ю
>таблицами (в каждой по 100 строк), составь SELECT по своему варианту.
Ты думаешь, в нашей базе этого не делают ? И думаешь, у нас ТАК МАЛО
строк в таблицах ? Все летает.
>Если вы боитесь термина денормализация (кстати это вполне официальный и
науке
Это не в науке он известен, это в правтике программирования. Да, иногда
приходиться, понимаю. Hо уж не на вшивой таблице из 10 тыщ записей.
>А поподробнее можно? Что за неудобность? Из-за клиента?
См. другое письмо в треде.
>Мне нужена глабальная последовательность (уникальный во всем
>множестве всех ПК). Кстати, IMHO, такая задача вообще не имеет решения без
IDENTITY в одной таблице.
>блокировки, едиственный выход - уменьшить размер блокировки,
>то есть сделать транзакцию как можно меньшей.
Естественно. Единственное решение БЕЗ блокировки - IDENTITY.
>Особых неудобностей не ощущаю :)
Медленно это.
>Конкретный пример можно какой-нибудь?
Hу не знаю. Мне надо перемножить декартовым произведением 3 справочника
и, выкинув некоторые комбинации, получившиеся строки положить
куда-нибудь для последующего использования. Допустим по запросу пользователя
эта операция может быть проделана N раз, т.е. пользователь вправе получить
N одинаковых строчек. А потом строчки надо обрабатывать.
Пример надуманный, на самом деле у меня много примеров из реальной
жизни, но только для их изложения надо в предметную область въезжать.
--------------------
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
