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

Question

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

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

Спасибо.

Answer 1

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

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

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

Answer 2

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

Если будет много ручного sql doen с db, то при наличии ключа, содержащего UUID из отдельных полей, воняет, когда вам нужно сделать вставку, и для него нет значения по умолчанию для db. Это также проблема с символами.

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

Answer 3

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

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

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

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