Нужно ли вручную назначать идентификаторы сущности? Хорошая идея?

Question

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

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

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

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

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

PD: Знаете ли вы какие-либо документы о? -Entities и IDs-

---

ОБНОВЛЕНИЕ

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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