Каков правильный размер для первичного ключа, сгенерированного последовательностью?

Question

В настоящее время первичные ключи в нашей системе имеют длину 10 цифр, чуть больше лимита для целых чисел Java. Я хочу избежать каких-либо проблем с обслуживанием в будущем, вызванных переполнением чисел в этих ключах, но в то же время я не хочу жертвовать большой производительностью системы, чтобы хранить бесконечно большие числа, которые мне никогда не понадобятся.

Как вы справляетесь с управлением размером первичного ключа? Мне лучше придерживаться целых чисел Java, чтобы повысить производительность по сравнению с большим Long, и увеличивать размер при необходимости, или я должен прикусить пулю, перейти на Java Long для большинства моих PK, и мне никогда не придется беспокоиться о переполнении размер последовательности?

Answer 1

Я всегда использовал длинные ключи (номер (18,0) в базе данных), потому что они просто исключают возможность возникновения такой ситуации практически во всех ситуациях (за исключением приложений в стиле экстремального хранения данных). Наличие одного и того же типа данных во всех таблицах для ключа означает, что вы можете использовать это поле для всех объектов вашей модели в родительском классе, а также иметь согласованный код для получателей SQL и т. Д.

Answer 2

Кажется, что ответ зависит от того, насколько велика вероятность переполнения целых чисел Java вашими данными И нет никакого способа узнать это без некоторого представления о том, что ваши данные.

Answer 3

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

Answer 4

32-битные целые числа в java являются целыми числами со знаком, поэтому всего 2 миллиарда. Если по какой-то причине ваша ПОСЛЕДОВАТЕЛЬНОСТЬ продолжает время от времени прыгать, то между вашими ПК будут пробелы.

Это не помешает иметь длинные (Помните, что проблема Y2K произошла, потому что некоторые разработчики на COBOL думали, что они сэкономят несколько байтов в датах ??): -)

Поэтому я всегда использую Long.

Answer 5

Это баланс между стоимостью хранения и использованием длинных целых чисел и вероятностью переполнения 32-разрядного целого числа.

Учтите, что 32-разрядное целое число без знака хранит более 4 миллиардов значений. Если вы думаете, что в течение следующих 136 лет вы будете усреднять более 1 новой строки каждую секунду в этой таблице, вам необходимо использовать Long.