User1582

Пусть менеджер сам заводит этого человека для организации.
Система может сопоставить уникальную информацию типа ИНН, и связать человека с общей базой.
Т.о. менеджер не будет иметь "выбора" личностей из общего списка

P.S. Можете отмечать )

Обверните структуры в "пакеты". Длинна структуры у вас не меняется, изменяется только содержимое. Тогда делаете примерно такой пакет:
[МАРКЕР_НАЧАЛА_СТРУКТУРЫ][ДЛИННА_СТРУКТУРЫ][ДАННЫЕ_СТРУКТУРЫ][CRC-8_СТРУКТУРЫ][МАРКЕР_КОНЦА_СТРУКТУРЫ]

Изменяться у вас будет только [ДАННЫЕ_СТРУКТУРЫ] и [CRC-8_СТРУКТУРЫ].
Как результат сможете легко пробежать по всей памяти, найти все структуры, сравнить crc, обнаружить битые и решать что с этим делать т.к. сможете только предсказать что вот тут явно что то не так.
Как минус избыточный объем данных за счет маркеров, длинны и crc. Но это можно оптимизировать исходя из ваших реалий, скажем если структуры не особо длинные то [МАРКЕР_НАЧАЛА_СТРУКТУРЫ][ДЛИННА_СТРУКТУРЫ] можно объединить в 1 байт вместо 2х(2-3 или 4 бита отдать под маркер а остальное под длинну).

Это с ходу что в голову пришло.

А нужна ли вам вообще EEPROM при наличии коннекта к серверу?

У вас есть два варианта - решить проблему аппаратно, навесив конденсатор и сделав контроль внешнего питания.

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

Можно блокировать редактирование данных пока user1 эти данные редактирует, т.е. выводить оповещение для user2 что в данный момент данные редактируются и предложить продолжить редактирование несмотря ни на что.

1 - уведомить пользователя user1 о том что данные были изменены и попросить дождаться синхронизации данных, после этого по-новому подтянуть актуальные данные и повторить потом операцию редактирования.

Это тоже вариант

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

Может у кого-то есть подобный опыт как обеспечить более-менее надежность подобных систем?
Здесь вопрос даже не к raspberry, а вообщем к системам на базе Linux (и не только)

Как раз относится и к расберри. Флешки, какие бы они не были, ненадежны.
1) Для начала городите любое гарантированное питание.
2) На серверах неспроста используется ЕСС память, поэтому даже в случае сферического "хорошо" в вакуме ошибки имеют место быть.
3) Выносите БД на другое хранилище.

Для надежности в целом:
1) Используйте f2fs вместо ext3\4.
2) Переводите корневой \ раздел в режим только чтение
3) БД храните отдельно от системы. Подключенный по usb hdd\ssd. Смонтировать по сети из более нажедного источника.
4) Можно заморочиться с оверлееями. Условно каталог с БД кинуть в оверлей где верхний уровень будет в tmpfs а нижний на флешке. Запускать раз в N часов\сутки слияние из верхнего в нижний уровень.

Как надежное питание можно использовать powerbank или даже обычный бесперебойник. Плюсом последнего будет то что его можно будет подцепить к малине и смотреть сколько заряда, какое состояние и принимать меры если питание перешло на батарею. Т.е. в вашем случае к примеру как по пункту 4 запускать слияние.

1. зачем вам ssl в вашей песочнице, вы жгете такты процессора непонятно для чего.
2. выпустите свой сертификат и подписывайте свои сервисы.

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

как писать поддерживаемый код?

Если уж очень коротко, то соблюдать SOLID/GRASP. Мне понравился твит одного из авторов React Router:
https://twitter.com/mjackson/status/1171524189850701825

Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
For me, this is 95% of software development. Just figuring out *where* things belong.

Что гуглить, что учить?

Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

Может литературу какую почитать посоветуете?

Скажу за себя. Ни одной из этих известных книжек за свою жизнь не прочитал. Писал много говнокода дома, очень много. Удалял, переписывал. Смотрел код других людей, анализировал, пытался перенять то, что считал правильным.

Можно ли себя называть миддлом, если твой код говно?

Не пытайтесь себя оценить. В каждой компании свои понятия миддла. А если кто-то 35 лет на лиспе кодил, а потом прыгнет на Angular - кто он, джун или сеньор?
И, да, все мы в какой-то степени пишем говнокод. Если кто-то Вам доказывает, что он пишет супер чистый код - не слушайте.

И ответ на главный вопрос.

Как перестать говнокодить и принимать неверные архитектурные решения?

Это невозможно. Все проекты, которые чуток сложнее CRUD-ов, рано или поздно обрастают говнокодом. Никто не пишет идеальный код. Код должен работать и решать проблемы бизнеса.

Для удобства можете использовать Criteria API, по сути сможете собирать запросы довольно близко к SQL, но манипулируя своими сущностями и их свойствами, добавляя аргументы и условия сборки.

Примеры:
- LEFT JOIN: https://www.logicbig.com/tutorials/java-ee-tutoria...
- INNER JOIN: https://www.logicbig.com/tutorials/java-ee-tutoria...

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

ИМХО если хотите вытащить данные одним запросом - напишите один запрос. :-)
Если вам нужны не все данные из сущностей, а только часть колонок, то создаете сущность с нужными колонками (без @Table), и через Native Query ее делаете запрос.
Запрос будет один. :-)

Вроде все работает, все более менее оптимизировано, но мне все равно кажется, что мой код ужасен. ПРОСТО УЖАСЕН.

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

Практический опыт важнее теории. По крайней мере изучение архитектуры уже предполагает наличие опыта

Транзакция - это возможность объединить несколько ваших запросов в один, в пределах которых возможен откат состояния базы до ее начала, причем исключительно в пределах записываемых данных.

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

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

Еще есть момент, если вы изменили базу в пределах транзакции и до ее завершения делаете запрос, включающий эти данные - то если такой запрос сделать вне транзакции (соседняя сессия например) то ваших измененных данных он не увидит, а внутри транзакции - увидит.

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

Сама связность данных конечно подразумевает что нужен контроль целостности но оно не обязательно, вы можете заложить в коде возможность неполного заполнения данных об объекте и следить за порядком изменения этих данных. Например вы сначала добавляете запись в таблицу 'родители', с количеством детей 0, затем добавляете в таблицу 'дети' запись об их детях, т.е. вместо одной транзакции у вас независимые две, в любой момент структура верна но между записями информация о детях родителей неверная (родители есть а детей нет), это очень короткий момент и он точно не актуален если у вас всего один пользователь, пока он меняет информацию, никто другой не будет читать эти неверные данные.