Уважаемые! Что посоветуете выбрать в качестве БД для хранения _только_ небольших (100Б - 30Кб) изображений формата JPEG, PNG ?
Данные и требования:
1) большое кол-во изображений: > от сотен тысяч до миллионов
2) возможность обращения к БД из программы написанной на Delphi
3) быстрый поиск/чтение/запись
4) БД хранится в одном файле
5) небольшой размер СУБД (< 1Мб)

Существует что-нибудь подходящее?

Забыл уточнить, что база будет храниться на локальном компе, т.е. никакие "клиент-серверные" технологии не нужны :)

Мимопроходящий
тогда что-нить, типа Jet, или SQLite
Может есть какие специально "заточенные"/оптимизированные под хранение изборажений?

Мимопроходящий
Picasa2
Это нечто совсем неподходящее. Мне нужно хранилище для сотен тыс картинок, с возможностью управления им из-под Delphi.....

Dimitry Sibiryakov
Если бы не ограничение "все в одном файле", то я бы сказал, что лучше ФС
трудно что-то выдумать. Обосновать его (ограничения) необходимость можете?
ФС (NTFS, про FAT32 промолчу) заметно (до минут, зависит от многих праметров, как железа, так и оси) тормозит при открытии папки, в которой несколько десятков тысяч небольших файлов. Какое быстродействие будет при сотнях тысяч, миллионах?

Dimitry Sibiryakov
LiYing
тормозит при открытии папки, в которой несколько десятков тысяч
небольших файлов.

Шутите. Тормозит получение полного списка файлов. Открытие одного
конкретного файла - нет, поскольку (ЕМНИП) NTFS организует записи
каталога в виде сортированного дерева. И в любом случае даже на FAT32
достаточно организовать структуру папок вложенности 3-4, чтобы миллионы
файлов разложились мелкими пачками по паре сотен штук на папку.
Posted via ActualForum NNTP Server 1.4

Возможно и так. Но Вы пробовали архивировать или записывать на CD/DVD такое кол-во файлов? Процесс затягивается на часы... вот почему хотелось бы организовать хранилище в одном (ну нескольких) файле....

Dimitry Sibiryakov
Пробовал. На то и придумали Incremental Backup чтобы не писать все
сразу. Да и не влезут ваши миллионы файлов на DVD.
Я не говорил, что буду писать ВСЮ базу на болванку (это не бэкап).
Давайте не будем отклоняться от первоначальной задачи... Положим, что ФС не уподходит :)

Dimitry Sibiryakov
И совершенно напрасно. В описанных условиях любая СУБД проиграет
ей по производительности. Стало быть ответ стандартный - берите ту СУБД,
которую знаете.

Я понимаю, что ФС проиграет СУБД...
А что скажете про Berkly DB?

MGR LiYing

Я понимаю, что ФС проиграет СУБД...
А что скажете про Berkly DB?

Совсем даже наоборот!
И?? Какой СУБД проиграет?

DobPilotА не проще свой формат? -) Типа [размер файла1][имя файла1][данные1]...[размер файлаn][имя файлаn][данныеn] + индекс файл к нему [имя_файла1][смещение ведущее к данным1]...[имя_файлаn][смещение ведущее к даннымn]
Возможно и проще. Так (принцип) сделано, к примеру, для хранения кэша Google Earth.
Встают проблемы контроля целостности и некоторые другие... решаемо коненчо, но если уже есть готовое решение (ищется), зачем изобретать велосипед? :)

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

Из известных мне:
1. Oracle Content DB.
2. Documentum Storage Server (кажется так, но могу немного попутать)
3. Appache JackRabbit (и вообще любые решения для на базе стандарта JCR-170, JCR-283).

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

DobPilotА если не секрет конечная цель какова ?
Оперирование (чтение/запись) изображений :) См. программы типа GoogleMV/GoogleV и т.п.