Создание уникальных идентификаторов базы данных в коде

Question

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

Второе требование заключается в том, что тип базы данных для ключа должен быть int или char (x) ... поэтому нет уникального идентификатора или двоичного кода (16) или тому подобного.

Это неизменные требования.

Что было бы лучшим способом справиться с этим?

Одна из идей - это кодированные base64 GUID, похожие на «XSiZtdXcKU68QWe7N96Dig». Они легко создаются в коде и для меня приемлемы в URL-адресах, если это необходимо. Но будет ли это слишком дорого в отношении производительности (индексации, размера), имеющей все первичные и внешние ключи char (22)? Мне очень нравится эта идея.

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

Я думаю, что никакой стол не будет превышать 1.000.000 строк ..., вероятно, будет намного меньше.

Answer 1

Простой инкрементный int был бы самым простым способом обеспечения уникальности. Это будет делать база данных, если вы ее разрешите. Если вы установите для строки таблицы значение auto_increment, база данных сделает это автоматически.

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

Answer 2

Видя, что у вас есть приложение ASP.NET, вы можете сделать следующее (в надежде и предположении, что все пользователи должны идентифицировать себя, прежде чем использовать приложение!):

• Присвоить каждому пользователю уникальный «UserID» в ваша база данных (может быть INT или CHAR)
• Присвойте каждому пользователю «HighestSequentialID» (INT) в вашей базе данных
• Когда пользователь входит в систему, прочитайте эти значения из базы данных и сохраните их, например пользовательский принцип, или в cookie или что-то еще
• всякий раз, когда пользователь собирается вставить строку, создайте сегментированный идентификатор: (UserID) (порядковый номер пользователя) и сохраните его как «VARCHAR (20)» - например ваш UserID равен 15, и, следовательно, записи этого пользователя будут иметь уникальные идентификаторы «15.00001», «15.00002» и т. д.
• , когда пользователь выходит из системы (или в любое другое время), обновить свой новый, самый высокий используемый последовательный идентификатор в базе данных, так что в следующий раз, вы будете знать, что этот пользователь использовал последний

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

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

Marc

Answer 3

Вы могли бы таблица с именем "последовательности". Для каждой таблицы будет строка со счетчиком. Затем, когда вам нужно другое число, выберите его из таблицы счетчиков и увеличьте его. Поместите его в транзакцию, и у вас будет уникальность.

Однако это, конечно, будет страдать с точки зрения производительности.

Answer 4

Для таблицы ниже 1.000.000 строк, я бы не слишком страшно беспокоился о главном ключе (22). Конечно, идеальным решением для такой ситуации было бы для каждого объекта иметь что-то уникальное в этом отношении, которое вы могли бы использовать для ключа, даже если это многосекционный ключ. Следующим идеальным решением было бы изменение требований :)