Должен ли я сканировать и хранить идентификационную карту клиента и отпечаток пальца в BLOB для каждой транзакции?

Question

У меня есть приложение ломбарда, написанное на isql 7.32.Теперь новый закон требует, чтобы идентификатор клиента и отпечаток пальца регистрировались на оригинальном распечатанном билете каждый раз при выполнении транзакции ссуды или покупки, и эти билеты должны храниться в течение 5 лет.

В среднем мойЛомбарды обрабатывают более 6000 транзакций в год, поэтому за 5 лет можно легко выполнить более 30 000 транзакций! .. Это подразумевает огромный рост потребления памяти, если бы я должен был хранить изображения для каждой транзакции, и хотел бы знать, будут ли запросы и обновления значительными.занять больше времени

Кроме того, я хотел бы представить, что эти изображения представляют собой типы данных BLOB (BYTE), в которых каждое изображение хранится извне из базы данных в отдельном файле, поэтому каталог, содержащий их, вырастет до десятков тысяч файлов,это проблема?

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

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

Насколько я понимаю, на экранах "Выполнение" ISQL при выполнении запроса к BLOB-объектам не обращаются во время запроса, а к ним обращаются, когда пользователи выбирают их просмотр с помощью команды Perform's View?

Как мне спроектировать эту таблицу для обеспечения производительности?

РЕДАКТИРОВАТЬ: Другой вопрос, который нужно задать: есть ли необходимость в регулярном доступе к этим изображениям? .. НЕТ! ..Причина, по которой закон требует, чтобы правоохранительные органы имели больше информации для идентификации кого-то, кто украл имущество и заложил или продал его ломбарду, поэтому в любом случае они собираются запросить предмет (ы), ихсвязанный печатный документ (ы), а также соответствующий им идентификационный номер и отпечаток пальца. Что правоохранительные органы обычно спрашивают у владельца ломбарда, есть ли какие-либо сообщения о похищенных предметах, соответствующих аналогичному описанию, в ломбарде, или они были, потому что в большинстве случаев преступник неизвестен.Таким образом, выполняется запрос по описанию элемента (ов), и любые транзакции, которые содержат аналогичные требуемые элементы, правоохранительные органы захотят увидеть элемент (ы) и просмотреть исходный печатный документ транзакции, чтобы узнать, кто это сделал!

Answer 1

IANAL

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

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

---

Существуют различные проблемы, с которыми вам придется иметь дело.

Хранение BLOB-объектов

• Стандартный движок Informix (SE) не поддерживает объекты BLTE или TEXT (или BLOB, или CLOB).
• Informix Dynamic Server (IDS) сохраняет BLOB-объекты BYTE или TEXT либо «IN TABLE» в тех же самых базах данных, что и основные данные таблицы, но на отдельных страницах из обычных данных в строках или в пространстве больших объектов. специально созданный для хранения капель. В любом случае обычные данные для строк содержат дескриптор большого двоичного объекта, который показывает, где в действительности хранится большой двоичный объект.
• IDS хранит «умные» BLOB и CLOB в «умных» BLOB-пространствах, специально созданных для хранения BLOB-объектов. Опять же, дескриптор сохраняется в строке вместе с обычными данными.
• Ни в коем случае IDS не хранит большие двоичные объекты в файловой системе. Они хранятся в дисковом пространстве, управляемом транзакциями, зарезервированным для СУБД.
• IDS имеет интерфейс виртуальных таблиц (VTI), который можно использовать для доступа к файлам из файловой системы, если вы того пожелаете.

Фактический объем данных зависит от разрешения изображений, которые необходимо сохранить. Хорошей новостью является то, что дисковое пространство в наши дни довольно дешевое. Предположим, вы сохраняете изображения высокого разрешения размером 3 МБ каждый. Если вам нужно хранить 30 000 таких файлов, вам нужно около 100 ГБ дискового пространства. Хотя вы, вероятно, все еще можете купить меньшие диски (я полагаю), вам не составит труда найти диски в нескольких сотнях гигабайт, доступных для использования. Таким образом, я не рассматриваю хранение как главную проблему. И объем не ставит ограничений рабочей нагрузки. Если бы это было 30 000 в день, то нам нужно было бы обсудить проблемы, но это, вероятно, не было бы огромной проблемой.

Пользовательский интерфейс

