Разрабатывается СУБД для хранения большого числа фотографий. Их количество может достичь 5-10 млн. шт. СУБД будет иметь архитектуру мастер-деталь. В мастер-таблице число записей будет 50-60 тыс. шт., в детали каждой строке и мастер будет соответствовать несколько десятков фото. Главная задача СУБД - просмотр фотографий. Т.е. пользователь выберет запись из мастера и вызовет форму просмотра . Вот здесь основная проблема. Как быстро будет выполняться выборка, не будет ли тормозить ? Желательно, что бы выборка сработала хотя бы за секунду. Если выборка будет выполняться, скажем, 10 секунд, то это никого не устроит. И какую СУБД выбрать в смысле надёжности ? Пока я использую FireBird, но это скорее всего временное рашение.

> Пока я использую FireBird

и какова скорость выборки?

>Как быстро будет выполняться выборка
Выборка чего?
50-60 тысяч записей в главной и 100 на каждую в детали - это детский лепет для СУБД, если конечно индексами не пренебрегать. Вот передача по сети СРАЗУ 100*5(10, 20?)мегабайт на клиента - задача для СЕТИ и дисков. Если сразу. Если не сразу, а по одной и по требованию, то значительно проще.

Если фотки будут ридонли, то хранить их в БД большого смысла нет, ИМХО. Достаточно хранить имена файлов и, возможно, миниатюры. По крайней мере в эту сторону стОит подумать.

MS SQL начиная с версии 2008, тип FILESTREAM

>Разрабатывается СУБД для хранения большого числа фотографий.

Так какую СУБД Ви разрабатываете?

> Главная задача СУБД - просмотр фотографий.

Не бывает таких задач у СУБД. Вы что, туда фотокамеру приделаете или распознавание прикрутите?

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

да любая оспади....

Значит, меняться не будут, только добавление. А что, в ФБ фотографии уже загружены и возникли сомнения?

Вот здесь основная проблема. Как быстро будет выполняться выборка, не будет ли тормозить ?

С базой эта проблема ну никак не связана.
Даже если фотки будут лежать в файлах, а не в блобах, то их все равно придется тянуть по проводам на клиентскую машину.
а толщина проводов от субд не зависит

> [9] Медвешонок Порожок   (30.10.13 18:44)

Судя по задаче, мегаколичествами тянуть не придётся.

А что не так с удобством?
D:\Фото\Опоры\2013\Oct\10000-10999\10031\4.jpg

> [11] RWolf ©   (30.10.13 18:50)
> D:\Фото\Опоры\2013\Oct\10000-10999\10031\4.jpg

Тогда уж
D:\Фото\Опоры\10000-10999\10031\4.2013.10.jpg

Ну и в базе-таки удобнее выбирать/сортировать по разным критериям + всякая доп. инфа наверняка есть.

> Inovet ©   (30.10.13 19:17) [12]

Я нарисовал именно такой путь из расчёта, что проверяющий ходит(-ят) весь октябрь среди опор с фотоаппаратом, а потом сливает всё сфотографированное на винт. Копировать всё разом в 2013\Oct\ немного удобнее, чем переименовывать и раскидывать тысячи фоток по каталогам опор.

> [13] RWolf ©   (30.10.13 19:31)

Вот в том и дело, что заливать так удобнее, а смотреть по-другому. Можно, конечно, линков наворотить.

Проблема в том, что работать с сотнями тысяч файлов -
это проблема. Постоянно что-то случается. Например, может
куда-то деться целый каталог. Неясно, куда делся и когда
это случилось. Всё равно, что работаешь с кучей песка.
Песчинки постоянно пропадают. Вот и появилась идея
загрузить эти песчинки в ящик.
И как правильно заметил Inovet, есть ещё масса дополнительной
информации, которая будет загружена в БД.
Меня беспокоят три момента.
1. Не будет ли тормозить БД ? (сеть не будет)
2. Надёжность хранения.
3. Я пока остановился на FireBird,  т.к. хорошо его знаю.
Может, использовать что-то другое ?
Что скажете ?

Отвечу ещё на один из предыдущих вопросов.
Должны выполняться операторы select,
insert, update,delete. Т.е. должна быть возможность
добавлять новые записи с фото, удалять и
изменять существующие.

1. С чего бы ей (БД) тормозить. Есть же фотографии за все годы. Залить и убедиться. Только не постоянно тягать фото, а по мере надобности.
2. Ну так бэкап по-любому надо делать.

> [16] kudatsky   (30.10.13 23:49)

Это само собой. Есть некая разница в подходах между тем, насколько чаще надо делать что-то одно из этого в сравнение с другими.

Т.е. должна быть возможность
добавлять новые записи с фото, удалять и
изменять существующие.

Ты знаешь хоть одну субд которая этого не умеет?

Песчинки постоянно пропадают. Вот и появилась идея
загрузить эти песчинки в ящик.

а есть разница из какого ящика пропадают песчинки? тем более что ящик один и тот же.
если у тебя сегодня с диска файлы фоток пропадают, то завтра пропадет файл данных бд.