Почему мы заботимся о типах данных?

Question

В частности, в системах управления реляционными базами данных зачем нам знать тип данных столбца (более вероятно, атрибута объекта) во время создания?

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

Я подозреваю, что именно здесь находится тяжелая работа, и поэтому проще просто спросить пользователя, чем выполнять работу.

Что ты думаешь? Куда мы направляемся? Это реалистичное ожидание? Или у меня ошибочное предположение?

Answer 1

Тип выражает желаемое ограничение на значения столбца.

Answer 2

Ответ - пространство памяти и строки фиксированного размера.

Строки с фиксированным размером намного, НАМНОГО быстрее для поиска, чем строки с переменной длиной, потому что вы можете искать прямо к правильному байту, если вы знаете, какой номер записи и какое поле вы хотите.

Редактировать: Сказав, что, если вы используете правильную индексацию в таблицах базы данных, строки с фиксированным размером не так важны, как раньше.

Answer 3

SQLite не волнует.

Другое СУБД принципы использования, которые были разработаны в начале 80 , когда это было жизненно важно для производительности.

Например, Oracle не различает NULL и пустую строку и сохраняет свои NUMBER как наборы центесимальных цифр.

Это вряд ли имеет смысл сегодня, но это были очень умные решения, когда Oracle разрабатывался.

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

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

Динамические операторы SQL использовались для анализа данных и помещения их в соответствующие таблицы на основе имени ключа.

Все значения были загружены во временный столбец VARCHAR2 как есть, а затем преобразованы в NUMBER и DATETIME для помещения в их столбцы.

Answer 4

Явные типы данных огромны для эффективности и хранения. Если они неявные, их нужно «выяснить» и, следовательно, понести затраты на скорость. Индексы также трудно реализовать.

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

Answer 5

Хм ... Ваш вопрос сбивает с толку.

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

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

Answer 6

Вы правы: назначение типа данных для столбца является деталью реализации и не имеет ничего общего с теорией множеств или исчислением, лежащим в основе движка базы данных. Как теоретическая модель, база данных должна быть «без типа» и способна хранить все, что мы на нее бросаем.

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

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

К сожалению, указание типа данных является неизбежным злом.

Answer 7

Если вы знаете, что какой-то элемент данных должен быть числовым целым числом, и вы сознательно решили НЕ позволять СУБД позаботиться об этом, тогда ВАША ответственность за обеспечение всех видов вещей, таких как целостность данных в столбце нельзя вводить значение «A», что гарантирует невозможность ввода значения 1,5 в столбце), например согласованность поведения системы (гарантируя, что значение «01» считается равным значению «1», что это не то поведение, которое вы получаете от типа String), ...

Типы позаботятся обо всех подобных вещах для вас.

Answer 8

Когда вы запускаете полмиллиарда строк через 5 месяцев после запуска, каждый байт имеет значение (в нашей системе)

В разработке базы данных нет такого антишаблона, как "преждевременная оптимизация".

Дисковое пространство, конечно, дешево, но вы используете данные в памяти.

Answer 9

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

Рассмотрим UniVerse (теперь собственность IBM). Он не выполняет никакой проверки данных и не требует указания типа. Поиск по-прежнему (относительно) быстр, он занимает меньше места (из-за способа динамического хранения данных).

Вы можете описать, как могут выглядеть данные, используя метаданные (элементы словаря), но это предел того, как вы ограничиваете данные.

См. Статью в Википедии UniVerse

Answer 10

Я не уверен в истории типов данных в базах данных, но для меня имеет смысл знать тип данных поля.

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