Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / Тип данных Blob / 19 сообщений из 19, страница 1 из 1
06.10.2007, 16:51:28
    #34851845
can4ec
can4ec
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Здравствуйте!!! Я работа с БД (Oracle) и хотелось бы мне загрузить в мою таблицу картинку. Как мне это сделать загрузить в БД и получить обратно? Что это за тип данных Blob?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.10.2007, 23:19:21
    #34852090
Паганель
Паганель
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Пара примеров:
Вот из доки Oracle
А вот с hibernate.org
Google рулит :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 10:42:36
    #34852285
Partisan M
Partisan M
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Пример из документации 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". Под словом "работа" можно понимать что угодно, надо указывать точнее.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 11:34:19
    #34852310
Stub
Stub
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Не слишком ли это тяжело(с тчки зрения производительности) Blob-ы из базы такскать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 12:47:57
    #34852368
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
StubНе слишком ли это тяжело(с тчки зрения производительности) Blob-ы из базы такскать.

Нормалёк. Здесь главным аргументом должно быть не "тяжело" а "правильно". Все альтернативные способы привязки картинок к базе очень быстро идут фтопку.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 13:20:31
    #34852394
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
mayton StubНе слишком ли это тяжело(с тчки зрения производительности) Blob-ы из базы такскать.

Нормалёк. Здесь главным аргументом должно быть не "тяжело" а "правильно". Все альтернативные способы привязки картинок к базе очень быстро идут фтопку.
- одно и то же обсуждаем по сто раз :(

- кто сказал что то и или иное решение "правильное"? в какой спецификации или каком паттерне это написано? У хранения картинок в базе есть одни проблемы, а у хранения картинок в файловой системе другие, но и в том и в другом случае проблемы есть, просто они разные и в зависимости от задачи некоторые проблемы оказываются более значимыми чем другие. Вот Вы не спросили у человека сколько картинок, какого размера он собирается хранить и с какой частотой картинки будут извлекаться, а также о чем идет речь: web? standalone application? как ведется работа с БД? JDBC? EJB? а уже уверенно говорите "фтопку" :(
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 13:47:44
    #34852420
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Kachalov
- кто сказал что то и или иное решение "правильное"? в какой спецификации или каком паттерне это написано? У хранения картинок в базе есть одни проблемы, а у хранения картинок в файловой системе другие, но и в том и в другом случае проблемы есть, просто они разные и в зависимости от задачи некоторые проблемы оказываются более значимыми чем другие. Вот Вы не спросили у человека сколько картинок, какого размера он собирается хранить и с какой частотой картинки будут извлекаться, а также о чем идет речь: web? standalone application? как ведется работа с БД? JDBC? EJB? а уже уверенно говорите "фтопку"

Я внимательно рассматривал ваш профиль, Качалов. У меня нет такого количества медалей и знаков отличия. Я - скромный инженер-трудяга из глубинки. Но я имею свой взгляд на проблему хранения данных. Я считаю, что постановка задачи, при которой нужно хранить связные с БД документы во внешних хранилищах ФС имеет свои изъяны. Причём количество этих изьянов несовместимо с преимуществами, которые мы получаем от подобной "гетерогенности". Здесь мне остаётся только присоединится к мнению одного из экспертов в области БД.


Я все храню в базе данных. Точка. Если данные что-нибудь значат для вас, имеют какое-либо значение вообще, то вы в действительности поместите их в базу данных, где они будут профессионально администрироваться, будут создаваться их резервные копии, данные будут восстанавливаемыми и защищенными от несанкционированного доступа. В дополнение к этим явным выгодам, вы также получите возможность индексирования и поиска ваших документов. (Правда, это может быть сделано также и в файловой системе, но тогда не будет никакой целостности между индексом и самим документом.) В базе данных вы получаете возможность преобразования формата документа (например, загрузить DOC-файл и представить его в HTML-формате.) Ваши данные полностью интегрированы, защищены, резервированы и всегда доступны вам.

В корпорации Oracle мы имеем для внутреннего пользования многотерабайтовую базу данных, используемую как единый файловый сервер для всей компании. Все документы компании находятся там – зарезервированные, пригодные для поиска, проиндексированные и полностью доступные – в одном-единственном месте. Управление тысячами тысяч документов было бы невозможным, если бы они находились в обычной файловой системе (даже если бы файловая система смогла разместить их всех).


В качестве дополнения. Лично считаю, что интефейс ФС уже вошёл в классику и всегда будет востребован и актуален, как наиболее прозрачный, простой, удобный для бекапирования, инструмент. С нетерпением ожидаю интересных разработак в области конвергенции РСУБД и ФС. До меня доходили слухи, что SUN и HP уже ведут исследования в этом направлении.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 14:00:56
    #34852436
Софтверный проктолог
Софтверный проктолог
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
mayton
Я все храню в базе данных. Точка. Если данные что-нибудь значат для вас, имеют какое-либо значение вообще, то вы в действительности поместите их в базу данных, где они будут профессионально администрироваться, будут создаваться их резервные копии, данные будут восстанавливаемыми и защищенными от несанкционированного доступа. В дополнение к этим явным выгодам, вы также получите возможность индексирования и поиска ваших документов. (Правда, это может быть сделано также и в файловой системе, но тогда не будет никакой целостности между индексом и самим документом.) В базе данных вы получаете возможность преобразования формата документа (например, загрузить DOC-файл и представить его в HTML-формате.) Ваши данные полностью интегрированы, защищены, резервированы и всегда доступны вам.

В корпорации Oracle мы имеем для внутреннего пользования многотерабайтовую базу данных, используемую как единый файловый сервер для всей компании. Все документы компании находятся там – зарезервированные, пригодные для поиска, проиндексированные и полностью доступные – в одном-единственном месте. Управление тысячами тысяч документов было бы невозможным, если бы они находились в обычной файловой системе (даже если бы файловая система смогла разместить их всех).

Дядька Том не хранит 4,5 гигабайтные (да хотя бы и 700 мегабайтные) образы дисков в своей корпоративной СУБД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 14:03:16
    #34852440
Софтверный проктолог
Софтверный проктолог
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Хоть это к картинкам и не относится. Это скорее по поводу "хранить всё в СУБД". Иногда таки стоит задумаццо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 14:23:03
    #34852465
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
maytonНо я имею свой взгляд на проблему хранения данных. Я считаю, что постановка задачи, при которой нужно хранить связные с БД документы во внешних хранилищах ФС имеет свои изъяны. Причём количество этих изьянов несовместимо с преимуществами, которые мы получаем от подобной "гетерогенности".
- вот это уже серъезный разговор! А то сразу "фтопку" :)

mayton Здесь мне остаётся только присоединится к мнению одного из экспертов в области БД.
- это частное мнение какого-то анонимного программиста (причем довольно категоричное: "Точка.") основанное на тех задачах и ПО с которыми он сталкивался. Согласитесь что индексирование картинок ... не звучит :) Преобразование формата ... тоже мимо. Поиск по бинарникам ... Если в ФС системе используются права доступа и бэкапирование то вопросы ограничения доступа и надежности также решены. Единственные аргументы за: "целостность" и "удобство". Кроме того, если бы аноним использовал не Oracle для внутреннего использования, а MySQL для работы с web, то возможно его взгляды на жизнь заметно бы поменялись.


