» InterBase и FireBird: вопросы по работе и их решение

Цитата:

salexn1
1111 - это 1.111 или 1.1.11 или 111.1 и т.д.
или это всегда 1.1.1.1, т.е. не может быть числа состоящего из 2-х и более цифр?

по сути это структура меню, хранящаяся в таблице. самая большая ветка 1.1, содержит 15 пунктов, т.е. последний 1115

Цитата:

по сути это структура меню, хранящаяся в таблице. самая большая ветка 1.1, содержит 15 пунктов, т.е. последний 1115

Как вы предлагаете определять, что 1115 - это 1.1.15, а не 1.1.1.5?

exteris

Цитата:

Как вы предлагаете определять, что 1115 - это 1.1.15, а не 1.1.1.5?

да я уж понял, что надо как то переделать. должно получиться отсортированное дерево меню
Добавлено
Мне нужно как то добиться чтоб 1.1.2 находилось выше 1.1.11

vetal71
Так сохраняй с точками, что бы не было разночтений, и дополнительно добавляй 0 перед цифрами. Вряд ли в меню будет > 100 элементов, поэтому можно добавлять только 0 перед числами меньше 10.

Вместо 11 сохранять 01.01
Вместо 112 - 01.01.02, 1111 - 01.01.11, и т.д.

salexn1
спасибо. попробую

AlexPetrovich
Готовы некоторые теоретические итоги по теме индексов.


Цитата:

По моему пытаться делать оптимизацию изобретая нестандартные SQL - это путь в никуда.

Нет. Я пытаюсь изобрести стандартные сервера SQL. Пример - в экспериментах над крысами выяснилось что если приучить крысу нажимать рычажок чтобы крыса получала сыр, то потом если крыса хочет удовольствия она будет жать рычажок всегда, даже если не получает уже сыр и такая крыса может умереть с голоду. Мне не очень приятно чуствовать себя крысой и ничего не получать нажимая всякие кнопки. Путь крысы - путь в никуда.

Из предыдущих примеров видно что сервер выбрал себе модель поведения с индексами, но существует и другая модель. И так. Сервер считает справедливым использовать все индексы которые он обнаружит в условии:

>where a between 1 and 2
> b between 1 and 20000000000
> c between 1 and 20000000000
...
> z between 1 and 20000000000

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

В примере between 1 and 20000000000, но данных там точно between 10 and 20000000. И с какого тогда перепугу сервер делает вывод что индексы которые безумно полезны в других запросах так же полезны именно в этом запросе? А он делает этот вывод потому что в S Q L нет возможности указать серверу что его модель поведения является неуместной.

Есть другая модель, это абсолютно не касается и не ломает планы по использованию индексов. По этой модели поведения для последовательных чтений используется только 1 индекс и он указан в запросе. Остальные индексы используются для локейтов поиска. При последовательном чтении первого индекса все остальные условия вычисляются только исходя из математики выражения только для фильтрации. Это другая модель поведения сервера по отношению к индексам. Такая модель поведения является вполне справедливой для запросов в которых участвуют связи между двумя таблицами, которые являются огромными а количество данных возвращаемых запросом всегда будет маленьким из за того что ПО НЕПОНЯТНЫМ ПРИЧИНАМ ПРОГРАММИСТУ ИЗВЕСТНО ЕДИНСТВЕННОЕ ПОДУСЛОВИЕ ЗАПРОСА ФИЛЬРУЮЩЕЕ ДАННЫЕ МАКСИМАЛЬНО.
Мне думается ему известно это условие в 100% запросов которые он пишет, и во всех 100% его знания запроса являются бесполезными. Если он получает ещё и удовольствие, то он точно крыса...


Цитата:

По моему пытаться делать оптимизацию изобретая нестандартные SQL - это путь в никуда.

