Bankir.Ru
7 декабря, среда 13:33

Объявление

Свернуть
Пока нет объявлений.

база Diasoft 5NT

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • база Diasoft 5NT

    В нашем банке установили Diasoft 5 NT работающая под SQL Server 2000
    смотрел я их базу, странная она какая-то.
    не используются кластерные индексы
    не используются первичные/внешние ключи
    все селекты с nolock
    в большинстве селектов содержит указание на то какой использовать индекс
    тестирование показало что не использование кластерных индексов снижает производительность, достаточно сильно, а использование подсказок оптимизатору не оправдано, так как SQL Server строит план на много лучше.
    Почему у них такая база и с чем это связано.

  • #2
    Наверное, всвязи с работой ещё и под Sybase...

    Комментарий


    • #3
      а что если программа пишется под несколько серверов то можно одну базу делать нормально, а другую как попало. И вообще программа то очень даже и не дешевая. Есть два пути поднять производительность
      - поднять аппаратное обеспечение
      - оптимизировать запросы
      В связи с тем что по контракту не разрешается менять исходный код базы, остается выбрать первый вариант, а на это тоже нужны деньги.
      Хотелось бы узнать мнение специалистов которые занимается администрированием БД и обслуживанием АБС.

      Комментарий


      • #4
        serge_p
        можно одну базу делать нормально, а другую как попало.
        Это происки. Во первых, не так уж они отличаются. Во-вторых, тестируется на обеих платформах.
        SQL Server строит план на много лучше.
        Это вы батенька, загнули. План, как правило, не бывает лучше или хуже. Оптимальный бывает только один. И сервер строит его далеко не всегда.
        все селекты с nolock
        И что? Молодцы, думают об одновременной работе многих пользователей. Вам нужна была однопользовательская система?
        Насчет кластерных индексов и ключей - это долгий теоретический разговор и тут тоже на все однозначно.

        Диасофт можно много в чем обвинить - в первую очередь в неаккуратности, неоптимальной структуре данных и непродуманных решениях.
        Но вот в отсутствии знаний и опыта - нельзя. Проблемы кроются именно в кривой структуре базы и методами администрирования не решаются (поверьте,пробовали).
        Есть реально 2 пути повышения поизводительности:
        1. Фиксировать проблемы как ошибки и жестко добиваться их исправления.
        2. Действительно, поднять аппаратное обеспечение. Самое эффективное - увеличивать размер кэша (более тонкая настройка, типа размера страниц серьезно не влияет). Благо, память сейчас не слишком дорогая.

        Комментарий


        • #5
          loo Диасофт можно много в чем обвинить - в первую очередь в неаккуратности, неоптимальной структуре данных и непродуманных решениях.
          Но вот в отсутствии знаний и опыта - нельзя.

          Давно так не смеялся!

          Вы меня конечно извините, но на кой мне их знания и опыт, если они ими пользоваться не умеют?

          Сорри за флейм. Не выдержал.

          Комментарий


          • #6
            без кластерного индекса работает медленней, если человек понимает в БД то он не будет спорить, что это действительно так. Но вот почему диасофт их не использует. А насчет nolock это означает что можно считывать не закомиченные транзакции, что есть не очень то и хорошо. Например при формирование отчета запускается ХП, в момент выборки данных некий пользователь пытается вставить запись но происходит откат транзакции. то в итоге получается что запись то не вставлена, а в построении отчета то она участвует. А это извените банк, сдеся деньги. nolock на многопользовательскую работу не влияет, это вообще немного не суда. И еще в 1 случае из 1000 подсказки оптимизатору оправданы. Производительность падает в разы!!! вот поэтому у Diasoft на 10 юзеров надо 2-х процовый сервак. А ведь можно и один Пень 500. вот тока исходный код базы менять нельзя. А такой мощный механизм БД как ограничение целосности вообще не используется.

            Комментарий


            • #7
              Отказ от FK - это гибкость при изменении версий.
              PK - есть, чисто формальные, но нет ссылочных констрейнтов, также по аналогичным причинам

              Отказ от clustered index - не знаю зачем, я многие таблицы перестроил на кластерность.
              Кстати для Loo - кластерность в 3.2 кажется еще была...

              в большинстве селектов содержит указание на то какой использовать индекс - очень правильная вещь, двумя руками "за", особенно для Sybase - там оптимизатор изрядный шалун, да и в MS - не все гладко. И лучше он построить может - если программер начудил, но это лечится, а эффективность оптимизатора - вещь условная.

              тестирование показало что... - пример тестирования в студию!!!


              Для Анюты
              А у нас глючит постоянно ... - у вас База глючит? н-да ну тут ничем не помогут...

              Вот что для меня супер-тайна, так это почему "pLIFOFIFO" - без индексов? кто виноват?
              С уважением, Максаев Андрей.

              Комментарий


              • #8
                Для serge_p -
                Например при формирование отчета запускается ХП, в момент выборки данных некий пользователь пытается вставить запись - в момент получения отчета, если какая-то ошибка вы запись просто никогда не увидите, у Диа в триггерах ничего не проверяется (только удаления весьма второстепенных сущностей), все проверки до вставки и до сохранения. И если вы видите ошибку, которая может откатить вставку - то это физические проблемы с БД, извольте их решать независимо от Диа.

                Не согласен с фразой
                И еще в 1 случае из 1000 подсказки оптимизатору оправданы - смею Вас заверить, гораздо чаще, но если вам безразлично качество и скорость отработки запросов не пишите хинты. А могу я узнать о размере вашей БД?

                Еще более не согласен с
                Производительность падает в разы!!! вот поэтому у Diasoft на 10 юзеров надо 2-х процовый сервак - Чушь какая... Мы вообще о 5нт говорим? пень166 с раидом - легко потянет работу 10 человек, с базой размером до 2-3 гиг.

                А фраза nolock на многопользовательскую работу не влияет - заставляет вообще задуматься о Вашем реальном опыте общения MS SQL, да и с Диа 5НТ.
                С уважением, Максаев Андрей.

                Комментарий


                • #9
                  в отчетах попробуйте вставить команду
                  set forceplan off -- включает оптимизатор
                  set forceplan on -- соответственно отключает
                  иногда это сокращает время выполнения отчета, но не всегда
                  Если у Вас есть Artizan, то понаблюдайте за SQL , может у Вас
                  бывают блокировки, в это время все тормозится.

                  Комментарий


                  • #10
                    andrey_seek
                    Да, в 3.2 много почти по всем таблицам кластерные индексы, но радости это не добавляет. Использовались они, в первую очередь не для ускорения последовательного доступа, а для разнесения по страницам последовательно вводимых данных, для уменьшения блокировок на вводе. Андрей, а когда версии меняешь, они не пытаются ли перестроить кластерные индексы? Это ж смерть. Или ты свои сделал?
                    А чей оптимизатор хуже - MS или Sybase - тут еще разобраться надо. Оба хороши, причем каждый по-своему.
                    serge_p
                    Насчет nolock. Любой сколько-нибудь серьезный отчет в 5nt получается с использованием псевдо-временных таблиц (вот помещение временных таблиц в основную базу - это действиетльно перл, слов нет). Грязного чтения, при этом, естественно, быть не может. Мест, где nolock используется на по делу, я вот даже не припомню.

                    Комментарий


                    • #11
                      Drozd
                      в отчетах попробуйте вставить команду
                      set forceplan off -- включает оптимизатор
                      set forceplan on -- соответственно отключает
                      А вот этого лучше не надо. Беретесь оптимизировать отчет - так подходить к этому стоит серьезно - смотреть где не попадает, почему. Два-три часа потратить придется, зато будет результат. А так - пальцем в небо.

                      Комментарий


                      • #12
                        Для Loo
                        Андрей, а когда версии меняешь, они не пытаются ли перестроить кластерные индексы?
                        Слава богам, на таблицах типа tDeal, нет не пытаются, ну только на p-таблицах.

                        Или ты свои сделал?
                        Я у себя, дропнул индексы XPK_, и создал кластерные 'alter table..' с такими же названиями. Помнится только один раз какая-то проблема была при заливке патчей... Но я собственно и не жду от этого круто возросшего быстродействия, так для порядку токмо ...


                        Хи-хи-хи, а попробывал бы товарищ, какой нибудь славный депозитарный отчет запустить, типа оборотно-сальдовой ведомости за последний квартал со сканом по tDepartment.DepHash без nolocka, - всеб попадали со смеху, если бы минут пять не смогли ни одной операции сделать...

                        А вообще-то замечаю что tDealProtocol и tRest - занимают почти 30% БД, а индексы 3/5 от всего размера - видимо у всех так?
                        С уважением, Максаев Андрей.

                        Комментарий


                        • #13
                          Да я ж не собираюсь чужие отчеты оптимизировать.

                          У нас была непонятная ситуация:
                          Замедлилась работа сервера, причем в это время пользователи
                          уже почти все вышли из Д-та (был конец рабочего дня).
                          Performance monitor показывал, что сервер загружен > 100%.
                          Блокировок не было.
                          Д-т прислал тест

                          use testdb
                          go
                          create table pSwiftLine11 (SPID numeric(15,0),Number int)
                          go
                          create index X1 on pSwiftLine11 (SPID,Number)
                          go

                          set nocount on
                          go
                          select Convert(varchar(50),getdate(),109)
                          declare @i int
                          select @i = 0
                          --begin tran
                          while @i 20000
                          begin
                          insert into pSwiftLine11 (SPID,Number) values (@@spid,@i)
                          select @i = @i + 1
                          end
                          --commit tran
                          select Convert(varchar(50),getdate(),109)
                          go
                          set nocount off
                          go

                          drop table pSwiftLine11
                          go

                          - вставка 20000 записей в pSwiftLine11, так он выполнялся 15 минут,
                          вместо 10 секунд как сейчас
                          причину замедления так и не поняли,
                          перезагрузка сервера не помогла, после перезагрузки я был один на сервере.
                          Торможение пропало само.
                          На следующий день написал запрос, чтобы при случае увидеть хоть что то ,
                          но ситуация не повторяется.
                          Если есть какие соображения, заранее спасибо.


                          use workdb
                          --sp_helptext sp_who
                          select u.Brief,u.FIOBrief, sp.spid,sp.cmd
                          from master.dbo.sysprocesses sp ,tUser u
                          -- where spid = @spid
                          where sp.cmd > 'AWAITING COMMAND'
                          and sp.cmd > 'TASK MANAGER'
                          and u.Brief = sp.loginame

                          USE master
                          EXEC sp_who 'active'

                          Комментарий


                          • #14
                            Для Drozd - хорошо вам , у нас в конце рабочего дня все только заходят в Диа...

                            Я для поиска заблокированных ресурсов пользуюсь такой SP


                            drop proc sp_lock1
                            select 'proc sp_lock1 -- информация о блокировках ', getdate()
                            go

                            create proc sp_lock1
                            as
                            set nocount on

                            select distinct substring(u.Name,1,10), substring(so.Name,1,35), t.Name, li.req_spid as SPID,
                            substring(ltrim(rtrim(loginame))+'/'+ ltrim(rtrim(nt_username))+'/'+ ltrim(rtrim(hostname))+'/'+ ltrim(rtrim(program_name)),1,50) as 'Loginame/Nt_Username/Hostname/Program_name'
                            from master..syslockinfo li (NOLOCK)
                            join sysobjects so (NOLOCK)
                            on so.ID = li.rsc_objid and so.xtype = 'U'
                            join master.dbo.spt_values u (NOLOCK)
                            on u.type = 'L' and u.number = li.req_mode + 1 and u.Name not in ('Sch-S')
                            join master.dbo.spt_values t (NOLOCK)
                            on t.type = 'LR' and t.number = li.rsc_type
                            join master.dbo.sysprocesses sp (NOLOCK)
                            on sp.spid = li.req_spid
                            -- where req_spid = 79
                            order by 1

                            go

                            grant exec on sp_lock1 to dia_public
                            go


                            Если если блокировка типа X на таблицу или на индекс - надо разбираться почему...

                            Кстати 100% -загрузки виноват - не обязательно Диа и не обязательно SQL, что у вас с дисковым массивом? может он целостность зарядил восстанавливать? Может стоило бы посмотреть Performace по подсистемам? ЦПУ, память, диск, кэш и т.п.?[/U]
                            С уважением, Максаев Андрей.

                            Комментарий


                            • #15
                              Для andrey_seek

                              Я вообще то не Admin, (поддерживаю РКО, Дилинг, Ком. кредиты, пишу всякие отчеты), так что многое просто не знаю. За совет спасибо.
                              Могу прислать программу- монитор (приятель писал), показывает кто работает
                              и кто кого блокирует, как Artizan.
                              Мой адрес:
                              vladimir@svabank.ru

                              Комментарий


                              • #16
                                Thanx, наверное не надо, глаз-б мои на них не глядели, на всех этих пользователей с ихними блокировками ...

                                Да и не любитель я чужие программы в сетке банка запускать...

                                Еще раз, спасибо.
                                С уважением, Максаев Андрей.

                                Комментарий


                                • #17
                                  Согласен.

                                  Комментарий


                                  • #18
                                    andrey_seek
                                    Я у себя, дропнул индексы XPK_, и создал кластерные 'alter table..' с такими же названиями. Помнится только один раз какая-то проблема была при заливке патчей... Но я собственно и не жду от этого круто возросшего быстродействия, так для порядку токмо ...
                                    Андрей!
                                    Почитал вчера одну умную книжку. Про кластерные индексы там написано, что их однозначно не рекомендуется делать по искусственным первичным ключам (то бишь ID по диасофтовски). Я был прав, они ускоряют запросы типа >, , between, где идет последовательное сканирование по индексу (Типа ResourceID, OperDate по tOperPart был бы, возможно, полезен).

                                    Олег

                                    Комментарий


                                    • #19
                                      что за книжка? В официальном пособии Микрософт написано другое.

                                      Комментарий


                                      • #20
                                        2Drozd

                                        >У нас была непонятная ситуация:
                                        ========
                                        Замедлилась работа сервера, причем в это время пользователи
                                        уже почти все вышли из Д-та (был конец рабочего дня).
                                        Performance monitor показывал, что сервер загружен > 100%.
                                        Блокировок не было.
                                        Д-т прислал тест

                                        use testdb
                                        go
                                        create table pSwiftLine11 (SPID numeric(15,0),Number int)
                                        go
                                        create index X1 on pSwiftLine11 (SPID,Number)
                                        go
                                        =======

                                        Это классический тест на работу Write Back cache. Если учесть - что таблица создается пустая - то скорость выполнения 20 000 insert не должна превышать 10-15 секунд. Обрати внимание - на закомментаренные begin/Commit tran - попробуй их раскомментарить и сравнить времена.
                                        Хорошо работающий RAID с отложенной записью и батарейкой должен давать одинаковые времена. Если же заметишь отличия в 5 и больше раз - плохая дисковая подсистема. В 10 раз - ужасно плохие диски :-))

                                        Удачи !

                                        Комментарий


                                        • #21
                                          Для Loo
                                          Ну я вижу что обычно 9 join-ов из 10 - это связь на ИД записи, и если там PK - это однозначно выигрыш по скорости.

                                          Вопрос был к Диа (и считаю в части PK - его очень справедливым) - почему они вообще их не используют, ни в каком виде?

                                          А в общем я извиняюсь, я не очень понял, то что ты хотел сказать (23-10-2003 16:02), правильно ли я понял из твоего поста -

                                          что PK ускоряют только ">, , between" - не могу с этим согласиться, хотя нет соглашусь, если вникнуть поиск по ИДу записи нужен для чтения чего-нибудь еще и однозначно потребует чтения какой-либо инфы из таблицы, а это снова обращение к странице данных, хотя мы страницу быстрее найдем, но на немного быстрее, нда дожили PK - никому не нужен...

                                          что индекс "ResourceID, OperDate" по tOperPart необходим PK - тоже не могу согласиться, это не уникальная комбинация, хотя можно сделать кластерный, но не уникальный индекс - но тогда вставка любой новой и изменение поля счета, даты записи - будет иногда порождать нехилый процесс разделения страницы таблицы

                                          Для bantik
                                          У меня с закомментаренным "begin tran" - 2 минуты 6 сек,
                                          с явной транзакцией - секунд 6.

                                          Хотя безусловно сервачок до ума не доведен, аппаратного raid-а нет, да и диски не оптимально разведены.
                                          2х933 PIII- 1024 RAM - 4х18gb какие-то HP (явно не 10к об.сек)
                                          Надо поднять вопрос перехода с (когда-то) тестовой системы.

                                          Нутка померимся?

                                          PS. Кстати маленький нюанс, я сделал не просто кластерные, а primary key.
                                          Последний раз редактировалось andrey_seek; 24.10.2003, 10:23.
                                          С уважением, Максаев Андрей.

                                          Комментарий


                                          • #22
                                            andrey_seek
                                            Мы говорим, про кластерные индексы, помнишь? :-).
                                            если вникнуть поиск по ИДу записи нужен для чтения чего-нибудь еще и однозначно потребует чтения какой-либо инфы из таблицы, а это снова обращение к странице данных
                                            Так вот при ссылке по ID, тебе потребуется чтение +1 страницы , если индекс не кластерный. Но при чтении по кластерному индексу тебе потребуется перебрать больше страниц, чтобы спозиционироваться, т.к. сами стриницы данных содержат гораздо меньше записей, чем страницы индекса. В итоге по i/o ты проигрываешь. И очень сильно теряешь производительность на операциях insert.
                                            Что касается Primary Key, то в чем разница по сравнению с обычным уникальным индексом в плане обработки - науке не известно.

                                            Комментарий


                                            • #23
                                              andrey_seek
                                              Кстати, вот пример:
                                              Таблица tSwiftLine в нашей базе. Записей - много.
                                              Индексы.
                                              CREATE UNIQUE CLUSTERED INDEX XPKE_541
                                              ON dbo.tSwiftLine(SwiftID,Number)
                                              go
                                              CREATE UNIQUE INDEX XAK1tSwiftLine
                                              ON dbo.tSwiftLine(SwiftID,Tag,Number)
                                              ON nc_indexes
                                              go

                                              Выбрал такую запись, чтобы при позиционировании по обоим индексам находилась она одна.

                                              select SwiftID, Tag, Number, TextLine
                                              from tSwiftLine (INDEX XPKE_541)
                                              where SwiftID = 647130
                                              and Number = 2100
                                              and Tag = '|BPARNM|'

                                              select SwiftID, Tag, Number, TextLine
                                              from tSwiftLine (INDEX XAK1tSwiftLine)
                                              where SwiftID = 647130
                                              and Number = 2100
                                              and Tag = '|BPARNM|'

                                              Результат:
                                              scan count 1, logical reads: (regular=5 apf=0 total=5)
                                              Одинаковый в обоих случаях!!!

                                              serge_p
                                              Книжка, скажу сразу, про SYBASE. Вот здесь она http://www.sypron.nl/ttr/
                                              Там есть оглавление, глава 7.10 (мы эту книжку себе заказывали).
                                              Вряд ли MS в этом смысле чем-нибудь отличается. В любом случае, все это легко проверяется на тесте, типа того, что я привел выше.
                                              Последний раз редактировалось loo; 24.10.2003, 16:53.

                                              Комментарий


                                              • #24
                                                Loo

                                                Еще раз сначала...

                                                Так вот при ссылке по ID, тебе потребуется чтение +1 страницы , если индекс не кластерный.
                                                - Согласен - Потребуется чтение страниц индекса и плюс страницы данных.

                                                Но при чтении по кластерному индексу тебе потребуется перебрать больше страниц, чтобы спозиционироваться, т.к. сами стриницы данных содержат гораздо меньше записей, чем страницы индекса.
                                                Чтобы "спозиционироваться" по кластерному - я наоборот выигрываю от того что он кластерный, я перебираю меньше страниц, потому-что сам ключ содержит значения которые я ищу.
                                                Но выигрыш снижается - если я читаю еще и данные, и вплоть до 0 - если я читаю все данные.


                                                В итоге по i/o ты проигрываешь. И очень сильно теряешь производительность на операциях insert.
                                                - по ИО, я как минимум не проигрываю, и практически совсем не имею проблем при вставке - потому как в Диа, искуственный ПК.


                                                Вот что меня действительно бесит, так это поле DepHash (в tOperPart и остальных), и тупое Date_Time в tRate - ведь сколько раз советовали миру хранить диапазон дат действия. Вставка происходит один раз, пользуешься этим тысячу. Вот вчера достало это в конец, сделал таблицку-зеркало, обсчитываю для него Date_Time - DateEnd и пользуюсь between при поиске курса. Чего и вам желаю.
                                                С уважением, Максаев Андрей.

                                                Комментарий


                                                • #25
                                                  >loo
                                                  Так вот друг мой, нельзя сравнивать логику Sybase и логику MS SQL
                                                  Если рассматривать Ваш запрос применительно к Сиквелу то в данном запросе

                                                  select SwiftID, Tag, Number, TextLine
                                                  from tSwiftLine (INDEX XPKE_541)
                                                  where SwiftID = 647130
                                                  and Number = 2100
                                                  and Tag = '|BPARNM|'

                                                  у Вас будет происходить т.н. Table Scan
                                                  попробуйте выполнить этот же запрос с условием
                                                  where SwiftID = 647130

                                                  и с условием
                                                  where Tag = '|BPARNM|'

                                                  а потом сравните время выполнения.

                                                  Повторюсь, опять же, не пытайтесь применить Ваши знания Sybase к MS SQL

                                                  Комментарий


                                                  • #26
                                                    Белов Владимир
                                                    Во-первых, мой доселе неизвестный друг, логика ASE и MS SQL исходно одна и та же.
                                                    Во-вторых, в Вашем постинге, кроме общих слов - мысль не прослеживается. Какой может быть Table Scan, если в запросе заданы все поля уникального индекса, который я, к тому же, явно указал? Это MS SQL так работает? Не замечал.
                                                    И зачем, не пойму, мне пытаться выполнять запрос, заведомо в ни в какой индекс не попадающий? Как это поможет оценить преимущества кластерных индексов перед некластерными?
                                                    Последний раз редактировалось loo; 27.10.2003, 21:20.

                                                    Комментарий


                                                    • #27
                                                      loo
                                                      Логика ASE и MS SQL одна и та же ? Хм... интересный вывод
                                                      А мой запрос (вернее я фактически скопировал Ваш запрос) - как раз хоть немного но примитивно покажет логику работы сиквела при наличии составного кластерного индекса - так как он указан в Вашем примере. Это раз.
                                                      А второе, скажем так, главное отличие кластерного индекса от некластерного
                                                      в том что при
                                                      Наличии кластерного индекса у тебя будет происходить
                                                      чтение страницы индекса ---- чтение страницы данных
                                                      ---- чтение страницы данных
                                                      ---- чтение страницы данных
                                                      ---- и так до конца
                                                      причем данных уже сразу будут "возвращаться" в той сортировке, которая была задана при создании кластерного индекса

                                                      Наличии некластерного индекса будет
                                                      чтение страницы индекса - чтение страницы данных
                                                      чтение страницы индекса - чтение страницы данных
                                                      чтение страницы индекса - чтение страницы данных
                                                      и так далее
                                                      и после этого будет происходить сортировка

                                                      Вот вроде бы объяснил как смог.

                                                      Комментарий


                                                      • #28
                                                        Белов Владимир
                                                        Владимир!
                                                        Логика Sybase и MS SQL исходно одна и та же, потому что MS не делала SQL сервер с нуля, а лицензировала его у Sybase. Конечно, с тех пор туда внесено множество изменений, но базовые механизмы, как мне кажется, остались те же.

                                                        По существу. Есть, на мой взгляд, немаловажное уточнение к Вашей схеме. Почему Вы считаете, что для нахождения записи по индексу читается лишь одна страница индекса? Индексы, в первом приближении, представляют собой деревья и для позиционирования требуется чтение, как правило, нескольких страниц.
                                                        В моем примере для позиционирования по кластерному индексу потребовалось чтение 5 страниц, а по не кластерному - четырех+страницы данных, что закономерно. Или я чего-то не понимаю, или в своем письме Вы повторяете мое утверждение - кластерные индексы хороши, когда происходит сканирование записей по индексу. Искуственные PK, которыми являются Диасофтовские ID, для этой цели практически никогда не используются.
                                                        Кстати, даже в случае сканирования, выигрыш от кластерных индексов по Вашей схеме не столь значителен, т.к. каждая страница индекса содержит ссылки на много страниц данных и происходит что-то вроде: чтение страницы индекса - чтение страницы данных - чтение страницы данных - чтение страницы данных - чтение страницы данных и т.д. Выигрыш достигается за счет нахождения последовательных данных на одной странице, тогда "чтения" вообще не происходит.
                                                        Что же касается потерь при вставке, то они возникают от необходимости более частого "разбиения" страниц в случае кластерных индексов, это является довольно затратной операцией для сервера.
                                                        Последний раз редактировалось loo; 28.10.2003, 15:20.

                                                        Комментарий


                                                        • #29
                                                          Не забывайте, что во ВСЕ некластерные индексы включается кластерный индекс - для нахождения записи. Поэтому по рекомендации MS его надо делать как можно меньше - и в идеале монотонно возрастающий. int identity это полностью удовлетворяет.

                                                          По поводу

                                                          Отказ от FK - это гибкость при изменении версий.
                                                          это извините ни в какие ворота. А почему не mysql тогда взяли? Бесплатный заодно =) Кто ссылочную целостность обеспечивает?

                                                          Комментарий


                                                          • #30
                                                            Ссылочную целостность обеспечивает пользователь сам себе, то бишь Stored Proc от диа.

                                                            А скажи какой индекс выгоднее использовать и будет ли FK задействован в случае поиска по tOperPart, если необходимо найти все проводки филиала за дату 01.01.2002 в области "А"?

                                                            1) FK по InstitutionID
                                                            2) FK по BalanceID
                                                            2) или XIE8tOperPart (BalanceID, InstitutionID, OperDate, ResourceID, SecurityID)

                                                            Не забывайте, что во ВСЕ некластерные индексы включается кластерный индекс - для нахождения записи
                                                            - откуда эта нетривиальная мысль? из MySQL?
                                                            С уважением, Максаев Андрей.

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X