SergSuper ASCRUS авторможет в ASA внутри MUMPS сидит :)

уж очень схема связей идентична
doubly-linked list

интересно про ASA почитать
Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;)
Да они хоть бы что-то читали... В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше.
Это понятно, когда ничего кроме кеша не знаешь, то кажется что все что есть в мире - взято из кеша.


iliker c127Убить при можно любую систему, дело только в наличии желания. Из хелпа по АСА9
CLUSTERED keyword
The CLUSTERED attribute causes table rows to be stored in an approximate key order corresponding to the index . While the server makes an attempt to preserve key order, total clustering is not guaranteed.
If a clustered index exists, the LOAD TABLE statement inserts rows into the table in the order of the index key, and the INSERT statement attempts to put new rows on the same table page as the one containing adjacent rows, as defined by the key order.

Это ж оно пыталось перестроить таблицу (не индекс, а именно таблицу) каждый раз при добавлении новой записи со случайным значением в индекированном поле. Ну может не каждой, но периодически перестраивало.
Обратите внимание While the server makes an attempt to preserve key order, total clustering is not guaranteed.
Не перестраивает asa каждый раз таблицу.Перестройка делается ручками при помощи reorganize table.
А MSSQL, похоже, перестраивает каждый раз.(маловато информации в MSDN)
MSDN 1
MSDN 2

А где я сказал, что ПЕРЕСТРАИВАЕТ каждый раз?

А какое отношение МСДН имет к АСА?


Iura c127
Это ж оно пыталось перестроить таблицу (не индекс, а именно таблицу) каждый раз при добавлении новой записи со случайным значением в индекированном поле. Ну может не каждой, но периодически перестраивало.

Вот вот! Но и индекс тоже, чтобы хранить ссылку на страницу
Уважаемый товарищ, перестроить индекс это совсем не то же самое что перестроить таблицу.

Кластерный индекс в данной ситуации совершенно не подходит, организовав кластерный индекс Вы сделали откровенную глупость. В этом нет ничего страшного, Вы же не администратор СКЛ серверов, но вот только нужно не выкручиваться, а признать это.

Iura
На самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится.
Бред какой-то. Физически СКЛ сервер записи не удаляет, это неэффективно, только помечает как удаленные, поэтому размер базы при делитах не меняется. Я удивлюсь, если в КЕШ-е не аналогично.

Если был делит, потом инсерт, то запись может попасть на место удаленной, размер базы не изменится. Поэтому файл не обязательно разрастается.

Лог растет, но на то он и лог, туда пишется большинство операций и ничего само по себе не удаляется по определению. Правда не все операции пишутся в лог, truncate table, например, в АСА не пишется. Если Вы так озабочены размером лога, то его можно отключить, но делать это по понятным причинам не рекомендуется.

Iura
А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить.
Чушь.
Во-первых скорость работы сервера от размера файлов БД не зависит, поскольку, как Вы правильно сказали, информация на современных дисках хранится не последовательно. Поэтому ужимать файлы БД не обязательно, если есть место на диске. В утилитах АСА шринка по-моему вообще нет, по крайней мере у меня ни разу в жизни не возникала необходимость его использовать, при обычной работе пустых мест в файле БД не так много.

Во-вторых база с необходимостью растет только при инсертах и отсутствии пустых мест в таблицах. Чудес же не бывает, нужно где-то хранить информацию. Или может КЕШ способен все на свете засунуть в пространство фиксированного размера, например в один байт?