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

LeaF_AVF && OXDBA
Спасибо за ответы но вот если оставить пароль для sysdba по умолчанию. То более менее опытный пользователь может просмотреть базу через тот же Ibexpert. А я хотел бы избежать данную ситуацию. но при этом что бы не поломать работу программ других разработчиков.
P.S. еще один нюанс embed server мен не нравиться

sergiuz1303
любой, кто сможет получить доступ к твоей БД или ее бекапу (т.е. просто скопировать сам файл базы данных) сможет просмотреть всю структуру базы, подняв эту базу у себя на сервере.
Поэтому с точки зрения безопасности - главное обеспечить отсутствие доступа (любого, в том числе и физического) к твоему серверу

LeaF_AVF
Это что прятать подальше и с измененым расширением файл БД?
Какие есть варианты обеспечения безопасности БД?

sergiuz1303
1. исключить доступ к серверу (физически тоже)
2. не расшаривать диски, где находится БД
3. использовать алиасы...

это навскидку, может кто-то продолжит список

4. Логгировать подключения к базе.
5. Сменить пароль для SYSDBA.
6. Правильно раздавать роли и права.

У кого-нибудь есть пример или документация по написанию blob-фильтра, работающего на сервере?

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

Tantos

Цитата:

5. Сменить пароль для SYSDBA.

Если читал рание посты то должно быть понятно что изменения пароля на пользователя Sysdba не рентабельно из-за программ других разработчиков

LeaF_AVF

Цитата:

обработку блоб-полей на сервере?

Да, я имел ввиду

Код:
DECLARE FILTER filtername
INPUT_TYPE <blobtype> OUTPUT_TYPE <blobtype>
ENTRY_POINT 'function_name' MODULE_NAME 'library_name'

idiMAN
Немного есть в книге Борри, а дальше смотри документацию от IB6.

idiMAN
Угу, именно это и имел в виду..
Если не сложно, поясни, для какой цели планируешь использовать фильтры на сервере (кстати по синтаксису объявления рискну предположить, что они являются какой-то разновидностью UDF, я не ошибаюсь?)

LeaF_AVF
Я планировал сделать на клиенте клиентские blob-фильтры для сжатия данных. Но, т.к. разрабатывать, администрить и отлаживать базу я планирую с помощью IBExpert, то хотел реализовать также blob-фильтры и на серверной стороне, для полукения нормальных (не сжатых) данных в IBExpert.

OXDBA

Цитата:

Немного есть в книге Борри

Да там совсем немного - меньше страницы. И то, констатация факта, что такие фильтры существуют.

idiMAN
Если используется FIBPlus:

Работа с BLOB-полями

Что такое BLOB? Как корректно работать с BLOB полями и BLOB фильтрами в Firebird/InterBase? В чем преимущество механизма клиентских BLOB фильтров в FIBPlus?

Tantos
Спасибо, но я это уже читал.

OXDBA много это 70 гигов, про ограничения не знаю.
LeaF_AVF не было проблемы с шатдауном.
Ну SYSDBA у нас использует только администратор и, естественно, только в административных целях
sergiuz1303 пользователи через эксперт заходить, ХХОХО, а зачем им это? они наверно даже не знают что это, может просто не оставлять эту программу на компах у юзеров?
Хотя у нашихклиентов она стоит и что-то ни разу за 3года не было случая, чтобы ктото туда залез

AngeL
ты для начала определись все-таки, как там у вас организовано, так:

Цитата:

у нас пром. преприятие, но юзверь SYSDBA и ничего страшного! Зачем вобще юзверя менять то? у нас правда версия еще 1.5, но база огромная и все вроде неплохо, работаем!

или так:

Цитата:

Ну SYSDBA у нас использует только администратор

а то, что

Цитата:

не было проблемы с шатдауном

,
это не значит, что такая проблема не возникнет в будующем.

Ну и напоследок - недооценивать клиентов/сторудников/юзеров все же не следует, в противном случае можешь как-то очень сильно пожалеть

AngeL

Цитата:

про ограничения не знаю

Незнание закона...(C)
У полуторки максимальный размер данных в одной таблице - 36,7 гигабайт.

LeaF_AVF

Цитата:

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

Если можешь, поделись пожалуйста библиотекой для сжатия/распаковки. Попробовал скомпилировать пример "Blob_Filters" из optimization_examples.zip но вылазиет куча ошибок. Исправление одних приводит к появлению других...

idiMAN
по правде говоря на основе выложенных тобой "Blob_Filters", я и делал свою упаковку/распаковку
Так что показывай ошибки, - будем решать (лучше наверное в ПМ, здесь чтоб не флудить)

