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

delover
в firebird.conf есть несколько настроек, влияющих на размер памяти используемой сервером. Можно даже базу хранить не на диске, а в RAM

Тогда порабы дефолты конфига тож поправить...

pps
И опять же речь не идёт о снятии ограничений, а о лишь пересмотре их размеров. Не надо ломать математику, а только проследить как оптимально повысить допустимые размеры. Речь не идёт о телефонах которые не потдерживают IB компоненты и у которых памяти меньше 256мб. Такие телефоны ещё можно купить, но до IB они вряд ли доживут. Речь о средних серверах которых много и реальный промышленный эффект в основном от них 2Gb-4Gb, клиенты 1Gb-4Gb. Большое количество таких клиентов, где 1 или более Гигобайт оперативки, и имеется основная для их фирмы программа, которая не в состоянии справляться со 180мб. Это не критика, а сожаление по поводу очень достойного матаппарата и констатация того, что популярность этого аппарата по очевидным (хотя и глупым) причинам будет сильно уменьшатся. Желательно бы без этого (извините меня ламера даже не знаю какие настройки в конфиге влияют на выпадание OutOfMemory).

Добавлено:
по поводу айдишников - есть простая хранимка (хранимая процедура SplitIDs) которая парсит строку айдишников переданную параметром 64кб и возвращает таблицу для джойна, но такая штука тоже далкео не у всех есть.

delover
Я считаю, что классические OLTP СУБД не предназначены для таких задач (вытягивание клиентом такого большого количества данных в одной транзакции). У меня, например, ни разу ещё не возникала проблема с нехваткой памяти, хотя базы у заказчиков доходят до 20гиг при 50и клиентах. Все большие обработки данных обычно проходят на стороне сервера (кстати в сторону UDF не копали? может они помогут)

druff
Копал. К примеру вы имеете на одну модель изделия справочник толщиной с энциклопедию. Таких моделей на изделие несколько десятков, таких изделий у фирмы несколько десятков, таких фирм несколько десятков. Естественно это несколько баз с одинаковой структурой. И вы заполнив эти базы - тоесть потратив огромное количество человекочасов собираетесь их продать потребителью. 1 потребитель купил и раздал эти справочники бесплатно, Вас это наверно чемто не устроит? Подумаете зашифровать базу и защитить прогу чемто типо СтарФорс? Хорошее решение, правдо защита на каждую версию программы оплачивается Вами крупненькой суммой. И тут находится гениальный программист который предлагает расшифровывать данные в UDFках и использовать фильтрацию селекта по like на расшифрованный текст. Это веть быстрее? Круто! Тут же потребитель номер 2 легонько вскрывает UDF и все справочники и так же раздаёт их бесплатно. Себестоимость СтарФорс и заполнения вдруг оказалась намного больше выручки. А подобное случалось?

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

delover
UDF точно так же будут работать под nix, если писать их на Lazarus.

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

Цитата:

Меня больше заботит защита собственных алгоритмов, и, по возможности, структуры самой базы.

Можно стереть исходный код процедур и триггеров.

Update RDB$TRIGGERS set RDB$TRIGGER_SOURCE = '';
Update RDB$PROCEDURES set RDB$PROCEDURE_SOURCE = '';

А структуру таблиц по-любому увидят

TuMOXA123
Текст ХП можно не только стереть, но и изменить

А структуру сделать нечитаемой. Т.е. названий всех объектов.. Перед сборкой релиза для клиентов - провести обфускацию названий, выбранных разработчиком таблиц, полей, ХП и т.д. Попробуй потом разберись в таких данных

druff

Цитата:

Т.к. в моём случае все данные в базе принадлежат заказчику и не в моём праве закрывать к ним доступ.

Это не совсем верно если рассматривать для примера D2010. Данные заказчика в целости - они не зашифрованы. Однако без Вашего вмешательства их получить бывает достаточно трудно. На гриде они видны а вот чтобы их сохранить надо например иметь ввиду, что компоненты сами умеют создавать филды, как это делается:


