Объясните мне тёмному, нафиг нужно криптование, если я могу подключиться IBExpert'ом и читать через UDF эти данные в открытом виде?
Наверное, защита на случай, если хекс-редактором прямо в файл базы будут смотреть? Гы.
Что-то мне подсказывает, что криптование - сугубо клиентское дело, и открытые данные гоняться не должны.
Расухание базы данных
Модератор: kdv
Разница есть. Темп и база могут находиться на разных носителях.И какая разница что будет пухнуть - база или темп ?
Базу можно разместить на временном устройстве (например на флэшке), а темп на жестком диске, где места много и пухнуть есть куда.
Если я в ОДНОЙ транзакции детаю 20 выборок по 200 записей или 4000 по одной записи, то это одно и тоже -- распухнет на 4000.Если каждое чтение в отдельной тр-ции затрагивает 200 блобов (а не так, как в примере), то она один раз 'распухнет' на 200 блобов и всё.
Чтобы сильно не пухло придется делать так: 200 выбрал -- COMMIT.
Верь. Ровно столько нужно для подготовки распечатки.И я не верю, что все эти 200 блобов тебе нужны на клиенте одновременно.
Для того чтобы раскриптовать нужно ещё ключ знать. Ключ в базе не хранится. В IBExpert введи сначала ключ, а потом увидишь результат. А без ключа ничего не увидишь.Объясните мне тёмному, нафиг нужно криптование, если я могу подключиться IBExpert'ом и читать через UDF эти данные в открытом виде?
Моя цель обеспечить безопасность хранения.Что-то мне подсказывает, что криптование - сугубо клиентское дело, и открытые данные гоняться не должны.
Безопасность передачи данных по сети должна обеспечиваться средствами сетевой безопасности. И вообще мы ушли сильно далеко от темы.
С этим я и спорить не буду, всё можно взломать. Ну перенесу я все это шифрование в клиент, так эта проблема вылезет с блоб полями на чем-то другом. Использование UDF скорее всего не единственный способ создания большого числа временных блоб.любые закрытые методы шифрования обычно взламываются самым неожиданным и примитивным способом.
Спрашивая о том, что ты делаешь, мы не пытаемся выведать "военные секреты". Не хочешь - не надо.
Мне жаль, что нельзя организовать работу с выборкой таким образом, чтобы мусор удалялся сразу после передачи данных на клиета. Поясню, что имею в виду: создаём гипотетическую модификацию оператора SELECT, которая работает следующим образом:
1. выбрали запись на клиент,
2. Забрали блоб,
3. Выбрали следующую запись,
4. Если в промежутке между 1 и 3 мы не назначили выбранный блоб никакой таблице, то он освобождается, а занятое им место и его идентификатор, сразу, до окончания транзакции, используется для следующего блоб.
Таким образом, если мы не назначили ни одного блоб поля таблицам, то можно существенно сэкономить место.
Я не знаю внутренний механизм формирования и передачи выборки в Firebird, но я думаю мне все-таки скажут почему такой подход невозможен?
Что касается того, почему я так ревностно отношусь к экономии места, то причина очень простая: база данных должна находиться на флэшке (а у них объем невелик). Понимаю, что сказанным выше навлеку на себя праведный гнев. Сам понимаю, что это бред и чем это всё мне грозит. Но это требование заказчика...
RTFM isc_cancel_blobivl писал(а):Поясню, что имею в виду: создаём гипотетическую модификацию оператора SELECT, которая работает следующим образом:
1. выбрали запись на клиент,
2. Забрали блоб,
3. Выбрали следующую запись,
4. Если в промежутке между 1 и 3 мы не назначили выбранный блоб никакой таблице, то он освобождается, а занятое им место и его идентификатор, сразу, до окончания транзакции, используется для следующего блоб
Но это не совсем то. Это же функция API. Но как мне при использованииRTFM isc_cancel_blob
IBX в Delphi её туда прикрутить? Или мне всё на API переделать?
Прикрутить можно, конечно, но это будет как-то не очень...
Я же говорил о другом: о реализации похожего механизма только средствами SQL. Или я что-то упустил из виду?
Всё делается через АПИ. Тебе шашечки или ехать ?ivl писал(а):Но это не совсем то. Это же функция API. Но как мне при использованииRTFM isc_cancel_blob
IBX в Delphi её туда прикрутить? Или мне всё на API переделать?
Я же говорил о другом: о реализации похожего механизма только средствами SQL. Или я что-то упустил из виду?
Делаешь наследника TIBBlobStream, перекрываешь у него CloseBlob и используешь его для работы с блобами.
В продолжение темы хочу спросить, будут ли созданы новые блоб при выполнении такой конструкции:
Или же это приведет к возврату идентификаторов уже реально существующих? То есть будет ли использован Firebird один и тот же объем памяти при выполнении операторов
И
Код: Выделить всё
CREATE PROCEDURE TEST_PROC RETURNS (
BL1 BLOB,
BL2 BLOB)
AS
BEGIN
FOR SELECT BLOB_FIELD1, BLOB_FIELD2 FROM TEST_TABLE
INTO :BL1, :BL2 DO SUSPEND;
END
Код: Выделить всё
SELECT * FROM TEST_PROC;
Код: Выделить всё
SELECT * FROM TEST_TABLE;