Ребята, подскажите, как правильно сделать. Есть таблица:
1-е поле: ID слова - первичный ключ в таблице
2-е поле: само слово
3-е поле: счетчик употреблений этого слова.
Нужно проиндексировать все слова в 6-ти документах (книгах). То есть из документа берется слово, если оно отсутствует в БД, то добавляется, если есть - в соседнем поле инкрементируется счетчик количества его употреблений. Всего в документе полмиллиона слов (словарь документов - 50 тыс разных слов, т.е. в таблице будет столько записей). В конце нужен отсортированный по алфавиту (2-му полю) список слов. Процесс заполнения БД занял 3 часа 20 минут. Как можно ускорить процесс, если это возможно вообще? Я так понимаю, что если делать индекс по 2-му полю, то поиск слова ускорится, но при добавлении слов индекс в таблице будет перестраиваться, что займет время. И возможно, что будет так, что результирующее время обработки не изменится? Как в этих случаях надо поступать?

DmitryKz
мне кажется, что "бутылочным горлышком" в данной ситуации является не быстродействие сервера БД, а процедура добавления записи (открыть документ, прочесть слово, сделать выборку на наличие такого, добавить или изменить значение поля, подтвердить транзакцию).
При таком подходе (без индекса по ключевому полю), время выборки будет становиться все больше и больше с каждым запросом из-за натурального перебора. Поэтому индекс я бы добавил.

И второй вариант - может заинтересует, вроде бы интересный:
1. Создаем таблицу table1 (id, name)
2. Добавляем в нее _все_ слова (только не по одной записи за транзакцию, а пакетно - по пару сотен или тысяч)
3. Создаем индекс на поле name
4. Создаем таблицу table2 (id, name, name_qty)
5. Пишем хранимую процедурку, которая:
- проходит по всей таблице table1 (вот тут индекс и поработает в полную);
- по каждому полю делает выборку вида

Код: SELECT COUNT(name)
FROM table1 t1
WHERE t1.name = :name
into :name_qty;
INSERT INTO table2 (name, name_qty)
VALUES (:name, :name_qty);
DELETE FROM table1
WHERE t1.name = :name;

LeaF_AVF само собой разумеется, что SYSDBA только для админов, остальным юзьверям права через программу, которая у нас и управляет тем, что можно сказать доступ к информации.
OXDBA

Цитата:

У полуторки максимальный размер данных в одной таблице - 36,7 гигабайт.

так я не про таблицу, а про базу говорила и вобще что вы имели ввиду про незнание закона?
LeaF_AVF

Цитата:

Ну и напоследок - недооценивать клиентов/сторудников/юзеров все же не следует, в противном случае можешь как-то очень сильно пожалеть

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

LeaF_AVF
Прости, забыл упомянуть, что индекс по ключевому (1-му - ID слова) добавлен. У меня еще была мысль сделать ключевым с индексом 2-е поле (само слово), но не знаю, правильно ли это.

DmitryKz
под ключевым полем (может быть не вполне корректная формулировка) в конкретном случае я подразумевал именно 2-е поле
AngeL
поступайте как считаете нужным, убеждать вас в чем-то я не стану

AngeL
Я имел ввиду настоятельную рекомендацию посмотреть размер самой большой таблицы БД, оценить темпы увеличения и получить дату падения Вашей БД по причине достижения магической цифры 36,7 и если она близка, принимать меры.

Добавлено:
DmitryKz
Индекс нужен, про заполнение лучше всего написано здесь
Тесты вариантов реализации проверки существования записи при ее обновлении
P.S. На прошлогодней конференции Сергей Мереуца предложил во второе поле писать не само слово, а результат хэш-функции CRC32 от этого слова.

OXDBA
Сорри, если туплю - а само слово тогда как узнать?

DmitryKz
Неет, это я три дела сразу делаю
Вместо первого поля CRC32 и индекс по нему

Добавлено:
О, нашел ...реализация морфологического поиска в Firebird.

Вот еще такую проблему обнаружил: в БД (кодировка 1251), есть две таблицы для греческих и еврейских слов (кодировки таблиц 1253 и 1255 соответственно соответственно). В программе используются Фибы. Из Юникодного текста эти слова конвертирую в Анси, английские и русские слова конвертятся и заносятся в свои таблицы успешно, а с греческими проблема - при занесении их в БД компонент выдает исключение из БД - переполнение или деление на ноль. Честно говоря, я не знаю как определить, в чем проблема (потому что вроде конвертятся они успешно), поэтому и решил сначала спросить здесь. Никто не сталкивался с подобным?

DmitryKz
При соединении какую кодировку указываешь?

OXDBA
Упс! Надо было указать NONE? Я сейчас сделал так, исключений не было. Правда занеслось всего два слова (их около 15 в тексте) и отображаются русскими буквами (Смотрел в IBExpert, думаю, он позволяет смотреть тексты в разных кодовых страницах?). Значит, получается, конвертация была неуспешной?
Понимаю, что вопрос из букваря, но что дает NONE при коннекте?