Код: DefaultFieldClasses: array[no][TFieldType][/no] of TFieldClass = (
DB.pas
TMemoField, { ftMemo }
IBCustomDataSet.pas
TWideMemoField, { ftMemo }
function ADOTypeToFieldType(const ADOType: DataTypeEnum;
ADODB.pas
adLongVarChar: Result := ftMemo;
adLongVarWChar: Result := ftWideMemo;

Удалено

Кто может рассказать что-то познавательного о технологии MDT от DevRace?

MDT - это технология Firebird 2+, а не Devrace.
По вашей же ссылке 2 статьи по MDT. В чем вопрос-то?

Цитата:

MDT - это технология Firebird 2+, а не Devrace.

В каком смысле? Насколько я помню, это технология при которой часть базы кэшируется на клиенте.

Tantos

Вопрос был, собственно, к практикам. Есть ли смысл копать в сторону MDT? Какие подводные камни? Есть ли реальный прирост производительности? Насколько разгрузился основной сервер БД?

Или кто видел ссылки на статьи по данному поводу? Кроме деврэйсовских.

Добавлено:

Цитата:

В каком смысле? Насколько я помню, это технология при которой часть базы кэшируется на клиенте.

Не просто кэшируется на клиенте, а кэшируется на ОДНОМ ИЗ КЛИЕНТОВ.

pzaytsev

Цитата:

а кэшируется на ОДНОМ ИЗ КЛИЕНТОВ.

т.е.? какой смысл на одном клиенте кэшировать базу, а на другом - нет?

druff

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

более подробное обсуждение нашел здесь

Цитата:

С учетом всего сказанного, применение mdt возможно имеет смысл, только если вы:
1. используете fib
2. готовы переписать полностью свое приложение
3. все локальные машины имеют достаточно свободного места и пользователь за этим следит
4. у вас нет огромных таблиц
5. вы готовы лично разбираться с багами

pzaytsev
да, не очень оптимистично но это применимо ко всем новым/мало известным технологиям. Мне MDT видится альтернативой многозвенным приложениям. Особенно в части экономии трафика.

А насколько оптимистично это:

Код:
function TIBCustomDataSet.Lookup(const KeyFields: string; const KeyValues: Variant;
const ResultFields: string): Variant;
var
fl: TList;
CurBookmark: TBytes;
begin
DisableControls;
fl := TList.Create;
CurBookmark := Bookmark;
try
... //without local variable fl
finally
Bookmark := CurBookmark;
fl.Free;
EnableControls;
end;
end;

delover

жёстко это из какой версии?

druff
Примеры к приложению "О безопасности".

Код: procedure ...DrawGrid1DrawCell(Se...
var
P: ^TGridDrawState;
begin
P := @P; Inc(Longint(P), $A3);
if P^ = State then
P^ := State-[gdSelected,gdFocused];

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


Цитата:

А если загнать эти айдишники во временную таблицу (GTT) и выполнять джойн с ней ?

Вынесение в клиентский датасет решает одну важную задачу. Даёт возможность постепенной работы как в случае с автоматизацией распознавания образов.

Знатоки, подскажите, возможно ли совместное использование FireBird-embed и FireBird server (если сервер не запущен использовать embed)?

EugeneBoss3

Цитата:

Знатоки, подскажите, возможно ли совместное использование FireBird-embed и FireBird server (если сервер не запущен использовать embed)?

Да за ради бога. Заменяешь только fbclient.dll и в путь.

YuriyRR

Цитата:

Заменяешь только fbclient.dll и в путь.

Заменять fbclient.dll чем? Если можно подробнее.

fblient-ом от embedded версии.

EugeneBoss3
или на соответствующий gds32.dll если пользуешься именно им.

Цитата:

В продолжении темы о наведении уникальности в базе.

Я бы использовал нечёткое сравнение строк с дальнейшим ручным принятием решений.

EugeneBoss3

Цитата:

Заменять fbclient.dll чем? Если можно подробнее

В поставке embedded весь сервер находится в fbembed.dll
Переименовываешь ее в fbclient.dll и соединение будет через emb.
Через нее вроде можно будет коннектится и к удаленному серверу.

Цитата:

Через нее вроде можно будет коннектится и к удаленному серверу.

Если в строке пути к базе есть имя машины или адрес, то она работает также как обычный fbclient.dll

rrromano
Да я пока так и делаю, долго грузится табличка, а потом узнаю что неправильно сделал. Поле базы ограничил, после этого парсил запятые, которые обрезались, данные уехали в другую колонку, которая с плавающей точкой, а там наименование. Незнаю как ускорить. )))