Это продолжение ветки:
v8: v8: Хранение больших объемов данных внутри базы данных.

Хочется обсудить вопрос хранения файлов в СУБД. Может у кого-нибудь есть примеры хранения, подключения и извлечения файлов? Хочется определиться с СУБД которую буду использовать для хранения файлов. Хотелось, чтобы она была бесплатная.

Тип Blob в таблицах VFP. Не знаю с какой версии, но в 9-ке точно. Насчет бесплатности - мимо.

mysql, postgresql...

"Firebird is faster than filesystem for blob storage! (http://codicesoftware.blogspot.com/2008/09/firebird-is-faster-than-filesystem-for.html)" - тестирование производительности показало, что хранить бинарные файлы в СУБД Firebird эффективнее, чем в файловой системе Windows. В ходе эксперимента было организовано копирование 3659 файлов общим объемом 343Мб, размещенным в 468 директориях. В Firebird данные были обработаны на 27669 ms, а в файловой системе за 40378 ms. (c) http://www.opennet.ru/openforum/vsluhforumID3/43624.html

(3) " СУБД Firebird" сравнивают с "файловой системе Windows"???????
То есть теплое с мягким?!
Теплое победило?!

sqlite

(4) Мопед не мой, я просто разместил объяву :)

DBF,Paradox,Data и наконекст хит сезона TXT !

автору яд уже предлагали ?

(1) не поверишь с версии фоксбейз 2.0 а до того в дб2 (даже не 3)

в каких угодно - современных.

(7) тхт, кстати, стандарт межбанковского обмена. только вот с кодировками хехе.. хехе.

(0) Все. BLOB поле (binary large object)

Господа, давайте по ближе к теме. Понятно, что это можно сделать практически с любой СУБД. Интересует конкретный опыт.

В FireBird всё прекрасно хранится, и выбирается (причём можно Blob-поля по кусочкам "кушать"). Очень удобно, если писать на Си и т.п. Стандартный ADO DB не очень переваривает (так как пытается хранить копию в памяти, чтоб его).
Кроме того, Firebird позволяет разделить базу на несколько файлов, чтобы не было одного большого (который, например, для FAT-а невозможен).
P.S. а какие объёмы предполагается ?

Господа все в Париже (с)
а перечисленое - опыт

(10) у этого "стандарта" корни растут из безмозглости банковских программеров. С кодирвками проблема от туда же

(12) в приведенной тобой ветке в нулевом посте какие-то сугубо теретические размышления без конкретики. Тут конкретики в нулевом посте еще меньше. В деле хранения больших файлов всё от деталей зависит на 100%, серебряной пули нет.
Либо выкладывай конкретику, либо доволствуйся полученными ответами

(16) Там под конец и до конкретики дошли. Обсуждали алкогольные компании.

(13) Firebird рулит.. непонятно, почему 1с не поддерживает его как СУБД. Для небольших баз он был бы лучше постгреса, он удобнее в смысле хранения данных, резервного копирования и восстановления - вся база в одном файле. И сам по себе очень компактный. А по сути - такой же версионник, как и постгрес.

(13) админу,который размещает файл(ы) БД на FAT'е уже предлагали стандартный набор из стены\яда\етк?

(19) Что за фетишизм? ) FAT в целом ничем не хуже других ФС, просто у неё есть свои особенности, которые надо учитывать.

(20) У FireBird можно настроить размер файлов базы данных так, чтобы он имел фиксированный размер (то есть не перемещался и не двигался по диску), тогда FAT оказывается лучше и быстрее всего (запись времени изменения в директорию, где живут файлы и запись в сам файл).
Испортить такой файл достаточно сложно (а для директории просто можно сохранить образ).
NTFS же будет хранить информацию о файле в MasterFile, то есть лазить в начало диска - что не есть хорошо.
Кроме того, FAT оказывается быстрее NTFS, так как всякая служебная информация туда просто не пишется (права доступа и т.п.). Если для базы данных сервер отдельный, то на нём живёт только процесс самого SQL-сервера, а он всё равно имеет полные права на свои базы.
Конечно, если на этом сервере работают пользователи, то FAT уже сразу отменяется - иначе каждый пользователь может просто удалить базу.
P.S. у FireBird есть режим, когда базу можно монтировать с CD или DVD, то есть в режиме ReadOnly, что иногда очень удобно.

(1) VFP развиваться не будет.
(2) С Вами всё понятно.
(18) Firebird идёт в топку из-за резервного восстановления данных.

И так, ставится вопрос иначе, наверное должен:
Хранение BLOB cо сжатием.

Варианта 2:
1. Использовать СУБД (не обязательно реляционную), которая умеет хранить BLOB и использовать внешний архиватор.

2. Использовать СУБД, которая умеет хранить BLOB в пожатом виде
(Microsoft SQL Server 2008 R2, Oracle 11g, IBM DB2 UDB)

(22) "Firebird идёт в топку из-за резервного восстановления данных"
Что там не так с восстановлением данных? Как будто в постгресе с этим легче.. сколько воплей на форуме было "переустановил систему, как подключить базы постгреса?" )

А, что про MySQL все молчат?

(22) Собственно, сжатие на уровне SQL-сервера не есть хорошо, так как SQL-сервер загружается выполнением не свойственной ему задачи. Конечно, если вы хотите потом организовывать поиск или выборку сжатых данных, то другие способы будут хуже, так как потребуют подключения архиватора к SQL-серверу (в принципе, в Firebird можно попробовать использовать внешние функции для сжатия, но нет уверенности, что это всё будет хорошо работать).
P.S. и если мы говорим про FireBird не надо забывать про Interbase (собственно, Firebird - это бесплатный аналог InterBase).