#java #database #integer #primary-key #long-integer
Вопрос:
В настоящее время первичные ключи в нашей системе состоят из 10 цифр, что чуть больше предела для целых чисел Java. Я хочу избежать любых проблем с обслуживанием в будущем, вызванных переполнением цифр в этих ключах, но в то же время я не хочу жертвовать большой производительностью системы для хранения бесконечно больших чисел, которые мне никогда не понадобятся.
Как вы справляетесь с управлением размером первичного ключа? Лучше ли мне придерживаться целых чисел Java для повышения производительности по сравнению с более длинными и увеличивать размер, когда это необходимо, или мне следует держать удар, использовать Java Long для большинства моих PK и никогда не беспокоиться о переполнении размера последовательности?
Комментарии:
1. Какие СУБД вы на самом деле используете? Реализация количества варьируется в зависимости от платформы.
Ответ №1:
Я всегда использовал длинные ключи (число(18,0) в базе данных), потому что они просто исключают возможность возникновения такой ситуации практически во всех ситуациях (кроме приложений в стиле экстремального накопления данных). Наличие одного и того же типа данных во всех таблицах для ключа означает, что вы можете совместно использовать это поле для всех объектов модели в родительском классе, а также иметь согласованный код для ваших SQL-геттеров и так далее.
Ответ №2:
Похоже, что ответ зависит от того, насколько вероятно, что вы переполните целые числа Java своими данными. И нет никакого способа узнать это, не имея представления о том, что представляют собой ваши данные.
Комментарии:
1. Честно говоря, это зависит от обстоятельств. У нас есть таблицы, в которых никогда не будет больше нескольких записей, и таблицы, которые, вероятно, станут очень большими. Я оговорю, что есть вероятность, что через несколько лет несколько столов могут подвергнуться такому риску.
Ответ №3:
Преимущество в производительности было бы незначительным, поэтому я бы посоветовал использовать длинные клавиши. Иметь дело с этим в будущем, скорее всего, будет серьезной проблемой.
Ответ №4:
Это баланс между стоимостью хранения и использованием длинных целых чисел и вероятностью переполнения 32-разрядного целого числа.
Учтите, что 32-разрядное целое число без знака хранит более 4 миллиардов значений. Если вы думаете, что в течение следующих 136 лет в этой таблице будет в среднем более 1 новой строки каждую секунду, то вам нужно использовать Длинную.
Ответ №5:
32-разрядные целые числа в java являются целыми числами со знаком, поэтому их всего 2 миллиарда. Если по какой-то причине ваша ПОСЛЕДОВАТЕЛЬНОСТЬ продолжает время от времени прыгать, то между вашими PKS будут некоторые промежутки.
Не помешает иметь длинный (помните, что проблема с Y2K возникла из-за того, что некоторые разработчики COBOL подумали, что они сохранят некоторые байты в датах ??) 🙂
Поэтому я всегда использую Длинные.