Тип первичного ключа: int против long

Question

Я знаю, что некоторые магазины программного обеспечения были сожжены при использовании типа int для первичного ключа постоянного класса. Тем не менее, не все таблицы превышают 2 миллиарда. Фактически, большинство не делает.

Итак, вы, ребята, используете тип long только для тех классов, которые сопоставлены с потенциально большими таблицами ИЛИ для каждого постоянного класса просто для согласованности? Что такое отраслевой консенсус?

Я оставлю этот вопрос открытым некоторое время, чтобы вы могли поделиться с нами своими историями успеха / ужасов.

Answer 1

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

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

Это не означает, что Int - не лучший вариант для сценариев других людей, например, для обработки данных или сложных систем запросов. Просто избегайте рисков / выгод и их влияния на ваш конкретный проект.

Answer 2

Я не знаю про "сгорел". Нетрудно перейти от int к long, когда это необходимо. Преобразование является простым в SQL, а затем это просто поиск и замена в клиентском коде (или внесение изменений в свой уровень персистентности, а затем компиляция и просмотр того, что ломается.) Вы переходите от одного целочисленного типа к другому так что вам не нужно беспокоиться о тонких проблемах преобразования или усечения ..

Переход от поплавка к двойному будет намного сложнее.

Answer 3

Потому что Int всегда будет быстрее для выбора / сортировки.

Answer 4

Я использую Integer для своих суррогатных ключей, если мне не нужно, чтобы они были чем-то другим. Нет необходимости всегда использовать Long, если он вам не нужен.

(Я обычно использую JPA / Hibernate в своих проектах, работающих с базами данных Oracle 10g или MySQL 5.x.)