Уважаемые! Что посоветуете выбрать в качестве БД для хранения _только_ небольших (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 и т.п.

Dimitry Sibiryakov
DobPilot
На реализацию core, потратил бы один ман дей, ибо
все в данном случае просто -)

Даже удаление отдельных картинок и повторное использование места внутри
многогигабайтного файла? Что-то мне сомнительно, что автор справится...
Угу.. это для меня в новинку. А если еще не удаление, а замещение с другим размером картинки? А выборка по дате сохранения?

miksoft LiYing(100Б - 30Кб) изображений формата JPEG, PNG ?
...
1) большое кол-во изображений: > от сотен тысяч до миллионов
...
5) небольшой размер СУБД (< 1Мб)если иметь базу в десятки гигабайт, то какой смысл жаться на размере исполняемого кода???

Вы таки огласите дополнительные требования на такое "хранилище".
В частности поддержка транзакций, репликаций, сложных критериев поиска и т.п.
Каким образом вы собираетесь поддерживать актуальность этой базы?
Я и не жмусь на размере исполняемого кода. Просто хотелось бы использовать небольшую СУБД, а не таких монстров как Oracle или MSSQL.
Собственно доп. требований, кроме вышеозначенных и нет. Чтение/запись, выборка по дате. Транзакции, репликации не нужны, база однопользовательская. Что имеется в виду под " поддерживать актуальность этой базы"?

miksoft LiYingЧто имеется в виду под " поддерживать актуальность этой базы"?Вы отдаете базу пользователю и она до скончания веков остается неизменной и работает только на чтение?
Или таки вам надо иногда обновлять ее содержимое? Если надо обновлять, то каким образом вы планируете это делать?
Мыслится так: я отдаю программу пользователю, прога создает пустую базу, которую юзер будет сам наполнять (скажем из папки, содержащей изображения). Должны поддерживаться операции чтения, записи и удаления. Еще нужна возможность объединять аналогичные базы (т.е. созданную другим юзером) и "выделять/вырезать" какую-то часть БД и сохранять в качестве отдельной базы (к примеру, выбрать все картинки с длиной имени=5 симв. (или с датой=хх.хх.хх) и сохранить в отдельную БД такой же структуры). Т.е. возможность переключения между наборами БД. И все это сделать из программы, написанной на Delphi под win32.

2 MBG: это можно сделать таким способом, как вы предлагаете?