Стратегия обновления сущности

Question

В моей команде ведутся дискуссии об обновлении данных сущностей и о том, как лучше всего к этому подойти.Это структура безопасности, поэтому вот некоторые ограничения и идеи.

1. каждая таблица в БД имеет PK, который является руководством, это необходимо для нашего решения по многоузловой кластеризации.Идея состоит в том, что мы не хотим раскрывать это на объекте клиенту через API, потому что он может делать две вещи:
   1. предоставить им больше информации, необходимой для их работы, и предоставить хакерам больше информации о системе.
   2. Кошмар службы поддержки заключается в том, что клиент каким-то образом жестко запрограммировал этот идентификатор, и если нам нужно изменить это, это повлияет на клиентов нашего ПК.

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

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

кажется, что в наши дни все просто используют PK в качестве идентификатора для объектов без проблем, не зная, как убедить нашу команду ветеранов из старых добрых времен программирования.

Другая проблема заключается в том, как поддерживать частичные обновления. Проблема в том, что у вас есть объект с 10 свойствами, 4 коллекциями и т. д.с комбинацией имя+область и укажите, какое свойство обновлять, вместо того, чтобы вытягивать поле изменения 1 всего объекта, отправить обратно на обновление.Я говорю «ленивая загрузка коллекций», но не уверен, имеет ли смысл частичное обновление.

мысли?

Спасибо!

Answer 1

Мой подход к структуре безопасности будет таким:

• Присвойте чему-либо в базе данных внутренний идентификатор (столбец идентификаторов, последовательность, независимо от того, что поддерживает ваша база данных).«собственный сгенерированный столбец идентификатора» на языке Hibernate).В конце концов, он вам понадобится, а его модернизация — это большая работа.

• Если вам нужно передать идентификатор пользователю, сгенерируйте случайное число, убедитесь, что оно еще не использовалось, подключите его к внутреннему идентификатору и затем передайте пользователю. Никогда выдайте внутренний идентификатор и никогда используйте идентификаторы, которые могут быть угаданы взломщиками.

Что касается частичных обновлений, они начинают иметь смысл только в том случае, если у вас много объектов с большим количеством атрибутов.По поводу 10 атрибутов я бы сказал "преждевременная оптимизация."

Answer 2

Используйте естественный ключ, если вам нужно предоставить идентификатор клиенту.Это не так просто реализовать, но это правильный путь.

Не могли бы вы предоставить более подробную информацию об этих частичных обновлениях?Я не понял.:/

Answer 3

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

Этот подход наиболее распространен во всех компаниях.UID не является Личные данные так что с юридической точки зрения у вас все в порядке, как и с точки зрения безопасности.