maytonЛично считаю, что интефейс ФС уже вошёл в классику и всегда будет востребован и актуален, как наиболее прозрачный, простой, удобный для бекапирования, инструмент. С нетерпением ожидаю интересных разработак в области конвергенции РСУБД и ФС. До меня доходили слухи, что SUN и HP уже ведут исследования в этом направлении.
- кстати в JAVA всегда можно спользовать JNDI поверх ФС (у Sun есть соответствующий SPI к ФС и примерчики по его использованию)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 14:58:24
    #34852483
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
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.
DECLARE
threshold NUMBER;
compare_sig ORDSYS.ORDImageSignature;
photographer VARCHAR2( 64 );
annotation VARCHAR2( 255 );
photo ORDSYS.ORDIMAGE;
-- Define cursor for matching. Set weights for the visual attributes.
CURSOR getphotos IS
SELECT photograpger, annotation, photo FROM stockphotos S
WHERE ORDSYS.IMGSimilar(S.photo_sig, compare_sig,
’color="0.2" texture="0.1" shape="0.4"
location="0.3"’, threshold)= 1  AND photo_id <>  1 ;
BEGIN
-- select signature of image you want to match against
SELECT P.photo_sig INTO compare_img FROM stockphotos P
WHERE P.photo_id =  1 ;
-- Set the threshold value.
threshold :=  25 ;
-- Retrieve rows for matching images.
OPEN getphotos;
LOOP
FETCH getphotos INTO photographer, annotation, photo;
EXIT WHEN getphotos%NOTFOUND;
-- Display or store the results.
-- .
-- .
END LOOP;
CLOSE getphotos;
END;
/

