|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Serge Prydatchenko 2:463/190.3 14 Jun 2001 18:25:56 To : Ilya Bricker Subject : Re: вопросы по Web-проекту -------------------------------------------------------------------------------- Thursday June 14 2001, Ilya Bricker wrote to All: >> 1) Как лучше реализовать "Online alert" для Buddy-list-а и приход >> "instant message" средствами IIS+MSSQL так, чтобы оно требовало минимум >> ресурсов сервера? IB> Hужно как можно меньше напрягать сервер БД по каждой перезагрузке IB> страницы, он просто загнется если не будет кэширования и обработки IB> на среднем уровне. Идея в том что в онлайне скорее всего на порядок IB> меньше пользователей, чем учетных записей в базе. IB> Предлагаю сделать компоненту, которая бы отвечала за подсистему IB> "instant messaging", описать ее функциональность. IB> Она должна кэшировать Buddy-list-ы активных пользователей, вести [skipped] Да, понятно, таки придется делать COM-объекты. >> 2) Я собираюсь использовать глобальные суррогатные ID типа IB> uniqueidentifier для >> облегчения сиcтемы прав доступа (у каждого объекта типа профиля, [skipped] >> я решил делать все суррогатные ключи типа uniqueidentifier, >> генерировать >> их newid() и привязывать единые ACL к ним. Правильно ли делать такие ПК >> некластерными (к тому же помним о RAID)? IB> Кластерным может быть только один индекс. IB> Если нет безусловных предпосылок для выбора того или иного индекса IB> на роль кластерного, то видимо на данном этапе проектирования это пока IB> не важно :-) Hо рано или поздно вопрос с кластерными ключами все равно нужно будет решать... >> Что будет с производительностью джойнов по сравнению с bigint PK? IB> Думаю, существенно ниже. А чем обычный int не устраивает? 4 миллиарда. А кстати - вроде нет, по данным MS и независимых разработчиков :) производительность якобы точно такая же. А не устраивает по причине отсутствия последовательностей / генераторов и наличия newid(). >> Стоит ли какие-либо другие индексы делать кластерными, какие тогда? IB> имхо рано думать об этом на начальных этапах. Может быть, выгоднее IB> будет впоследствии денормализовать модель, вставить лишнее поле IB> и сделать кластер по нему. Да я сразу слегка денормализовывал, сразу понятно, что для вывода имени и фотографии Person of the Hour совершенно необязательно делать join с Persons, итп. Для некоторых таблиц кластеры просятся в основном по полям типа Creation_Datetime, в которые вставляются значения "по порядку", которые потом будут участвовать в запросах (чат, например, или запрос типа New Personals) но необходимость наличия кластерного индекса в каждой таблице для меня неясна, я в Оракле всегда делал все индексы включая PK обычными и выносил в другой таблспейс на другой диск. Если ключ IDENTITY или Creation_Datetime (не PK) и идет подряд, то понятно, что кластерный индекс - благо. А что будет со скоростью вставок строк с идущими не подряд значениями кластерного ключа? MSSQL не займется физической сортировкой частовставляемой таблицы при каждой вставке? То есть, верно ли утверждение, что "Hадо обязательно всеми силами делать для всех таблиц кластерный индекс - и воздастся"? С наилучшими пожеланиями... Serge Человек способен понять лишь то, что не превосходит уровень его сознания. --- * Origin: Per aspera ad astra! (FidoNet 2:463/190.3) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/27643b2901ba.html, оценка из 5, голосов 10
|