100% случаев стандартные SQL не даёт использовать мои знания тех данных с которыми он работает. Пользоваться таким SQL - путь в никуда. Вернее сервер вполне может мне помочь в 50% запросов, но только при использовании планов либо +0. То что существует +0 говорит о том что не мне одному приходится отключать конкретные индексы. Но эта возможность просто припарка, которая не позволяет реально выбрать другую модель отношения к индексам.

2) В случае когда я пишу слева на право сверху вниз запрос SQL мне удобнее определить первичный индекс до того как я начну писать джойны

OFFTOP
Не иначе танка прокачал!


Цитата:

2) В случае когда я пишу слева на право сверху вниз запрос SQL мне удобнее определить первичный индекс до того как я начну писать джойны

Тогда такая форма будет неполиткоррекна по отношению к пишущим справа налево и снизу вверх. А японцы те вааще пишут в столбик!

Подскажите как подружить FireBird 2,5 х64 с базой которая сделана была в версии 1,5. При попытке подключиться к ней, пишет что не верный формат сток.

ekemov
нужно сделать backup в версии 1.5 и restore уже в новой, 2.5 версии

ekemov
Если в базе данных были русские комментарии или названия объектов, тогда первый рестор нужно делать с опцией -fix_fss_metadata.

А вообще ODS от 1.5 к 2.5 настолько поменялась, что база может на 2.5 и не заработать с ходу.

ekemov
miwa
это да, возможно в 1.5 придётся перед бэкапом кое-что закоментить в триггерах и процедурах, чтоб нормально восстановилось, а потом уже в 2.5 допиливать с учетом нового синтаксиса

AnGo

Цитата:

Тогда такая форма будет неполиткоррекна по отношению к пишущим справа налево и снизу вверх.

Возможно и я выражаю мысль не политкоректно. Сервер совершенно точно знает что индекс для последовательного чтения и индекс для поиска (например уникальный индекс при джойне) это разные индексы. Если для поиска уникального значения не важен порядок филдов в индексе, главное чтобы они были перечислены первыми. То для оптимизации ORDERBY вычисляется индекс для последовательного чтения! Сервер это отлично знает.
Для своего примера я сделал смелое предположение что сервер FB найдёт оптимальный индекс для последовательного чтения. Не тут то было...
Вот индекс:

Код: CREATE INDEX TABLE1_IDX3 ON TABLE1 (PARENT_ID, GRADE_ID);

НЕ очень удобно будет. Просто иногда необходимо просмотреть данные в базе. А 1,5 на х64 системе не работает. А ради 1,5 версии ХР держать уже смысла нету.

delover

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

Ну и заодно - в теме о IB/FB давайте писать именно об IB/FB, а не о вашем виденье того, как надо развиваться системам управления базами данных?

Если я правильно понял ekemov, то он действительно прав, так как про оператор IN, я не стал сразу разжевывать. Предлагаю посчитать затраты на ресторацию стандартного порядка возвращаемых оператором IN записей. При моём последовательном чтении нам кажется что сервер вернёт отсортированные айдишники, а не тот порядок который указан в скобках - иногда это не удобно. По этой причине посчитаем затраты на ресторацию этого порядка от самого лёгкого случая до самого тяжелого.
1) Случай когда в запросе уже есть ORDERBY нам не следует вообще делать ресторацию. Тут всё ясно.
2) Случай когда последовательное чтение идёт именно по айдишникам, то есть по уникальному индексу. Это случай когда для ресторации требуется ещё один массив - буфер выборки равный по количеству элементов массиву который в скобках. Когда запись является отобранной она должна ложится на против своего значения. Это IndexOf для каждой записи - то есть наносекунды. Это более 90% случаев использования IN. Из этих 90% половина содержит ORDERBY.
3) Случай. Во первых он отличается тем что количество элементов IN более 2500. Это значит в скобках будет хранимая процедура, иначе вам не передать такое количество элементов в запрос. Мы будем передавать 60 тысяч элементов через селект из хранимой процедуры. Естественно, в нашем случае сервер обязан сделать фечьол хранимой процедуры чтобы выяснить мин-макс элементы, далее всё ничем не отличается. Но в нашем случае мы последовательно читаем по не уникальному индексу. Следовательно тот буфер выборки отличается по размеру от того что возвращает селект хранимой процедуры. Следовательно ресторация обязана использовать сортированную вставку. При сортированной вставке используется операция сравнения. Эта операция похожа на переделанный IndexOf. Он должен вернуть один из двух элементов который встретится первым, он и будет минимальным. Сама эта процедура занимает наносекунды, но весь процесс сортированной вставки может занять время равное 1/24. Человеческий глаз замечает 24 кадра в секунду, 1/24 это 42 миллисекунды на ресторацию.

