Технически вы определяете не длину, а точность и масштаб.
Одно и то же числовое значение (например, 100, 4.3) принимает одно и то же внутреннее значение независимо от точности и масштаба, определяющих столбец.
Максимальное значение, которое может содержать столбец, определяется ОБА точностью и масштабом. То есть вы можете сохранить значение 100 в столбце NUMBER (3,0), но не в столбце NUMBER (3,1).
Как правило, если столбец не должен хранить десятичную дробь, масштаб должен быть равен нулю. Имейте в виду, что если вы попытаетесь сохранить 10.12 в NUMBER (3,0), он сохранит значение 10. Это не ошибка (потому что если бы это произошло, вам было бы трудно сохранить значение одной трети в что-нибудь). Если вы хотите, чтобы он выдавал ошибку, вы хотите разрешить более высокий масштаб и использовать ограничение, чтобы прекратить его использование.
Я также считаю, что вы должны попытаться использовать «разумную» точность. Если бы вы хранили тысячу значений каждую секунду в течение тысячи лет, вы бы все равно поместили это в 14 цифр. Если я вижу столбец NUMBER (14,0), то я знаю, что на моем экране или распечатке я должен разрешить отображение 14 числовых символов. Если я вижу только НОМЕР или НОМЕР (38,0), то мне на самом деле не дают никаких указаний, и я могу предположить 14 символов. И если они начнут вводить 16-значные номера кредитных карт, я буду неправ. Вот почему я предпочитаю не догадываться.
Также в PL / SQL у них есть тип данных PLS_INTEGER, который подходит до 2147483647. Если я вижу столбец NUMBER (9,0), я знаю, что могу вписать его в PLS_INTEGER. Вероятно, существуют аналогичные соображения для Java, .Net и т. Д., Когда они хотят выяснить, какой тип данных, масштаб и точность следует использовать при извлечении / отправке данных в базу данных.