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

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 метров на опору. А за год пофиг пока влазит в БД.