#mysql #database #blob
#mysql #База данных #Большой двоичный объект
Вопрос:
Я подумываю о том, чтобы собрать небольшой журнал, который я хочу показать онлайн, и подумал, что хорошим способом сделать это было бы иметь таблицу, состоящую из идентификационного номера, плюс данные большого двоичного объекта, чтобы показать каждую страницу в виде изображения.
Итак, если бы у меня была проблема, состоящая из 10 страниц, это выглядело бы так:
ID . Page_1_Blob . Page_2_Blob . Page_3_Blob . Page_4_Blob . Page_5_Blob . etc
Дело в том, что я видел много негатива, когда дело доходит до хранения данных blob для изображений, в частности, из-за того, что это замедляет работу вашей базы данных? Насколько это верно? И есть ли какие-либо аргументы в пользу использования blob-данных таким образом?
Комментарии:
1. Есть ли веская причина показывать только изображение каждой страницы журнала вместо ссылки на соответствующий HTML-документ? Вы уничтожаете предыдущую проблему каждый раз, когда пишете новую?
2. Возможно, «Журнал» — неправильное слово. Это больше похоже на брошюру, где люди могут просматривать ее онлайн в виде постраничного буклета, а затем загружать фактический файл в формате PDF.
Ответ №1:
Итак, я понимаю, что большой двоичный объект сохраняется в реальном файле базы данных. Итак, если бы у вас был журнал объемом 10 ГБ, то 10 ГБ оказались бы в реальном файле базы данных SQL. Файл загружается в оперативную память при выполнении запроса. Очевидно, что поиск в файле размером 10 МБ выполняется намного быстрее, чем загрузка и поиск в файле объемом 10 ГБ. Ответ на этот вопрос заключается в использовании SqlFileStream для хранения информации в фактической файловой структуре сервера, однако это вызывает всевозможные сбои, поскольку API SqlFileStream работает только на реальном компьютере, а не на удаленном. Для моей базы данных мне пришлось настроить программу WCF для добавления огромных файлов в мою базу данных.
Если у вас есть только база данных, скажем, из 10 страниц, то обязательно вставляйте в BLOB-объект, однако, если вы добавляете журнал за журналом, это приведет к замедлению.
Если вы попытаетесь выполнить запросы типа «выбрать * из журналов», то эти запросы будут длиться вечно, потому что он фактически возвращает двоичные данные с этого сервера как часть запроса. Если вы запустите такой запрос к видео, вам придется долго ждать.
Комментарии:
1. Я не могу найти никакой документации, предполагающей, что MySQL имеет тип SqlFileStream.
2. Извините, я думал, что вы используете Microsoft SQL. Название немного вводит в заблуждение. В настоящее время я думаю, что вы застряли с BLOB тогда.
3. Ну, честно говоря, я бы, вероятно, выбрал
page_2_blob FROM magazines WHERE id = X, поскольку каждая страница журнала будет размещена на своей собственной веб-странице, т.website.com/issues.php?issue=1amp;page=2Е.. Я просто не уверен, как выбор BLOB-объекта из большой базы данных может сильно отличаться от выбора большой текстовой статьи.4. Все дело в размере. Большой двоичный объект может составлять более 100 ГБ, тогда как у вас никогда не может быть блока текста такого размера. Если ваш большой двоичный объект имеет общий размер 1 МБ, это вообще не повлияет на вашу базу данных. Проблемы возникают, когда люди сходят с ума и начинают вводить огромное количество информации, что и делают некоторые люди.
5. @ChristopherVickers Знаете ли вы какой-либо способ вычисления размера большого двоичного объекта на основе изображения? Как предполагается, каждая страница будет размером с лист бумаги — скорее всего, A5.