Имеются реализации поиска по видео и звуковым форматам бинарных данных.

Ну а про форматы документов (doc, pdf, chm) я вообще молчу. Их индексирование на сегодня - задача уже решённая.




- кстати в JAVA всегда можно спользовать JNDI поверх ФС (у Sun есть соответствующий SPI к ФС и примерчики по его использованию)

Спасибо за информацию. Почитаю.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 15:20:10
    #34852497
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
maytonУ вас, наверное немножко устаревшие сведения о РСУБД. Современные образцы позволяют индексировать и выполнять поиск не только по атомарным, а и по сложным бинарным типам данных. Многие современные мультимедиа форматы (JPEG например) хранят достаточно метаинформации в заголовках, чтобы выполнять какие-то базовые поисковые операции. К примеру мой цифровик шлёпает снимки с указанием модели камеры, размеров, разрешения получателя, даты и времени съёмки и проч. А это чрезвычайно удобно при организации Web-фотоальбомов.
- круто! правда не знал, спасибо. Но это Oracle, а Oracle с web-фотоальбомом как то плохо кореллируется. В моем представлении Oracle это корпоративная БД, а web-фотоальбом это массовый web (т. е. сайты, хостинг, MySQL/PostgreSQL), т. е. разные задачи, разные ресурсы, разные возможности, разная нагрузка, и, если мы оговоримся что БД не Oracle, то утверждение что хранить картинки в БД "надо всегда", все таки ставится под сомнение :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 17:40:05
    #34852601
Partisan M
Partisan M
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
"Веб-фотоальбом" для 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 него есть недостатки - не обеспечивается целостность базы (если удалить или изменить данные файла, то в базе это не отразится ) и такие данные не участвуют в операции репликации.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.10.2007, 18:14:58
    #34852626
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Partisan M"Веб-фотоальбом" для Oracle не проблема. (Я измерял время и дополнительный расход памяти в Oracle при хранении картинок в BLOB - невелики).
- а он (web-фотоальбом) сильно нужен пользователям Oracle? (см. пост выше, зачем по второму, третьему и т. д. разу обсуждать одно и то же?)

Partisan M
Но не охота что-то многократно доказывать (точнее ругаться) - всякий раз, когда возникет вопрос про BLOB, находится кто-то, высказывающий идею: а вот есть ещё файловая система. Это наблюдение. Ну есть ну и что. Мало ли что есть, всего и не перечислить, причём многое из него плохое.
- странно что иная точка зрения вызывает у собеседника желание "ругаться". Мне тут недавно нос утирали, мол не надо плодить новые сущности кроме существующих ("Бритва Оккама" мол), так ФС уже существует, а БД это новая сущность, которая в некоторых задачах является лишней, так как для хранения файлов уже есть ФС.

- я извиняюсь если мои тезисы выглядят как флейм, но по существу все давно сказано (типа: не каждая БД это Oracle и не везде задачи одинаковые), а стабильное нежелание спокойно относиться к чужой точке зрения (основанной на ином опыте) задевает. Еще раз извиняюсь, это не личный выпад, а так, философские рассуждения не требующие ответа.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
08.10.2007, 14:33:46
    #34854136
Изя Шниперсон
Изя Шниперсон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
can4ecЗдравствуйте!!! Я работа с БД (Oracle) и хотелось бы мне загрузить в мою таблицу картинку. Как мне это сделать загрузить в БД и получить обратно? Что это за тип данных Blob?


Типа, есть таблица:
Код: plaintext
1.
2.
3.
4.
CREATE TABLE MYBLOBTABLE
(
 ID NUMBER( 5 ),
 BLOBOBJECT BLOB());

