Перечень статей   Choose language


Почему BLOB-поле - недополе, и как его сделать полем


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

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

Скачивание

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

И нам нужны операторы:

Получение

Мы не можем продолжить получение после разрыва TCP-соединения, после перезагрузки или выключения питания - мы можем только надеяться, что соединение не будет разорвано, компьютер не повиснет, и что источник бесперебойного питания дотянет до конца передачи. Но если кто-нибудь попросит СУБД выдать этот BLOB в процессе получения, что СУБД должна ответить ему? Отвечая NULL, она сообщит, что ничего не знает о BLOB-е, что является ложью, т.к. получение BLOB-а - это только вопрос времени. Таким образом мы видим, что поле должно хранить:

Пусть третья база данных копирует BLOB-поле в себя в тот момент, когда наша база данных его еще получает. Может ли третья база данных содержать значение "ACCEPTING"? Очевидно нет, т.к. это выглядело бы так, как будто третья база данных сама получает BLOB. Таким образом третья база данных дезинформировала бы своих пользователей, и внушила бы им ложные надежды. Итак, нам нужно еще одно значение, подобное NULL, например в которое превращается "ACCEPTING" в процессе копирования. NOTGOT превращается в NOTGOT при копировании.

Оба случая

Следует заметить, что BLOB - это часто картинка, которая должна быть продемонстрирована в клиенте (например, в браузере). И было бы очень неудобно, если бы адрес содержал имя BLOB-поля (чтобы отличить его от других BLOB-полей), имя поля первичного ключа (чтобы указать запись), и имя таблицы [1]. И как записать такой адрес? Это будет совершенно не похоже на URL, кроме того, клиент совершенно не обязан знать SQL. Таким образом мы видим, что

должен быть помещен в BLOB-поле сразу, как только BLOB будет скачал или получен полностью. Помещение должно выполняться СУБД автоматически, без участия программиста [2].

Вообще же BLOB - это файл, и как всякий файл он имеет тип - jpg, mpg, и т.д. Файлы одних форматов содержат указание типа в самом начале файла, файлы других форматов - не содержат, и в этом случае тип должен хранится в BLOB-поле и копироваться из поля в поле при копировании BLOB-а [3].

Резюме

Давайте подытожим: BLOB-поле должно быть способно содержать один из следующих наборов значений:

or or or or Операторы, умомянутые выше, будут выглядеть так:

[1] Предполагаем, что имя схемы объединено вместе с именем таблицы в один токин

[2] Было бы очень глупо, если бы программист был должен создавать последовательность для BLOB-ов, и создавать по триггеру для каждого BLOB-поля в базе данных

[3] Хорошо, если бы СУБД понимала большое количество форматов и исправляла бы тип файла в BLOB-поле на значение из содержимого файла

[4] Вида "site.com/~dbowner/dbname/identifier" или "111.222.333.444/~dbowner/dbname/identifier"

[5] Знать тип BLOB-а нужно только чтобы отобрать BLOB-ы для конвертирования из одного формата в другой. Тип BLOB-а должен извлекаться автоматически вместе с самим BLOB-ом при его пересылке, таким образом излишне запрашивать тип BLOB-а отдельно. Кроме того, BLOB-ы должны передаваться не в самой записи (record), а после всех записей. Иначе они будут блокировать реакцию получателя на быстро передаваемые не-BLOB поля.

<tablename fieldname1= fieldname="3652435"/>
<?file                 value="3652435" type="mpg" size="3">Y29</?file>

P.S.

Статья является руководством по реализации идей с.167-175 pdf-документа. Кроме того, для принудительного построения пиринговых сетей (peer-to-peer network) типа BitTorrent, Kademlia и пр. могут быть добавлены команды выяснения количества скачиваемых частей и их начал и концов

select reckon(    @field   ) from ... ;  -- returns quantity of blob parts
select beginning( @field, 5) from ... ;  -- beginnings of 5th part
select end(       @field, 5) from ... ;  -- ends of 5th part

Тюрин Дмитрий, dmitryturin@yandex.ru



Перечень статей   Choose language


Используются технологии uCoz