Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Тогда уж так: 28.03.08 13:10 Число просмотров: 2152
Автор: Den <Denis> Статус: The Elderman
Отредактировано 28.03.08 13:11 Количество правок: 1
|
> Нет, задача выбирать по произвольной битовой маске, типа
> select * from main where (isbitset(eventcode,bitmask)=true)
Тогда уж так:
SELECT * FROM main WHERE Bin_and(eventcode,bitmask) <> 0
Маскирование битов выполняется побитовым AND, а не OR.
> [UPD]: Катит, это я не прав, сорри... Разобрался с udf -
> библиотеками внешних функций, которые регистрируются путём
> выполнения запроса вида как выше. Если я правильно понял,
> это просто dll, которая просто экспортит функции, а
> FireBird подхватывает возвращаемые значения? Есть ли
> какие-нибудь особенности их написания, а лучше доки по
> написанию таких штук\механизму их работы?
Это обычные DLL'ки с обычными функциями, которые подхватываются не сложнее чем в MS VB. Немного об этом есть в приведенной ниже ссылке.
Иногда, при их написании необходимо соблюдать некоторые правила, особенно те, что касаются выделения памяти (имеется ввиду выделение (malloc) памяти через менеджер памяти IB).
> [UPD2]: Гуру БД послали меня куда подальше с моими битовыми
> масками, сказав, что любой селект с where по битовой маске
> приведёт к селекту всего чего можно с верификацией каждой
> записи, то есть работать это будет медленно.
Не факт! Они могут ошибаться.
Любое сравнение в БД использует вызов функций, зачастую находящихся в ядре сервера БД. При использовании определенных пользователем функций (UDF), DLL с этими функциями становиться т.н. in-proc сервером (используя терминологию COM), потому как выполняется в контексте загрузившего процесса и в одном с ним адресном пространстве.
> Механизм меняться не будет, так как плодить столбцы
> ну совсем никак не хочется, найдено
> Решение, специфичное для моей задачи:
> 1) Использование "историйной" таблицы - когда данные
> существуют больше определённого времени - переносим их в
> историю, обращения к которой в силу специфики происходит
> достаточно редко и не сильно критично по времени
> 2) Введение в интерфейсе принудительных ограничений на
> объём выбираемых данных типа замены select на select first
> 10000
Все же не совсем понимаю в чем суть, но уверен, что у твоей задачи есть масса элегантных решений.
http://www.ibphoenix.com/downloads/60DevGuide.zip
|
|
|
подробно о проекте
Анализ криптографических сетевых...
