Разрабатывается СУБД для хранения большого числа фотографий. Их количество может достичь 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)

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

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

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

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

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

Ну что же, вопрос достаточно понятен. Тем не менее, вы меня не успокоили. С нового года я начну эту работу, тогда всё станет ясно. Всем спасибо.

2kudatsky
Ты так и не ответил - что за выборки то?
Разница по времени между выборками



и



будет примерно равна времени копирования всех фото файлов одной опоры с диска (где фотки хранятся) на диск клиента (где смотреть будут). Эту разницу можно измерить секундомером, даже без заливки фоток в БД. При этом скорость первой выборки при 100 возвращаемых записях условно можно принять за ноль.

Запрос будет именно второй:
select ID_Foto,Name_Foto,Desc_Foto, BLOB_Field_Foto from Tab_Foto
where id_opor=:id
Цель запроса - просмотр фотографий пользователем на локальной машине.
На экране будет DBGrid со списком фотографий и DBImage для просмотра фото по очереди. Перемещение между фото - click или DBNavigator

я не понял, это все для локального места? или серв с фотками отдельно, а пользователь отдельно?

brother>Фотографии будут на сервере. Все пользователи на локальных машинах будут работать с одной базой данных. Пользователи с правами смогут пополнять БД новыми фото.

Думаю, я нашёл решение задачи. В БД будут храниться 2 копии фото. Одна так, как она создаётся фотоаппаратом, 4х3 тыс. пикселей. Вторая - в масштабе 1:4, т.е. 1000х750 пикселей. Именно она будет использована для просмотра. Занимать она будут несколько сотен килобайт и ни сеть, ни сервер её даже не заметят. А кому нужно фото высокого разрешения, сможет скачать его за несколько секунд.

> [25] kudatsky   (01.11.13 10:26)
> Думаю, я нашёл решение задачи. В БД будут храниться 2 копии фото.

> [25] kudatsky   (01.11.13 10:26)
> Вторая - в масштабе 1:4, т.е. 1000х750 пикселей

Для миниатюр и немньше хватит.

Пользователь нажал кнопку "Семейный фотоальбом участка", выбрал, к примеру, диапазон с 1000 по 1100 - надо ему просмотреть участок длинной километров 30. А лучше эти участки хранить в отдельной таблице. Пользователю в грид вывалилось 100 записей с опорами из таблицы Опоры. Он по ним бегает. Миниатюры на данном этапе нужны ли? И какая конкретно из всей истории на каждую опору? Вряд ли нужны. Если и нужны, то не 1000х750. А вот теперь пользователь решил полюбоваться конкретной опорой во всей красе с рождения и до сегодняшнего дня. Жмёт кнопку "Личный фотоальбом" или кликает в гриде, открывается ещё один грид, хотя вот тут лучше бы не грид, но не суть - открылось окно. Сверху информация об опоре, дальше миниатюры, но опять же не 1000х750, и рядом с каждой дата съёмки и, может, ещё что-то, где-нибудь, например, справа фото в полном разрешении. Кликнул по самой памятной - фото в ПОЛНОМ разрешении подгрузилось в это где-нибудь-справа. Насмотрелся, кликнул по следующей. Смахнул слезу умиления.

Можно ещё режим слайд-шоу сделать - "вся жизнь опоры № 123". Тогда загружать сразу за раз всю историю этой опры.

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

> [27] kudatsky   (01.11.13 11:56)

Значит, храни по 3 изображения. Разумно. Полное показывай по отдельной кнопке отдельным запросом.

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

3 метра...

> [30] brother ©   (05.11.13 18:15)
> 3 метра...

3 метра * 10 лет * 2 раза в год = 60 метров

>>Этих опор десятки тысяч. Каждую опору дважды в год фотографируют с 4-х сторон
>3 метра * 10 лет * 2 раза в год = 60 метров
Т.е. еще умножать на количество опор
50 гигов в год

Ещё с * на 4 стороны = 240 метров на опору. А за год пофиг пока влазит в БД.