|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 11 Apr 2001 06:49:55
To : All
Subject : Re: Re[2]: FW: Дремина хитрость 2
--------------------------------------------------------------------------------
Hi !
> T> [Попытка скипнута] Есть подозрение, что от десятков тысяч
> T> записей и десятка клиентов эта схема начнет вгонять
> T> сервер в некоторые тормоза.
>
> Что именно указывает на такую вероятность? Hа данный момент
> более 600 таблиц, в сумме более миллиона строк,
:-)
1 000 000 / 600 ~ 1500 строк на таблицу ?
>в среднем от
> 30 до 50 клиентов - тормозов не замечается.
А кто только что про денормализацию рассказывал, как средство больбы с
указанными тормозами ?
> T> По-моему ты слегка увлекся декларативностью и передоверил глупой
> T> машине слишком много достаточно тонких вещей. Hа мой взгляд - тут надо
> T> искать компромисса и он лежит в работе "на чтение" - посредством
> T> запросов написанных таки руками и оптимизированных.
>
> То есть для каждой таблицы писать запросы вручную? Зачем?
Затем, что именно запросами на выборку отображаемых данных как правило и
определяется быстродействие системы в целом.
При больших объемах данных и изрядной нагрузке - тут окажется узкое место.
Твои танцы с FAST(30) - тому пример. Hо что-то я не верю, что можно машине
доверить еще и хинты расставлять. Для этого - придется тебе реализовать
оптимизатор поумнее серверного.
> Всеже я не понял почему нужно разбить на две части "чтение"
> и "запись"...
Потому, что "чтение" - определяет быстродействие
А "запись" - определяет надежность и согласованность данных и вот тут - есть
поле для декларативности.
--
Bye ...
Тенцер А.Л.
tolik@katren.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
