Ну вот не могу согласиться с вашим советом в том, что он подходит всем.
И вот по каким причинам:
1. При нахождении файла фотографии в поле 953 размер записи читателя увеличивается на размер фотографии. Было 300 байт, станет 50 кбайт (а то и больше). Каждая корректировка записи читателя (в т.ч. процедуры выдачи/возврата/продления/посещения/блокировки/разблокировки) приводит к увеличению записи читателя на размер фотографии +/- размер добавленных/измененных данных (но ими по сравнению с 50 кбайт можно пренебречь). В итоге интенсивной работы с БД читателей при книговыдаче с течением времени скорость работы с БД может ощутимо замедлиться, а размер файла RDR.MST вырастет
на ПОРЯДКИ. Очень часто за 1-2 месяца файл БД разрастался до 2-3 Гб.
Конечно, можно выполнять реорганизации БД (удалять предыдущие состояния записей) но тогда теряется возможность (при необходимости) проследить изменения в тех или иных записях, если они были сделаны ошибочно (например в итоге неудачной глобальной корректировки или невнимательности сотрудника) или наоборот намеренно.
2. Дублировать информацию о файле фотографии и в поле 950 и в поле 953 - совершенно избыточно - это лишние действия для сотрудников, т.к. при необходимости изменить фото придется выполнять много дополнительных действий.
Можно вообще не иметь информации ни в одном из этих полей и выводить фото, например если его имя будет совпадать с идентификатором читателя (можно как с тем, который вводится в поле 30 так и с тем, который присвоен в информационной системе вуза). Единственное - при таком подходе не работает кнопка ФОТО в АРМ Книговыдача.
Но как правило это и не требуется, т.к. фото может выводится в формате просмотра (том который по умолчанию или том, который будет включен в список) или же в отдельном окне по ссылке:
Что касается технологии, то фотографии можно получать и отправлять непосредственно на сервер при помощи одной из программ. Например www.yawcam.com
ИРБИС может забирать файл из нужного места и переименовывать его так как хотите/нужно, например из произвольного имени файла в конкретной директории (файл д.б. один файл но с любым именем) в файл с заданным именем, например 90004433.jpg в директории по пути, указанному в 11-м параметре БД RDR. После копирования исходный файл м.б. без проблем автоматически удален. Все это можно сделать без привлечения программистов, всего лишь средствами пользовательского оперативного режима.
Пример фрагмента текста из operhint.pft
if a(v950) or a(v953) then
'ФОТО',/,
'Добавление файла фотографии',/,
''/#,
'3'/,
'ADD_953,991,foto_place.wss'/,
'Команда выполнена'/,
'',/#,
else fi,
(поле 953 у нас используется как транзитное)
У каждого может быть свой путь, но стремиться нужно к оптимальному решению, которое может быть отличным в том или ином случае, не забывая при этом о требованиях безопасности персональных данных, предъявляемым к ИСПДн.