Правильно ли назначать идентификаторы сущности вручную?

Question

Мы разрабатываем систему для замены старого приложения наших клиентов.

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

Мы считаем, что лучшее решение - это просто позволить пользователю назначать идентификаторы сущностей вручную при создании сущности; мы предложим ему следующий доступный идентификатор, и пользователь сможет изменить его, если захочет. обновления не допускаются! (Muahahaha)

Мы будем рады услышать ваши мысли о. Плюсы / минусы

Заранее спасибо:)

PD: Вы знаете какую-либо документацию? -Сущности и идентификаторы-

---

ОБНОВЛЕНИЕ

• Мы думаем, что должны быть случаи, когда это применимо, а что нет. так что ...
• Кроме того, существуют случаи, когда клиент буквально хочет, чтобы у данного объекта был идентификатор, который они приносят. внутренние коды организации, я думаю.

Answer 1

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

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

Вместо этого у вас должен быть обычный идентификатор сущности некоторого типа (int, guid и т. Д.), Который система назначает и использует для ссылок на все зависимые объекты. Затем имейте некоторый «внешний» идентификатор, в который пользователь может поместить свой собственный идентификатор.

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

Answer 2

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

Answer 3

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

Я видел похожий случайпри работе с розничными продавцами есть идентификатор и SKU продукта, сам sku может быть идентификатором, который позволит нам создать хороший дизайн, который у нас есть.