|
|
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Здравствуйте!!! Я работа с БД (Oracle) и хотелось бы мне загрузить в мою таблицу картинку. Как мне это сделать загрузить в БД и получить обратно? Что это за тип данных Blob? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2007, 16:51:28 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Пример из документации Oracle сомнительный, не уверен что будет работать. Впрочем, там Oracle 8.1.7, которым не пользовался из-за устарелости. Но в документации по JDBC для Oracle 9i и 10g есть описание "работы с BLOB" c пригодными программными примерами. Если "работать" через JDBC, то чтение этой документации всё равно обязательно. Потому что всегда есть особенности для определённой СУБД и JDBC драйвера. Ещё есть книжки по JDBC с описанием особенностей Oracle, там тоже есть примеры (книжки легко найти в интернете). Что такое BLOB - опять же, написано в документации Oracle (в документации по SQL, а также отдельный документ про LOB-ы (Large Objects). Кратко - BLOB это поле, содержащее произвольные бинарные данные, в том числе например, байты из файла с картинкой, но в BLOB-е характер данных не имеет значения - можно только записать данные и прочитать, а как использовать - определяется вызывающей программой. В Oracle есть также CLOB - большие текстовые объекты. LOB - общее название для BLOB и CLOB. Вообще картинки в Oracle можно хранить в полях типа BLOB, LONG RAW и BFILE. Из них LONG RAW устарел и не рекомендуется, а BFILE - это по-существу указатель на внешний файл с картинкой. То есть скорее всего лучше выбрать BLOB. JDBC - это стандартный интерфейс для работы с базами в Java. Но есть специальное решение для Oracle - Oracle Intermedia. В нём фактически хранение происходит тоже в BLOB-е, но через объект, содержащий параметры иображения - такие как размер картинки, формат файла. Может, это удобнее (сам не пользовался). В BLOB-е хранятся только бинарные данные, поэтому дополнительные параметры (если нужны) надо сохранять в базе отдельно в дополнительных полях таблицы. Изучать Hibernate только для того, чтобы воспользоваться BLOB - экзотическое решение. Не сразу ответил потому что не понял, что значит "Я работа с Oracle". Под словом "работа" можно понимать что угодно, надо указывать точнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 10:42:36 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Не слишком ли это тяжело(с тчки зрения производительности) Blob-ы из базы такскать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 11:34:19 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
StubНе слишком ли это тяжело(с тчки зрения производительности) Blob-ы из базы такскать. Нормалёк. Здесь главным аргументом должно быть не "тяжело" а "правильно". Все альтернативные способы привязки картинок к базе очень быстро идут фтопку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 12:47:57 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
mayton StubНе слишком ли это тяжело(с тчки зрения производительности) Blob-ы из базы такскать. Нормалёк. Здесь главным аргументом должно быть не "тяжело" а "правильно". Все альтернативные способы привязки картинок к базе очень быстро идут фтопку. - одно и то же обсуждаем по сто раз :( - кто сказал что то и или иное решение "правильное"? в какой спецификации или каком паттерне это написано? У хранения картинок в базе есть одни проблемы, а у хранения картинок в файловой системе другие, но и в том и в другом случае проблемы есть, просто они разные и в зависимости от задачи некоторые проблемы оказываются более значимыми чем другие. Вот Вы не спросили у человека сколько картинок, какого размера он собирается хранить и с какой частотой картинки будут извлекаться, а также о чем идет речь: web? standalone application? как ведется работа с БД? JDBC? EJB? а уже уверенно говорите "фтопку" :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 13:20:31 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Kachalov - кто сказал что то и или иное решение "правильное"? в какой спецификации или каком паттерне это написано? У хранения картинок в базе есть одни проблемы, а у хранения картинок в файловой системе другие, но и в том и в другом случае проблемы есть, просто они разные и в зависимости от задачи некоторые проблемы оказываются более значимыми чем другие. Вот Вы не спросили у человека сколько картинок, какого размера он собирается хранить и с какой частотой картинки будут извлекаться, а также о чем идет речь: web? standalone application? как ведется работа с БД? JDBC? EJB? а уже уверенно говорите "фтопку" Я внимательно рассматривал ваш профиль, Качалов. У меня нет такого количества медалей и знаков отличия. Я - скромный инженер-трудяга из глубинки. Но я имею свой взгляд на проблему хранения данных. Я считаю, что постановка задачи, при которой нужно хранить связные с БД документы во внешних хранилищах ФС имеет свои изъяны. Причём количество этих изьянов несовместимо с преимуществами, которые мы получаем от подобной "гетерогенности". Здесь мне остаётся только присоединится к мнению одного из экспертов в области БД. Я все храню в базе данных. Точка. Если данные что-нибудь значат для вас, имеют какое-либо значение вообще, то вы в действительности поместите их в базу данных, где они будут профессионально администрироваться, будут создаваться их резервные копии, данные будут восстанавливаемыми и защищенными от несанкционированного доступа. В дополнение к этим явным выгодам, вы также получите возможность индексирования и поиска ваших документов. (Правда, это может быть сделано также и в файловой системе, но тогда не будет никакой целостности между индексом и самим документом.) В базе данных вы получаете возможность преобразования формата документа (например, загрузить DOC-файл и представить его в HTML-формате.) Ваши данные полностью интегрированы, защищены, резервированы и всегда доступны вам. В корпорации Oracle мы имеем для внутреннего пользования многотерабайтовую базу данных, используемую как единый файловый сервер для всей компании. Все документы компании находятся там – зарезервированные, пригодные для поиска, проиндексированные и полностью доступные – в одном-единственном месте. Управление тысячами тысяч документов было бы невозможным, если бы они находились в обычной файловой системе (даже если бы файловая система смогла разместить их всех). В качестве дополнения. Лично считаю, что интефейс ФС уже вошёл в классику и всегда будет востребован и актуален, как наиболее прозрачный, простой, удобный для бекапирования, инструмент. С нетерпением ожидаю интересных разработак в области конвергенции РСУБД и ФС. До меня доходили слухи, что SUN и HP уже ведут исследования в этом направлении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 13:47:44 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
mayton Я все храню в базе данных. Точка. Если данные что-нибудь значат для вас, имеют какое-либо значение вообще, то вы в действительности поместите их в базу данных, где они будут профессионально администрироваться, будут создаваться их резервные копии, данные будут восстанавливаемыми и защищенными от несанкционированного доступа. В дополнение к этим явным выгодам, вы также получите возможность индексирования и поиска ваших документов. (Правда, это может быть сделано также и в файловой системе, но тогда не будет никакой целостности между индексом и самим документом.) В базе данных вы получаете возможность преобразования формата документа (например, загрузить DOC-файл и представить его в HTML-формате.) Ваши данные полностью интегрированы, защищены, резервированы и всегда доступны вам. В корпорации Oracle мы имеем для внутреннего пользования многотерабайтовую базу данных, используемую как единый файловый сервер для всей компании. Все документы компании находятся там – зарезервированные, пригодные для поиска, проиндексированные и полностью доступные – в одном-единственном месте. Управление тысячами тысяч документов было бы невозможным, если бы они находились в обычной файловой системе (даже если бы файловая система смогла разместить их всех). Дядька Том не хранит 4,5 гигабайтные (да хотя бы и 700 мегабайтные) образы дисков в своей корпоративной СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 14:00:56 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Хоть это к картинкам и не относится. Это скорее по поводу "хранить всё в СУБД". Иногда таки стоит задумаццо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 14:03:16 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
maytonНо я имею свой взгляд на проблему хранения данных. Я считаю, что постановка задачи, при которой нужно хранить связные с БД документы во внешних хранилищах ФС имеет свои изъяны. Причём количество этих изьянов несовместимо с преимуществами, которые мы получаем от подобной "гетерогенности". - вот это уже серъезный разговор! А то сразу "фтопку" :) mayton Здесь мне остаётся только присоединится к мнению одного из экспертов в области БД. - это частное мнение какого-то анонимного программиста (причем довольно категоричное: "Точка.") основанное на тех задачах и ПО с которыми он сталкивался. Согласитесь что индексирование картинок ... не звучит :) Преобразование формата ... тоже мимо. Поиск по бинарникам ... Если в ФС системе используются права доступа и бэкапирование то вопросы ограничения доступа и надежности также решены. Единственные аргументы за: "целостность" и "удобство". Кроме того, если бы аноним использовал не Oracle для внутреннего использования, а MySQL для работы с web, то возможно его взгляды на жизнь заметно бы поменялись. maytonЛично считаю, что интефейс ФС уже вошёл в классику и всегда будет востребован и актуален, как наиболее прозрачный, простой, удобный для бекапирования, инструмент. С нетерпением ожидаю интересных разработак в области конвергенции РСУБД и ФС. До меня доходили слухи, что SUN и HP уже ведут исследования в этом направлении. - кстати в JAVA всегда можно спользовать JNDI поверх ФС (у Sun есть соответствующий SPI к ФС и примерчики по его использованию) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 14:23:03 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Kachalov...Согласитесь что индексирование картинок ... не звучит :) Преобразование формата ... тоже мимо. Поиск по бинарникам ... У вас, наверное немножко устаревшие сведения о РСУБД. Современные образцы позволяют индексировать и выполнять поиск не только по атомарным, а и по сложным бинарным типам данных. Многие современные мультимедиа форматы (JPEG например) хранят достаточно метаинформации в заголовках, чтобы выполнять какие-то базовые поисковые операции. К примеру мой цифровик шлёпает снимки с указанием модели камеры, размеров, разрешения получателя, даты и времени съёмки и проч. А это чрезвычайно удобно при организации Web-фотоальбомов. А следующий пример из Oracle Intermedia демонстрирует поиск по "нечётким" признакам из базы графических изображений. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. Имеются реализации поиска по видео и звуковым форматам бинарных данных. Ну а про форматы документов (doc, pdf, chm) я вообще молчу. Их индексирование на сегодня - задача уже решённая. - кстати в JAVA всегда можно спользовать JNDI поверх ФС (у Sun есть соответствующий SPI к ФС и примерчики по его использованию) Спасибо за информацию. Почитаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 14:58:24 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
maytonУ вас, наверное немножко устаревшие сведения о РСУБД. Современные образцы позволяют индексировать и выполнять поиск не только по атомарным, а и по сложным бинарным типам данных. Многие современные мультимедиа форматы (JPEG например) хранят достаточно метаинформации в заголовках, чтобы выполнять какие-то базовые поисковые операции. К примеру мой цифровик шлёпает снимки с указанием модели камеры, размеров, разрешения получателя, даты и времени съёмки и проч. А это чрезвычайно удобно при организации Web-фотоальбомов. - круто! правда не знал, спасибо. Но это Oracle, а Oracle с web-фотоальбомом как то плохо кореллируется. В моем представлении Oracle это корпоративная БД, а web-фотоальбом это массовый web (т. е. сайты, хостинг, MySQL/PostgreSQL), т. е. разные задачи, разные ресурсы, разные возможности, разная нагрузка, и, если мы оговоримся что БД не Oracle, то утверждение что хранить картинки в БД "надо всегда", все таки ставится под сомнение :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 15:20:10 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
"Веб-фотоальбом" для Oracle не проблема. (Я измерял время и дополнительный расход памяти в Oracle при хранении картинок в BLOB - невелики). Но не охота что-то многократно доказывать (точнее ругаться) - всякий раз, когда возникет вопрос про BLOB, находится кто-то, высказывающий идею: а вот есть ещё файловая система. Это наблюдение. Ну есть ну и что. Мало ли что есть, всего и не перечислить, причём многое из него плохое. Что можно иметь ввиду при работе с Oracle. - различие между LONG RAW и BLOB. когда выбираем записи из базы данных по оператору SELECT *, то из полей LONG RAW извлекаются сами данные, то есть если записей результата много, то может возникнуть большой расход памяти для него. Ддя BLOB извлекаются указатели на данные BLOB (в документации Ortacle - locator-ы). Данные извлекаются по указателю дополнительной операцией. Исключение составляют маленькие BLOB-ы, которые можно хранить в самой таблице, наподобие LONG RAW. - Разные режимы чтения BLOB. Физически BLOB-ы хранятся в специальных страницах, обычно назывемых сегментами (но в документации Oracle сегментом BLOB называется пространство на диске, выделенное для всех BLOB-ов схемы базы данных). Соответственно, в JDBC есть режимы чтения - по сегментам, или потоковый (как stream). В зависимости от базы и драйвера доступен один из режимов или оба. В Oracle есть оба варианта. Через поток проще, и можно прочитать произвольную часть BLOB-а. Чтение BLOB-а по частям можно применить, если надо экономить память. Например, в цикле читаем часть, выводим её в сервлете. - При хранении картинок во внешних файлах следует использовать тип BFILE, но по сравнению с BLOB него есть недостатки - не обеспечивается целостность базы (если удалить или изменить данные файла, то в базе это не отразится ) и такие данные не участвуют в операции репликации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 17:40:05 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Partisan M"Веб-фотоальбом" для Oracle не проблема. (Я измерял время и дополнительный расход памяти в Oracle при хранении картинок в BLOB - невелики). - а он (web-фотоальбом) сильно нужен пользователям Oracle? (см. пост выше, зачем по второму, третьему и т. д. разу обсуждать одно и то же?) Partisan M Но не охота что-то многократно доказывать (точнее ругаться) - всякий раз, когда возникет вопрос про BLOB, находится кто-то, высказывающий идею: а вот есть ещё файловая система. Это наблюдение. Ну есть ну и что. Мало ли что есть, всего и не перечислить, причём многое из него плохое. - странно что иная точка зрения вызывает у собеседника желание "ругаться". Мне тут недавно нос утирали, мол не надо плодить новые сущности кроме существующих ("Бритва Оккама" мол), так ФС уже существует, а БД это новая сущность, которая в некоторых задачах является лишней, так как для хранения файлов уже есть ФС. - я извиняюсь если мои тезисы выглядят как флейм, но по существу все давно сказано (типа: не каждая БД это Oracle и не везде задачи одинаковые), а стабильное нежелание спокойно относиться к чужой точке зрения (основанной на ином опыте) задевает. Еще раз извиняюсь, это не личный выпад, а так, философские рассуждения не требующие ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2007, 18:14:58 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
can4ecЗдравствуйте!!! Я работа с БД (Oracle) и хотелось бы мне загрузить в мою таблицу картинку. Как мне это сделать загрузить в БД и получить обратно? Что это за тип данных Blob? Типа, есть таблица: Код: plaintext 1. 2. 3. 4. Вставка BLOB объекта в базу данных: Сначала нужно выполнить SQL запрос вставки пустого BLOB в таблицу БД, а затем, выполнить SQL запрос SELECT FOR UPDATE для только что вставленного пустого BLOB, получить java-wrapper BLOB, получить входной поток java-wrapper'a и записать в этот поток нужные данные. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2007, 14:33:46 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Изя ШниперсонВставка BLOB объекта в базу данных: Сначала нужно выполнить SQL запрос вставки пустого BLOB в таблицу БД, а затем, выполнить SQL запрос SELECT FOR UPDATE для только что вставленного пустого BLOB, получить java-wrapper BLOB, получить входной поток java-wrapper'a и записать в этот поток нужные данные. Как дополнение, тут удобно будет использовать инсерт с returning into: Код: plaintext 1. 2. Kachalov Partisan M Из собственной практики - размер иногда действительно имеет значение ;) Сталкивался с ситуацией, когда даже нужные для бизнеса архивные документы удалялись из БД через несколько месяцев хранения с целью экономии дискового пространства. А для нас потом был лишний геморрой, но как грится "кто платит ..." Переубедить не смогли :(( И здесь как раз тот случай, когда исходить в первую очередь надо из того, что выше - стоимость (полная) хранения всех данных в БД или цена потери сохраненных не в БД данных. При прочих равных я конечно за первый вариант, но иногда приходится учитывать и ограничения бизнеса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2007, 15:40:00 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Увы, у файловой системы есть один, но очень существенный, плюс по сравнению с БД - быстрые web-сервера очень существенно оптимизированы для работы с файлами. Т.е. если задача - как можно быстрее отдать пользователям большой объем данных, то lhttpd + хорошая файловая система существенно эффективнее БД. Но таких задач, в общем, не много, а в остальных, по видимому, проще хранить все данные единообразно - в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2007, 20:06:54 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
DPHУвы, у файловой системы есть один, но очень существенный, плюс по сравнению с БД - быстрые web-сервера очень существенно оптимизированы для работы с файлами. Т.е. если задача - как можно быстрее отдать пользователям большой объем данных, то lhttpd + хорошая файловая система существенно эффективнее БД. Но таких задач, в общем, не много, а в остальных, по видимому, проще хранить все данные единообразно - в БД. СУБД предназначены как раз для обеспечения доступа к данным при большой нагрузке - когда пользователей много и все они очень часто к данным обращаются . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2007, 11:21:12 |
|
||
|
Тип данных Blob
|
|||
|---|---|---|---|
|
#18+
Изя Шниперсон СУБД предназначены как раз для обеспечения доступа к данным при большой нагрузке - когда пользователей много и все они очень часто к данным обращаются . 1. Все СУБД расчитаны на большую нагрузку по количеству соединений? (дурацкий пример Access) 2. С какими объемами данных может эффективно работать СУБД (какие размеры таблицы, размеры поля)? (у разных СУБД разные возможности в плане эффективности работы с разными типами и объемами данных) 3. Зачем разводить флэйм? Пишите конкретней, а то из Вашего поста можно подумать что никакая ФС не может обеспечить доступ большого количества пользователей к хранимым данным (опять же, для некоторых видов ФС это может быть и так). Зачем ставить вопрос в форме: ФС vs СУБД? И СУБД бывают разные и ФС. Можно говорить об эффективности применительно к конкретной задаче (выборка/запись/размер) и конкретным типам СУБД (Oracle/SQLite/PostgreSQL/SQL Server и т.д.) и ФС (ext3/FAT/NTFS и т.д.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2007, 11:36:20 |
|
||
|
|

start [/forum/topic.php?fid=59&gotonew=1&tid=2144403]: |
0ms |
get settings: |
19ms |
get forum list: |
28ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
73ms |
get topic data: |
23ms |
get first new msg: |
16ms |
get forum data: |
6ms |
get page messages: |
98ms |
get tp. blocked users: |
3ms |
| others: | 409ms |
| total: | 689ms |

| 0 / 0 |
