Какие СУБД позволяют хранить в них бинарные файлы? #484691

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

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

mysql, postgresql...

"Firebird is faster than filesystem for blob storage! (" - тестирование производительности показало, что хранить бинарные файлы в СУБД Firebird эффективнее, чем в файловой системе Windows. В ходе эксперимента было организовано копирование 3659 файлов общим объемом 343Мб, размещенным в 468 директориях. В Firebird данные были обработаны на 27669 ms, а в файловой системе за 40378 ms. (c)

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

sqlite

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

DBF,Paradox,Data и наконекст хит сезона TXT ! автору яд уже предлагали ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VFP развиваться не будет. С Вами всё понятно. Firebird идёт в топку из-за резервного восстановления данных. И так, ставится вопрос иначе, наверное должен: Хранение BLOB cо сжатием. Варианта 2: 1. Использовать СУБД (не обязательно реляционную), которая умеет хранить BLOB и использовать внешний архиватор. 2. Использовать СУБД, которая умеет хранить BLOB в пожатом виде (Microsoft SQL Server 2008 R2, Oracle 11g, IBM DB2 UDB)

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

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

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