Я хочу рассмотреть последний случай - без сортировки по неуникальному индексу для значений которые имеют тип строка. Мы выбираем 60 тысяч записей в 5и милионной таблице. Мои затраты на всё это хозяйство занимают примерно 100 миллисекунд. Это два кадра для человеческого глаза. Современные затраты сервера в среднем превысят 5 минут (не проверял, ИМХО за это не бейте, боюсь что может быть и дольше). Для людей чувствительных ко времени вполне видна разница, нечуствительные могут продолжать наслаждаться тормозами. Теперь:

Цитата:

Просто иногда необходимо просмотреть данные в базе.

Да это один из случаев когда я использую оператор IN.

Второй случай, например, моя таблица имеет 5 миллионов документов. В программе пользователь видит только документы за последний год, почти всегда. Чутьё мне подсказывает что айдишники этих документов генерятся последовательно - в основном. Моя задача только в том, что если пользователь нажал CTRL+A и выделил все документы, а потом исключил из выборки те которые не стоят на учёте. То моя задача показать общую сумму по всем документам. Для этого я делаю в запросе оператор IN. По моей схеме пользователь даже не заметит что сумму считает не моё приложение, а сам сервер. В нынешнем случае, если сервер будет делать эту операцию то пользователь будет психовать каждый день. И так мои 100 миллисикунд против сегодняшних 5 минут на каждый чих...

Было бы приятно, если бы сервер умел и это тоже делать.

miwa
Если вы о линках - то это как-то само получается
Попробуйте набрать ключевые( оптимальный сервер ) слова и вы сможете создать пост из одних "линок"

AnGo

Цитата:

Тогда такая форма будет неполиткоррекна по отношению к пишущим справа налево и снизу вверх. А японцы те вааще пишут в столбик!

На сколько я слышал от гакусеев (студенты по японски), они пишут сверху в низ, так что их мнение по этому вопросу скорее всего совпадёт с моим мнением.

Добавлено:
В продолжение Теперь о небывалом ускорении.
Последний случай который я описывал настолько экстравагантный, что я бы в принципе мог бы не делать ресторацию порядка элементов IN (с помощью сортированной вставки). Но такой SELECT может быть использован в конструкции INSERT from SELECT. И мне было бы понятно желание тех кто хотел бы управлять порядком вставки, вполне разумное желание занимающее очень мало времени.

Естественно, что выделение из множества условий, условия подходящего для последовательного чтения индекса является квантором. Для такого квантора подходят операции с промежутком (и операции равенства, как частный случай промежутка), то есть операторы = between и IN. Большего я пока не придумал, операции < > рискованно использовать в моей схеме, хотя это тоже некие промежутки. В любом случае для <> это +1 поиск по индексу и мы получаем % занимаемого промежутка. В этом случае можно выбирать схему, но тогда придётся делать поиск до составления плана индексов. Ну или полностью довериться пользователю в этом вопросе, как вариант.

delover
Имхо, у вас диалог самим с собой...

salexn1
Мне кажется, это... кхм... мыслеизлияние даже диалогом называть - слишком громко. То ли человек переучился и из него тепер прут слова без какого-либо смысла, то ли он так стебется, то ли бредогенератор тестирует

delover
насколько я знаю, IN всё равно преобразовывается в OR

miwa
ну отчего же поговорить с хорошим человеком - самим с собой
к тому же он сам себя хорошо понимает

