Будет ли проблема с псевдоинкрементным номером для идентификатора ошибки?

Question

Обратите внимание, что когда я говорю "клиент", я имею в виду предприятия или организации, которые подписались на услугу.

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

Следовательно, существует одна огромная таблица ошибок с записями от всех клиентов. Идентификатор ошибки - это спецификация личности. Из-за этого, когда любой пользователь под любым клиентом добавляет ошибку, она увеличивается. Для клиента, который добавил только 3 задачи, идентификаторы задач могут быть # 45, # 49, # 53, потому что пользователи других клиентов могли добавить некоторые из них!

Это приемлемо с точки зрения варианта использования?

Иногда клиенты могут воспринимать последний идентификатор ошибки как приблизительный показатель количества ошибок. Но на самом деле это будут ВСЕГО ошибки в системе. Или они будут просто удивлены, если их первая ошибка начинается с # 51134!

С другой стороны, если у меня есть этот конкретный идентификатор "за кадром", и я рассчитываю "видимый" идентификатор для каждого клиента в отдельности, они будут видеть числа в порядке. Но при передаче ссылочного идентификатора ошибки в качестве параметров в URL я не могу использовать видимый пользователем идентификатор, потому что он не уникален. Я не думаю, что ClientID - BugID Combo будет элегантным. Я боюсь, что использование исходного значения спецификации идентификатора вызовет путаницу, поскольку пользователь увидит один идентификатор в пользовательском интерфейсе и другой идентификатор в URL-адресе. И нет необходимости говорить, что разработчики будут пытаться использовать URL-адрес, изменяя идентификатор и наблюдая за его ошибкой.

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

Answer 1

Я думаю, что здесь применяется принцип наименьшего удивления: вы должны быть последовательны в том, что вы делаете. Если вы не можете изменить схему URL, то это оставляет непоследовательные идентификаторы в качестве единственного жизнеспособного решения. Лично я не вижу проблемы с этим, большинство систем отслеживания ошибок смогут генерировать отчеты о том, сколько ошибок было сообщено за определенный период, или сколько в конкретном проекте и т. Д.

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

Answer 2

Я хотел бы упомянуть один особый случай: если это общедоступный веб-сайт, т. Е. Общедоступная страница поддержки или аналогичная, когда клиент дает вам номер заявки в службу поддержки по телефону (т. Е. Перерыв в средствах связи), то было бы разумнопостроить «интеллектуальный» идентификатор.Например 5 цифр + контрольная сумма.Тогда оператор (или система) может более легко проверить номера неправильно прочитанных билетов.

Answer 3

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

Идея создания идентификатора, потребляемого человеком, лучше всего решит вашу проблему, как вы упомянули, просто нене используйте его как ключ в вашей системе.Используйте ваши суррогатные ключи в качестве ключей.(Обычно существуют способы передачи ключей в строке URL-адреса ...) Скорее, обработайте ваш человеческий потребительский ключ как поле отображения после его первоначальной генерации.

Рассмотрите возможность объединения аббревиатуры имени клиента или аббревиатуры компании-клиента или части даты / времени или другого счетчика, который вы определяете с помощью отдельного запроса к контексту (SELECT MAX(?) FROM q) или комбинации этих ...

Удачи!