ISQL, вероятно, не является предпочтительным инструментом, если вам нужно иметь возможность отображать сканы. Возможно, вы сможете заставить систему работать нормально для ввода данных, и, возможно, личную информацию можно будет включить в отчет (тикеты) и т. Д. Тем не менее, это, вероятно, не будет тривиальным.

Я не разработчик пользовательского интерфейса; Я работаю с программами CLI и в недрах СУБД. Я не уверен, что посоветовать в качестве внешнего интерфейса. Вероятно, я бы посоветовал взглянуть на Genero (проданный IBM и разработанный FourJs ).

Дизайн стола

С точки зрения дизайна таблицы, я бы имел одну отдельную таблицу из существующих таблиц для хранения изображений. Он будет содержать столбец SERIAL для указания номера изображения, и вы добавите столбец номера изображения внешнего ключа в соответствующие существующие таблицы. Таблица изображений также будет содержать большой двоичный объект с изображением и, возможно, некоторые метаданные об изображении (дата и время, может быть, идентификатор клиента, может быть, идентификатор сканирующего устройства). Это позволяет гибко обрабатывать все, что говорят юридические люди, необходимо. Вы можете повторно использовать идентификационный номер, если вам не нужно каждый раз снимать изображение; Вы все еще можете хранить информацию, если вы делаете. Вы по-прежнему выиграете от наличия отдельной таблицы для хранения данных (за исключением, возможно, с точки зрения пользовательского интерфейса ISQL - но это становится еще одной причиной для беспокойства по поводу использования ISQL). Одним из преимуществ является то, что если вы не хотите видеть изображения, вы можете просто оставить таблицу изображений вне запроса; вы случайно не выберете изображения, если выполните запрос SELECT *.

Ведение записей с отметкой времени

Мне неясно, требует ли закон от владельцев ломбардов сохранения копии оригинала распечатанного билета на момент совершения операции или достаточно ли электронной копии, которая может быть восстановлена.Возможно, вам придется рассмотреть возможность отметки времени в записях - см. PublicTimeStamp.org , чтобы узнать об одном из возможных способов сделать это.Это дало бы вам достаточно простые средства для самостоятельной записи того, что электронный документ был создан в определенное время.

Answer 2

Фрэнк, почему бы тебе не проверить это? Возможно, у вас есть опыт, чтобы сделать это самостоятельно, или, если нет, это не должен быть слишком большой проект, чтобы заставить кого-то помочь вам, не тратя слишком много денег.

Вам просто нужен сценарий, чтобы взять один из рисунков (или такой, который будет похож, если у вас его еще нет) и вставить его в поле большого двоичного объекта для 10 000 (или сколько угодно вы хотите проверить) записей.

Что касается проектирования таблиц, вот мое предложение: вы хотите разделить вертикально, чтобы легче было разделить по горизонтали. Это означает, что поместите большой двоичный объект в таблицу отдельно (или с другими полями, которые только специфичны для изображения ... как, возможно, дата, когда он был взят) с идентификатором, связывающим его с другими данными. Затем очень часто вы можете сделать резервную копию того, что находится в этой таблице, а затем обрезать более старые записи. Все, что имеет значение, - это то, что вы можете восстановить эти данные, если это необходимо, если это замедляет работу системы, то нет причин оставлять ее там.

Answer 3

Я бы сохранял изображения в виде файлов на жестком диске и сохранял имя файла в базе данных. Единственным недостатком является то, что если вы используете что-то вроде Crystal Reports для отчетов, которые знают, как отображать изображения непосредственно из базы данных, вы не сможете использовать эту функцию.

Я предполагаю, что вам действительно не нужно делать никаких отчетов об этих изображениях, хотя ... вам просто нужно иметь возможность предоставить полиции снимок отпечатка пальца при необходимости. Это будет гораздо проще сделать, если вы просто посмотрите имя файла отпечатка пальца и отправите его по электронной почте в полицию. Будет больше работы, чтобы получить данные в формате BLOB. Не большая проблема, а просто еще одна причина не хранить в базе данных imo.

Так что, мне кажется, это не составляет никакого труда, если хранить их в базе данных как BLOB или просто сохранять их в виде файлов изображений и сохранять имя файла. Дайте мне знать, если я что-то упустил, и я постараюсь дать лучший ответ.