salexn1
miwa
ant0ni02004
Двоешники. Я вам толдычу что такое индекс - я то думаю со своим топорным мозгом и бедным запасом алгоритмов вызову другую реакцию. Понимаю Вы не видели индексы под отладчиком по этому для Вас это страшный зверь. Уверяю он не страшный.

Пример данных с индексами без любых компонентов баз данных. Под отладчиком можно даже руками потрогать 2 разные операции по использованию индексов. Скорее автор этой библиотеки сам с собой разговаривал.


Код: [no]uses vdb;

//...

procedure TForm1.Button1Click(Sender: TObject);
var
v: TVariantArray;
idx: TIndexList;
colors: TStrings;
i: Integer;
begin
//Заполнение
v.Init('name=ftString,16'#13#10'color=ftInteger');
colors := vTableStorage.GetColorIdentsStrings;
for i := 0 to colors.Count - 1 do
begin
v.Append;
v['name'] := colors[i];
v['color'] := TColor(colors.Objects[i]);
end;
colors.Free;
v.Sort('color');

//Создание индекса
idx := TIndexList.Create(@v, 'name');
v.AddIndex(idx);
idx.Eval;

ShowMessage('Последовательность данных');
v.First;
for i := 1 to 5 do
begin
ShowMessageFmt('%d) %s', [i, v['name']]);
v.Next;
end;

//Первая операция - использование индекса при селекте
ShowMessage('Последовательное чтение индекса');
for i := 1 to 5 do
begin
v.RecNo := idx[i-1];
ShowMessageFmt('%d) %s', [i, v['name']]);
end;

//Вторая операция - поиск по индексу - lookup,locate,locateNext
ShowMessage('Поиск с использованием индекса');
ShowMessage(v.Lookup('name', 'Red', 'name'));

//Финализация
v.DoneIndexes;
v.Done;
end;[/no]

Программист, который посмотрит на индексы под отладчиком и поймёт что это 2 - две разные операции с использованием индексов, который потом перечитает что я писал по этому поводу. Тот программист не увидит ничего сверхестественного в том что было написано в топике. А так же поймёт что индексы используются сервером неэффективно только из-за неграмотности со стороны клиента. Клиент (со своими потребностями) достоен своего "правительства" тоесть - сервера.

delover

Цитата:

адрес библиотеки vdb.pas

для этой конкретной реализации(библиотеки), так наверное всё и есть, допустим...
осталось только понять, какое это имеет отношение конкретно к Firebird/Interbase и их индексам?

а что касается эффективности - есть такое дело, иногда приходится переписывать запросы, пока сервак не начнёт применять нужные сортировки/слияния и в правильном порядке. так и Firebird не Oracle, который умеет находить этот порядок почти всегда

ant0ni02004
Ну оракл тоже пока напильником-потом надфилем-потом нулевкой не пройдешься может выдавать не самый оптимальный вариант.
Но вот если все подтюнить - насобирать статистику и прочее - летает!

delover

Цитата:

Двоешники. Я вам толдычу что такое индекс - я то думаю со своим топорным мозгом и бедным запасом алгоритмов вызову другую реакцию.

Прочти для начала сам, что такое индекс в базах данных вообще, потом хоть что-то по теме ФБ, прежде чем вываливать на форум кучу несвязного бреда, отличник ты наш.


Цитата:

Пример данных с индексами без любых компонентов баз данных.

Какое отношение вообще имеют никому не известные библиотеки к организации индексов в файрберде?

Не в обиду delover будет спрошено, я один такой тупой, что практически не понимаю его размышления или есть ещё на форуме такие тугодумы?
Просто у меня после пары первых предложений его очередного поста соображалка отключается.

AnGo
+1

Поначалу у меня складывалось впечатление, что это гугл перевод... может так оно и есть... но читать этот поток сознания просто не реально...

AnGo
salexn1
у меня тоже, но оказалось, что речь шла об неких индексах, совершенно к ФБ не относящихся и вообще о другой БД