LINUX.ORG.RU

Firebird 2.02


0

0

Вышел Firebird 2.02 (билд 12964) - компактная, кроссплатформенная, свободная система управления базами данных (СУБД), предоставляющая наиболее полную поддержку стандартов ANSI SQL (полностью поддерживает SQL 92 Entry Level 1 и реализует большую часть стандарта SQL-99), работающая на Linux, Windows и разнообразных Unix платформах.

ReleaseNotes:

http://www.firebirdsql.org/rlsnotes/F...

>>> Подробности



Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

>> Убогие индексы, нет кластерных. >И нах не нужны на версионнике

Анонимусу моск нах не нужен, если он такую херь пишет. Версионник отличается от блокировщика только если у нас есть больше одного подключения. Если у нас одна программа заливает данные, то версионник от блокировщика не отличается вообще. И, похоже, ты вообще не в курсе, что такое кластерный индекс.

<i> Принципиальным отличием кластерного индекса от индексов других типов является то, что при его определении в таблице физическое расположение данных перестраивается в соответствии со структурой индекса. Логическая структура таблицы в этом случае представляет собой скорее словарь, чем индекс. Данные в словаре физически упорядочены, например по алфавиту.

Кластерные индексы могут дать существенное увеличение производительности поиска данных даже по сравнению с обычными индексами. Увеличение производительности особенно заметно при работе с последовательными данными. Если в таблице определен некластерный индекс, то сервер должен сначала обратиться к индексу, а затем найти нужную строку в таблице. При использовании кластерных индексов следующая порция данных располагается сразу после найденных ранее данных. Благодаря этому отпадают лишние операции, связанные с обращением к индексу и новым поиском нужной строки в таблице.</i>

Если создан кластерный индекс с небольшим fill factor, то в для каждого значения хеша индекса выделяются резервные страницы, куда и происходит вставка.

И при чём тут версионник?

Ждём слива.

anonymous
()
Ответ на: комментарий от anonymous

> Версионник отличается от блокировщика только если у нас есть больше одного подключения. Если у нас одна программа заливает данные, то версионник от блокировщика не отличается вообще.

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

anonymous
()
Ответ на: комментарий от anonymous

мьсе прикидывается? Сервер на старте транзакции создаёт во временной памяти копии изменяемых объектов. При insert версионник ничего нового не создаёт и конфликты по сути невозможны.

При заливке кластерные индексы нужны потому что 1. при заливке данные идут подряд, поэтому записи будут заливаться в смежные блоки памяти 2. Есть такая штука как fill factor, который позволяет зарезервировать страницы под загружаемые данные вместо того, чтобы страницы по одной выделять, как это FB делает.

anonymous
()
Ответ на: комментарий от anonymous

>...Сервер на старте транзакции создаёт во временной памяти копии изменяемых объектов. При insert версионник ничего нового не создаёт и конфликты по сути невозможны.

Дас ист фантастиш! ЛОР - форевер!

>При заливке кластерные индексы нужны потому что 1. при заливке данные идут подряд, поэтому записи будут заливаться в смежные блоки памяти 2. Есть такая штука как fill factor, который позволяет зарезервировать страницы под загружаемые данные вместо того, чтобы страницы по одной выделять, как это FB делает.

Дас ист супер гут фантастиш!!! ЛОР (не побоюсь этого слова) - форевер!

Какой полет мысли!

anonymous
()
Ответ на: комментарий от anonymous

>Ждём слива.

Я к стати, занимался задачей вставки больших объемов данных, сторонней утилитой. Так OLAP строят иногда. Есть база, приспособленная для OLTP, из такой базы выборки быстро не сделаешь, по этому создается другая база, денормализованная, и туда по определенным правилам вставляешь. Так вот, для оптимизации вставки, кластеный индекс удалял, а после вставки массива, снова строил.

anonymous_pro
()
Ответ на: комментарий от anonymous

> Сервер на старте транзакции создаёт во временной памяти копии изменяемых объектов. При insert версионник ничего нового не создаёт и конфликты по сути невозможны.

1. Чушь. 2. Транзакция при старте опять же не имеет понятия, вставки в ней будут делать, апдейты или делеты. Ей, транзакции, это похрен.

> При заливке кластерные индексы нужны потому что 1. при заливке данные идут подряд, поэтому записи будут заливаться в смежные блоки памяти 2. Есть такая штука как fill factor, который позволяет зарезервировать страницы под загружаемые данные вместо того, чтобы страницы по одной выделять, как это FB делает.

Ни по первому, ни по второму пункту наличие индекса (не кластерного - вообще индекса как такового) не является необходимым. Херню-с порете-с, милейший.

anonymous
()
Ответ на: комментарий от anonymous

>> Один ReNoiSer за всех отдувается

>Да и тот по большей части остальных веселит

Ну вот, дождались: закрыли обсуждение.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.