Вставка 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.
..............
//Вставка пустого BLOB
            OracleConnection conn = (OracleConnection)getConnection();
            OracleStatement statement = (OracleStatement)conn.createStatement();
            OracleResultSet result = 
                (OracleResultSet)statement.executeQuery("insert into MYBLOBTABLE (ID, BLOBOBJECT)
VALUES (1, , EMPTY_BLOB () );");           
            result.close();
            statement.close();
            conn.close();

         //Открытие BLOB
            BLOB[] b =  new  BLOB[ 1 ];
            conn = (OracleConnection)getConnection();
            OracleStatement statement = (OracleStatement)conn.createStatement();
            OracleResultSet result = 
                (OracleResultSet)statement.executeQuery("select BLOBOBJECT from MYBLOBTABLE where ID=1");
             while  (result.next()) {
                b[ 0 ] = result.getBLOB( 1 );
            }
            result.close();
            statement.close();
 //Запись в BLOB из потока            
           Writer blobWriter = b[ 0 ].getCharacterOutputStream(); 
            blobWriter.write("ZAPIC V BLOB 1"); 
            blobWrite.flush();
   	    tblobWrite.close(); 
   	    b[ 0 ].close();
.........
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
08.10.2007, 15:40:00
    #34854407
TiG
TiG
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Изя ШниперсонВставка BLOB объекта в базу данных:
Сначала нужно выполнить SQL запрос вставки пустого BLOB в таблицу БД,
а затем, выполнить SQL запрос SELECT FOR UPDATE для только что вставленного пустого BLOB,
получить java-wrapper BLOB, получить входной поток java-wrapper'a и записать в этот поток нужные данные.
Как дополнение, тут удобно будет использовать инсерт с returning into:
Код: plaintext
1.
2.
insert into MYBLOBTABLE (ID, BLOBOBJECT)
  values ( 1 , EMPTY_BLOB () )
  returning blobobject into :new_lob_locator
вместо инсерт+селект.

Kachalov Partisan M
Из собственной практики - размер иногда действительно имеет значение ;) Сталкивался с ситуацией, когда даже нужные для бизнеса архивные документы удалялись из БД через несколько месяцев хранения с целью экономии дискового пространства. А для нас потом был лишний геморрой, но как грится "кто платит ..." Переубедить не смогли :((
И здесь как раз тот случай, когда исходить в первую очередь надо из того, что выше - стоимость (полная) хранения всех данных в БД или цена потери сохраненных не в БД данных. При прочих равных я конечно за первый вариант, но иногда приходится учитывать и ограничения бизнеса.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
08.10.2007, 20:06:54
    #34855169
DPH
DPH
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Увы, у файловой системы есть один, но очень существенный, плюс по сравнению с БД - быстрые web-сервера очень существенно оптимизированы для работы с файлами.

Т.е. если задача - как можно быстрее отдать пользователям большой объем данных, то lhttpd + хорошая файловая система существенно эффективнее БД.

Но таких задач, в общем, не много, а в остальных, по видимому, проще хранить все данные единообразно - в БД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2007, 11:21:12
    #34856079
Изя Шниперсон
Изя Шниперсон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
DPHУвы, у файловой системы есть один, но очень существенный, плюс по сравнению с БД - быстрые web-сервера очень существенно оптимизированы для работы с файлами.

Т.е. если задача - как можно быстрее отдать пользователям большой объем данных, то lhttpd + хорошая файловая система существенно эффективнее БД.

Но таких задач, в общем, не много, а в остальных, по видимому, проще хранить все данные единообразно - в БД.

СУБД предназначены как раз для обеспечения доступа к данным при большой нагрузке -
когда пользователей много и все они очень часто к данным обращаются .
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.10.2007, 11:36:20
    #34856163
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тип данных Blob
Изя Шниперсон
СУБД предназначены как раз для обеспечения доступа к данным при большой нагрузке -
когда пользователей много и все они очень часто к данным обращаются .

1. Все СУБД расчитаны на большую нагрузку по количеству соединений? (дурацкий пример Access)

2. С какими объемами данных может эффективно работать СУБД (какие размеры таблицы, размеры поля)? (у разных СУБД разные возможности в плане эффективности работы с разными типами и объемами данных)

3. Зачем разводить флэйм? Пишите конкретней, а то из Вашего поста можно подумать что никакая ФС не может обеспечить доступ большого количества пользователей к хранимым данным (опять же, для некоторых видов ФС это может быть и так). Зачем ставить вопрос в форме: ФС vs СУБД? И СУБД бывают разные и ФС. Можно говорить об эффективности применительно к конкретной задаче (выборка/запись/размер) и конкретным типам СУБД (Oracle/SQLite/PostgreSQL/SQL Server и т.д.) и ФС (ext3/FAT/NTFS и т.д.).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Java [игнор отключен] [закрыт для гостей] / Тип данных Blob / 19 сообщений из 19, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 700ms
Закрыть
start [/forum/topic.php?fid=59&tablet=1&tid=2144403]:
 0ms
get settings:
 20ms
get forum list:
 24ms
check forum access:
 7ms
check topic access:
 7ms
track hit:
 73ms
get topic data:
 24ms
get forum data:
 6ms
get page messages:
 110ms
get tp. blocked users:
 3ms
others: 426ms
total:  700ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]