Использование указания длины для суррогатных ключей

Question

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

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

Нет никакой разницы между NUMBER (n) и NUMBER в том, что касается физической памяти или производительности, и, следовательно, нет причин указывать длину для столбца суррогатного ключа на основе NUMBER.Почему этот профессор считает, что использование одного NUMBER было бы «непрактичным»?

Answer 1

По моему опыту, большинство рабочих администраторов баз данных в реальной жизни, вероятно, будут делать то, что вы предложили, и объявить ключевые столбцы как NUMBER, а не NUMBER (n).

Стоит спросить профессора, что делает этот подход нецелесообразным по его или ее мнению.Есть несколько вариантов, о которых я могу подумать

Предполагая, что вы используете инструмент моделирования данных для разработки своей схемы, разумный инструмент гарантирует, что тип данных ключа будет таким же, как в таблице, гдеон определяется как первичный ключ и в дочерней таблице, где он является внешним ключом.Если вы укажете длину для первичного ключа, принуждение ключа к генерации внешних ключей без ограничений длины будет нецелесообразным.Конечно, в противовес этому можно просто объявить столбцы как первичного, так и внешнего ключа как NUMBER.

Администраторы баз данных, как правило, очень разборчивы (и я имею в виду это как комплимент).Им нравится, когда все организовано "просто так".Добавление спецификатора длины к полю, будь то NUMBER или VARCHAR2, служит неявным ограничением, гарантирующим, что неверные данные не будут сохранены.В идеале вы должны знать, когда вы разрабатываете таблицу, разумную верхнюю границу для количества строк, которые вы вставляете за время жизни таблицы (т.е. если ваша таблица PERSON содержит более 10 миллиардов строк, что-то, вероятно, будет серьезнонеправильно).Применение ограничений длины к числовым столбцам демонстрирует администратору базы данных, что вы провели такой анализ.

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

Answer 2

Оставив на свои собственные устройства, я бы объявил суррогатные первичные ключи как NUMBER (38) на оракуле, а не NUMBER.И, возможно, проверочное ограничение, чтобы сделать ключ> 0. В первую очередь служить в качестве документации для внешних систем о том, что они могут ожидать в столбце и что им нужно уметь обрабатывать.

Теоретически, при построенииПриложение, которое читает суррогатный первичный ключ, видит NUMBER означает, что нужно обработать полный диапазон с плавающей запятой числа , тогда как NUMBER (38) означает, что приложению необходимо обработать целое число до 38 цифр.

Если бы я работал в среде, где все внешние интерфейсы собирались использовать 32-разрядное целое число для суррогатных ключей, я бы определил его как число (10) с соответствующим проверочным ограничением.

Answer 3

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

Из этой темы о числе

число (n) является редактированием - ограничение числадо n цифр в длину.

, если вы храните число «55», оно занимает то же место в числе (2), что и число (38).

требуемая память = функция от фактически сохраненного числа.