Что произойдет когда значение поля integer достигнет максимума?
А если это первичный ключ и значение маскимально для этого типа данных, что произойдет?

При попытке присвоить полю типа int значение вылезающее за диапазон сервер выплюнет ошибку:

И что делать то  тогда?

А что, реально боишься, что значение ключа превысит 2^64?

Читать литературу.
У Вас действительно возникла такая проблема?

Нет. Это так интересно стало. Ведь есть базы где в день появляется несколько сотен записей и удаляется столько же.

2^64 ?? возможно я дезинформирован:
В InterBase есть следующие основные категории типов данных: символьные, целые, дробные (с плавающей точкой), время и дата.Начнем подробный разбор.

Название типа данных Размер в байтах Диапазон значений/Точность Дополнительно 
INTEGER 4 от -2147483648 до 2147483648 Целое знаковое 
SMALLINT 2 от -327678 до 32767 Целовое знаковое 
DECIMAL(precision,scale) Переменная длина. 2,4 или 8 байт Точность(precision) от 1 до 18 ( Точность - это максимальное количество цифр ). Количество(scale) цифр после десятичной точки от 1 до 18 Масштабируемое целое ( десятичное ) 
NUMERIC(precision,scale) Переменная длина. 2,4 или 8 байт Точность(precision) от 1 до 18 ( Точность - это максимальное количество цифр ). Количество(scale) цифр после десятичной точки от 1 до 18 Масштабируемое целое ( десятичное ) 
DOUBLE PRECISION 8 от 2.225x10-308 до 1.797x10308 Дробное 
FLOAT 4 от 1.175 x 10–38 до 3.402х1038 Дробное 
CHAR(n) n - символов от 1 до 32767 Строка фиксированной длины (набор символов фиксированной длины). Альтернативное название - CHARACTER. 
VARCHAR(n) n - символов от 1 до 32765 Строка переменной длины (набор символов переменной длины).Альтернативное название - CHARACTER VARYING, CHAR VARYING. 
DATE 8 От 1 Января 100 нашей эры to 29 Февраля 32768 нашей эры. Дата 
TIME 8 0:00 AM-23:59.9999 PM Время 
TIMESTAMP 8 От 1 Января 100 нашей эры to 29 Февраля 32768 нашей эры. Время и дата 
BLOB Переменная длина  Динамически расширяемый тип данных для хранения данных большого размера.Например, графики,текста,звука. 

Ну если у тебя количество записей в таблице перевалило за эти отведенные два с хвостиком миллиарда, и оптимизировать базу действительно некуда, то переведешь тип поля в BIGINT и возрадуешься 

BIGINT[(M)] [UNSIGNED] [ZEROFILL]

A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615. 

Девять секстиллионов записей осилишь (это еще если со знаком, а без знака так вообщее 18)?  (Если ты ответил да, то база данных ответит нет  )

Это сообщение отредактировал(а) smartov - 14.8.2007, 09:15

Лучше сразу перевести все первичные ключи в large integer?

Добавлено через 2 минуты и 1 секунду
в ibexpert нет этого типа данных?
Ты про interbase писал?
  
нужно что ли через sql изменять...

Добавлено через 5 минут и 14 секунд
Стоп а как мне тогда в приложении использовать эти числа delphi такие числа не осилит без всяких хитростей которых я не знаю :(

Какой large integer?

INTEGER - 4-байтовой целое. В диалекте 1 генераторы генерируют значения типа INTEGER. Вы можете хранить эти числа в BIGINT без преобразования.

BIGINT - 8-байтовое целое. В диалекте 3 генераторами генерируются числа типа BIGINT.

по понятнее можешь ?  
Генераторы то может и генерируют а вот поле тип данных то другой...

Ты же сам говоришь "первичные ключи". А их обычно генераторы и генерят

Добавлено через 2 минуты и 52 секунды
Если вдруг когда-то тебе не хватит 2^32 (INTEGER), преобразуешь его без проблем к BIGINT  и будешь работать дальше


Это вообще-то по сравнению с 2^32 ОЧЕНЬ мало, посчитай сам если не веришь, на сколько лет хватит integer'a

Вот сейчас попробывал изменить тип данных и облом!
Так как есть внешние ключи. Получается в одной таблице один тип данных  во второй другой.
Решение убрать связь,и зменить тип и снова сделать связь?

Попробуй так и сделать. Проблема конечно из=за связей. Сам INTEGER должен преобразовываться к BIGINT без проблем

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

А потом 15 лет хранишь в укромном месте этот скрипт, чтобы в критический момент достать его и использовать   

понятно спасибо!
А если сразу поставить bigint, на много возрастет размер базы данных?

Согласись, это зависит от того, сколько у тебя таких ключей, и сколько их относительно других полей. Так что попробуй, истина где-то там, на твоём компе.

Я думаю, размер не сильно возрастёт

Нет нужно тут разобраться!
В одной базе все ОК! даже внешние ключи переводит в bigint, в другой где как раз  ин нужно это такая ошибка вылазит:

Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
action cancelled by trigger (1) to preserve data integrity.
Cannot update index segment used by an Integrity Constraint.

деактивируй все триггеры и индексы и попробуй снова.

вообще как все происходит
1) при вставке вызываются триггеры before insert
2) триггер через GEN_ID(SOME_GEN, 1) получает новое значение генератора
3) пытается "положить" значение генератора в нужное поле 
new.id = gen_id(some_gen, 1)
4) если тип поля - int, а значение генератора уже "не вписывается" в int - будет выброшено исключение и текущая операция будет откачена.