#c# #sql-server-2008 #linq-to-sql #asp.net-mvc-2 #identity-column
#c# #sql-server-2008 #linq-to-sql #asp.net-mvc-2 #идентификатор-столбец
Вопрос:
Обратите внимание, что когда я говорю «клиент», я имею в виду предприятия или организации, которые подписались на услугу.
Я создаю приложение для отслеживания ошибок. Я решил использовать мультитенантный подход как к экземпляру приложения, так и к базе данных.
Следовательно, существует одна огромная таблица ошибок с записями от всех клиентов. Идентификатор ошибки — это спецификация идентификации. Из-за этого, когда любой пользователь под управлением любого клиента добавляет ошибку, она увеличивается. Для клиента, который добавил всего 3 задачи, идентификаторы задач могут быть #45, # 49, # 53, потому что пользователи из других клиентов, возможно, добавили некоторые промежуточные!
Приемлемо ли это с точки зрения варианта использования?
Иногда клиенты могут использовать последний идентификатор ошибки в качестве приблизительного показателя количества ошибок. Но на самом деле это будет ОБЩЕЕ количество ошибок в системе. Или они будут просто удивлены, если их первая ошибка начнется с #51134!
С другой стороны, если у меня есть этот конкретный идентификатор «за кулисами», и я вычисляю «видимый» идентификатор для каждого клиента отдельно, они будут видеть числа по порядку. Но при передаче ссылочного идентификатора ошибки в качестве параметров в URL-адресах я не могу использовать видимый пользователем идентификатор, потому что он не уникален. Я не думаю, что комбинация ClientID — BugID будет элегантной. Я боюсь, что использование исходного значения спецификации идентификатора вызовет путаницу, потому что пользователь увидит один идентификатор в пользовательском интерфейсе и другой идентификатор в URL. И нет необходимости говорить, что разработчики попытаются использовать URL, изменив идентификатор, и увидят, что это не удастся.
Как я могу решить эту проблему? Я не хочу переходить к подходу с несколькими базами данных, поскольку я немного боюсь процесса обслуживания и обновления.
Комментарии:
1. ИМО, подход с несколькими базами данных был бы лучше. Вы можете использовать автоматизированные решения для обслуживания и обновлений. Для единой базы данных вам приходится намного больше беспокоиться в вашем приложении о разделении данных. Одна маленькая ошибка, и вы предоставляете пользователю данные других клиентов, что вряд ли будет приемлемо.
2. Популярный инструмент отслеживания проблем с открытым исходным кодом (redmine) использует последовательные идентификаторы для всех проектов в системе. Исходя из личного опыта и опыта клиентов, я могу сказать, что на самом деле это не проблема. Я определенно предпочитаю простые целые числа при поиске ошибки и не хотел бы увеличивать длину идентификатора проблемы, если это возможно.
3. @AlexDuggleby: согласен… Это сомнительная проблема, и мой ответ ниже является излишним, если это требование может быть устранено.
4. @AlexDuggleby: Увеличивает ли он также один и тот же идентификатор для всех клиентов? Насколько иное воздействие это окажет по сравнению с простым использованием во всех проектах одного и того же заказчика?
5. В Redmine нет понятия клиентов (AFAIK). Есть только проекты. Пользователи для каждого клиента имеют права на определенные проекты. Во всех проектах используется один и тот же начальный идентификатор, поэтому в основном да, начальный идентификатор одинаков для всех клиентов.
Ответ №1:
Я думаю, что здесь применим принцип наименьшего удивления: вам нужно быть последовательным во всем, что вы делаете. Если вы не можете изменить схему URL, то это просто оставляет непоследовательные идентификаторы в качестве единственного жизнеспособного решения. Лично я не вижу в этом проблемы, большинство средств отслеживания ошибок смогут генерировать отчеты о том, сколько ошибок было зарегистрировано за определенный период или сколько в конкретном проекте и т.д.
На слегка несвязанном примечании, на работе мы используем единую систему отслеживания ошибок для всех наших проектов. Система в целом имеет один инкрементный идентификатор для ошибок в любом проекте. У нас никогда не было проблемы.
Ответ №2:
Как общее эмпирическое правило, не показывайте свои суррогатные ключи (значения идентификаторов) своим пользователям, если вы вообще можете с этим справиться. Люди в конечном итоге хотят изменить что-то, о чем они знают, поэтому им не нужно знать значения первичного ключа…
Идея о создании идентификатора, используемого человеком, лучше всего решит вашу проблему, как вы упомянули, просто не используйте его как ключ в вашей системе. Используйте свои суррогатные ключи в качестве ключей. (Обычно есть способы обойти передачу ключей в строке URL …) Скорее, обработайте свой человеческий потребляемый ключ как поле отображения после его первоначальной генерации.
Рассмотрите возможность объединения аббревиатуры имени клиента или компании клиента, или части даты / времени или другого счетчика, который вы определяете с помощью отдельного запроса к контексту ( SELECT MAX(?) FROM q ) или их комбинации…
Удачи!
Ответ №3:
Один особый случай, который я хотел упомянуть: если это общедоступный веб-сайт, т. Е. общедоступная страница поддержки или аналогичный, где клиент сообщает вам номер обращения в службу поддержки по телефону (т. Е. Разрыв среды связи), тогда было бы разумно создать «интеллектуальный» идентификатор. Например, 5 чисел контрольная сумма. Тогда оператору (или системе) будет проще проверять номера неправильно прочитанных билетов.