Значение производительности гуидов РАСЧЕСКИ
Первый ответ почти правильный, но необходимо изменить метод получения, а НЕ поле - поле является закрытым (и не определяется автоматически); кроме того, геттеры имеют приоритет над полями, если оба видны. (Есть также способы сделать приватные поля видимыми, но если вы хотите получить геттер, нет особого смысла)
Так что геттер должен быть либо назван getWrapper() или помечены:
@JsonProperty("wrapper")
Если вы предпочитаете имя метода получения как есть.
1 ответ
Я бы предположил, что вы не видите преимущества порядка, потому что целевая таблица не имеет ПК. Так что' s накладные расходы на конверсию, которые вы видите. ЕСЛИ у него есть PK, 585k строк все равно должны быть отсортированы при вставке. Как SQL узнает, что он частично отсортирован?
Теперь, если это было вставлено 5850 x 100 строк, вы можете увидеть некоторые преимущества, потому что новые строки будут идти «в конце», а не «посередине», что сокращает разбиение страниц и накладные расходы.
Я бы пошел дальше и сказал, что статья датирована 2002 годом и предназначена для SQL 2000, и ее превзошла реальная жизнь.
В SQL Server 2005 у нас есть SEQUENTIAL GUID, чтобы разрешить строго монотонные GUID. для решения некоторых вопросов. Идентификатор GUID в качестве PK также был использован здесь: недавний пример: INT vs Уникальный идентификатор для поля ID в базе данных со сторонними ссылками.
Если ORM диктует GUID как PK, а не естественный ключ или стандартный суррогатный ключ на основе int, это серьезное ограничение ORM.