Александр, дело в том что все люди находятся в единой базе и проследить их связь с той или иной организации можно только после того как данный человек будет принят на работу, т.е. появиться запись в отдельной таблице, которая свяжет вместе user_id и position_id.
При добавлении нового сотрудника менеджер должен иметь возможность ввести ФИО и потом ему будет выведен наиболее подходящий человек из общей базы, однако с одинаковыми ФИО может быть несколько человек. Т.е. менеджер будет иметь фактически доступ к личным данным нескольких человек, сможет их посмотреть, чего хотелось бы избежать, хотелось бы дать менеджеру доступ только к одному конкретному человеку и никаких шагов влево-вправо.
Вот у меня пока непонимание как обеспечить данное ограничение.
Если расследовать случаи "лазанья по базе" постфактум и если бы у меня был некий уникальный идентификатор пользователя типа номера паспорта или идентификационного кода, то можно было бы сделать чтобы при приеме на работу менеджер для поиска использовал данный код и по нему однозначно находился бы один уникальный человек. А дальше уже можно было бы дописать логику, которая будет отслеживать по статистике запросов в базу что менеджер производил поиск номеров, которые ему не нужны были, т.е. эти люди не были приняты на работу и таким образом понимать что менеджер злоупотребляет доступом к базе.
Насколько я понимаю, в некоторых банках это все работает подобным образом, т.к. работники банка имеют возможность посмотреть информацию по разным пользователям (не только тем, с которыми они работают), но опасаются это делать, т.к. потом служба безопасности задает им вопросы относительно того зачем им была нужна информация по тем или иным пользователям если они их не обслуживают.
Александр, проблема как раз в том случае когда пользователя нужно принять на работу и он пока не числиться в той организации. Т.е. он пока есть в общей базе пользователей, но нет никаких привязок к данной организации.
acex101, это я утрировал ситуацию. На самом деле я больше стараюсь обойти ситуацию когда что-то пошло не так и не всегда проблема лежит на поверхности как то пропадание питания. Могут быть опять таки проблемы с битыми данными после сотен тысяч перезаписей ячеек. И это желательно не просто постараться обойти размазыванием этого кол-ва по максимально возможному кол-ву ячеек чтобы уменьшить нагрузку на каждую из них, но и выявить эту проблему максимально быстро и дать возможность принять какие-то меры (либо пометить ячейку наподобии bad секторов винчестера, либо еще что-то).
Потому мне и хотелось понять как сделать "правильно".
Одна из проблем на фирмах, занимающихся разработкой это когда программисты тыкают пальцами на электронщиков что это аппаратная проблема если что-то пошло не так (а не всегда в реальности можно понять что именно пошло не так если это не массовые отказы), а электронщики в свою очередь пинают на кривой код программистов.
Я считаю что нужно как программно так и аппаратно по максимуму постараться обеспечить надежность устройства.
Дмитрий Александров, добавление crc8 особо данные не увеличит, так что думаю это будет нормально.
Хорошая идея насчет того чтобы добавить контрольные суммы к каждой структуре (изначально я думал постранично добавлять).
Также подумаю насчет того как реализовать copy-on-write алгоритм чтобы оставлять в памяти хотя бы одну копию предыдущих данных.
Странно, вроде бы писал ответ Вам, но он исчез из сообщений. На всякий случай продублирую. Фокс Йовович, соединение с сервером не постоянно, в случае если девайс переходит в оффлайн, то он должен продолжить полноценно функционировать.
В девайсе будет присутствовать схема бесперебойного питания на случай пропадания основного питания, но, насколько я понял из разной информации (на своем опыте пока не сталкивался), информация может "биться" и при нормальном питании. Хотелось бы избежать подобной ситуации.
Я думал по поводу журналирования как делается в СУБД, однако боюсь что здесь может получиться ситуация что проблемы скорее начнутся из-за потенциальных багов в самой программы (ввиду возросшей сложности алгоритма).
Потому пытаюсь искать нечто оптимальное с точки зрения надежность/сложность.
Насчет сквозной контрольной суммы, проверки при старте это интересно, попробую подумать какую избыточность мне добавить в данные чтобы при старте была возможность восстановить данные.
Adamos, я не стараюсь высосать из пальца проблему. Мне просто хочется понять как принято правильно обрабатывать подобные ситуации чтобы и для пользователя оно было удобно потом и в системе не возникало каких-либо проблем (к сожалению, пока не хватает опыта чтобы наперед чувствовать всякие "подводные камни").
Adamos, это система контроля доступа, однако кроме функционала обычного СКУД (карточка, расписание, события) она содержит еще и различную информацию о пользователях, их должностях, отслеживает смены этих должностей и соответственно вносятся изменения в права доступа.
Информация у меня не совсем текстовая, потому мерджи у меня не особо применимы.
Макс, спасибо! Я пока не сильно понимаю для себя как реализовать подобную блокировку. Я изначально не уточнил все моменты - у меня frontend на angular и с бэкендом общается по REST.
В таком случае наверное проблематично будет блокировать данные, потому что да я знаю что пользователь запросил данные, но страничка у него может быть открыта бесконечно долго и ничего на ней не происходить. Я не могу держать данные блокированными все это время для других пользователей.
Ну хотя если другим пользователям выводить уведомление и разрешить принудительное редактирование..то возможно.
Я думал блокировать данные от момента когда user2 нажал сохранить и данные поступили на сервер, до момента когда данные полностью "разойдутся" по системе и установиться флаг что данные в порядке.
При этом я разве что могу пользователю user1 вывести сообщение когда тот также нажмет сохранить и я увижу на сервере что пришли новые данные а старые еще "не в порядке".
Ну либо периодически перезагружать актуальные данные с сервера увеличивая нагрузку на него.
res2001, спасибо! По всей видимости для начала реализую некую блокировку данных. А потом буду смотреть в сторону хранения версий, чтобы лучше понимать кто что менял.
Adamos, спасибо! Я думал по поводу хранения обеих версий. Пока останавливает то, что я в данный момент еще пока не сильно могу понять какое кол-во данных у меня будет, а хранение всех версий автоматически увеличит это кол-во данных.
mayton2019, спасибо за совет.
Но в данный момент меня беспокоит не столько вопрос как сохранить полученный бекап (я его могу скинуть на внешний носитель или отправить по сети периодически), а вопрос контроля работы самого сервера БД, чтобы вовремя иметь возможность что-то исправить.