Наиболее эффективный тип данных для UUID в базе данных, помимо собственного UUID

Question

Какой тип данных был бы наиболее эффективным для хранения UUID / GUID в базах данных, которые не имеют собственного типа данных UUID / GUID?2 БИГИНТа?

И какой был бы наиболее эффективный код (предпочтительный C #) для преобразования в GUID и из него в этот тип?

Спасибо.

Answer 1

Трудно сказать, что было бы наиболее эффективным, не зная используемой вами базы данных.

Моим первым побуждением было бы использовать binary(16) колонна.

Что касается использования этого значения в C #, то System.Guid тип имеет конструктор , который принимает byte[] массив и метод ToByteArray() это возвращает массив байтов.

Answer 2

По моему опыту, UUID, разбитый на два целых числа, все равно будет более эффективным, чем использование поля char.Однако разные базы данных реагируют по-разному.Сопоставление и здесь могло бы иметь значение.При этом, как правило, во всех приложениях есть гораздо большие "грехи" производительности, и я не думаю, что это было бы важно в любом случае для многих приложений.Вам придется судить о себе, исходя из того, насколько загруженной будет эта часть вашего приложения?Вам нужен максимально быстрый запрос, возможно, с помощью UUID?Для вас 600нс против 400нс - большая разница во времени?

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

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

Answer 3

Глядя на Класс .NET guid, есть несколько способов инициализировать guid:

Guid (Int32, Int16, Int16, Байт, Байт, Байт, Байт, Байт, байт, байт, Байт, Байт) Guid (строка)

Хотя теоретически может быть более эффективно хранить целое число в базе данных (вы могли бы использовать сдвиг битов, чтобы действительно сохранить 4 32-разрядных целых числа..но вам пришлось бы вычислять это при загрузке и сохранении каждый раз.Кроме того, для этого потребовалось бы 4 поля в базе данных..Я бы предположил, что в конечном итоге это окажется менее эффективным.

Добавьте к этому невозможность чтения этого непосредственно в вашей базе данных для целей отладки / тестирования, и я бы сказал, что лучше всего хранить строку.Это всего лишь 32-символьное поле (36, если включить тире), и его очень легко преобразовать.идентификатор пользователя.toString() Построить строку() и новый идентификатор Guid(строковое значение);