Почему нас интересуют типы данных?
В частности, в системах управления реляционными базами данных, почему нам нужно знать тип данных столбца (скорее всего, атрибут объекта) во время создания?
Для меня типы данных выглядят как оптимизация, потому что одна точка данных может быть реализована любым количеством способов. Разве не лучше было бы назначать семантические роли и ограничения для точки данных, а затем внутренне исследовать и оптимизировать двигатель, какой тип данных лучше всего обслуживает пользователя?
Я подозреваю, что это тяжелый подъем и почему проще просто спросить пользователя, а не выполнять работу.
Как вы думаете? Куда мы направляемся? Это реалистичное ожидание? Или у меня есть ошибочное предположение?
Ответы
Ответ 1
Вы правы: присвоение типа данных столбцу является деталью реализации и не имеет ничего общего с теорией множеств или исчислением за движком базы данных. Как теоретическая модель, база данных должна быть "беспричинной" и способной хранить все, что мы бросаем на нее.
Но мы должны реализовать базу данных на реальном компьютере с реальными ограничениями. С практической точки зрения нецелесообразно заставить компьютер динамически пытаться выяснить, как лучше хранить данные.
Например, скажем, у вас есть таблица, в которой вы храните несколько миллионов целых чисел. Компьютер мог - правильно - понять, что он должен хранить каждую дату в качестве целостного значения. Но если вы однажды попытаетесь сохранить строку в этой таблице, должен ли механизм базы данных останавливать все, пока он не преобразует все данные в более общий формат строки?
К сожалению, указание типа данных является необходимым злом.
Ответ 2
Тип выражает требуемое ограничение на значения столбца.
Ответ 3
Ответ - это пространство для хранения и строки фиксированного размера.
Строки с фиксированным размером намного больше, намного быстрее для поиска, чем строки с переменной длиной, потому что вы можете искать непосредственно правильный байт, если знаете, какой номер и поле записи вы хотите.
Изменить: Сказав, что если вы используете правильную индексацию в таблицах базы данных, то строка с фиксированными размерами не так важна, как раньше.
Ответ 4
SQLite не заботится.
Другие RDBMS используют принципы, которые были разработаны в ранних 80, когда это было жизненно важно для производительности.
Oracle, например, не различает NULL
и пустую строку и сохраняет ее NUMBER
как набор значащих цифр.
Это вряд ли имеет смысл сегодня, но это были очень умные решения, когда разрабатывался Oracle.
В одной из созданных нами баз данных использовались неиндексированные значения, которые были сохранены как VARCHAR2
, динамически внедряемые в соответствующие типы данных в зависимости от нескольких условий.
Это была довольно особенная вещь: она использовалась для групповой загрузки пар ключ-значение в одном вызове базы данных с помощью коллекций.
Динамические операторы SQL
использовались для анализа данных и помещения их в соответствующие таблицы на основе имени ключа.
Все значения были загружены во временный столбец VARCHAR2
как есть, а затем преобразованы в NUMBER
и DATETIME
, которые будут помещены в их столбцы.
Ответ 5
Явные типы данных огромны для эффективности и хранения. Если они неявные, они должны быть "фигурированы" и, следовательно, несут скоростные издержки. Индексы также трудно реализовать.
Я бы заподозрил, хотя и не положительно, что наличие явных типов также в среднем несут меньше места для хранения. Для чисел, в частности, нет никакого сравнения между двоичным int и строкой цифр.
Ответ 6
Hm... Ваш вопрос путается.
Если я правильно ее понимаю, вы спрашиваете, почему мы указываем типы данных для столбцов таблицы и почему именно "движок" автоматически определяет, что необходимо для пользователя.
Типы данных действуют как ограничение - они обеспечивают целостность данных. У столбца int никогда не будет букв в нем, что хорошо. Тип данных автоматически не определяется для вас, вы указываете его при создании базы данных - почти всегда с использованием SQL.
Ответ 7
Если вы знаете, что какой-то элемент данных должен быть числовым целым числом, и вы намеренно выбираете NOT, чтобы позволить СУБД позаботиться об обеспечении этого, тогда ваша ответственность заключается в обеспечении всех видов вещей, таких как целостность данных (обеспечение того, чтобы в столбце не может быть введено значение "A", гарантируя, что в столбце не может быть введено значение 1,5), например, согласованность поведения системы (обеспечение того, что значение "01" считается равным значению "1", которое это не поведение, которое вы получаете от типа String),...
Типы заботятся обо всех этих вещах для вас.
Ответ 8
Я не уверен в истории datatypes в базах данных, но для меня имеет смысл знать тип данных поля.
Когда вы хотите сделать сумму некоторых полей, которые являются полностью varchar?
Если я знаю, что поле является целым числом, имеет смысл делать сумму, avg, max и т.д.
Ответ 9
Не все базы данных работают таким образом. SQLite упоминалось ранее, но гораздо более старый набор баз данных также делает это, многозначные базы данных.
Рассмотрим UniVerse (теперь свойство IBM). Он не выполняет никакой проверки данных и не требует указания того, какой тип он есть. Поиски по-прежнему (относительно) быстро, он занимает меньше места (из-за того, что он динамически хранит данные).
Вы можете описать, как могут выглядеть данные, используя метаданные (словарные элементы), но это ограничение того, как вы ограничиваете данные.
См. статью wikipedia на UniVerse
Ответ 10
Когда вы нажимаете полмиллиарда строк через 5 месяцев после перехода в прямом эфире, каждый байт подсчитывает (в нашей системе)
В дизайне базы данных не существует такой анти-шаблон, как "преждевременная оптимизация".
Дисковое пространство, конечно, дешево, но вы используете данные в памяти.
Ответ 11
Вы должны заботиться о типах данных, когда дело касается фильтрации (предложение WHERE) или сортировки (ORDER BY). Например, "200" LOWER, чем "3", если эти значения являются строками, а наоборот, когда они являются целыми числами.
Полагаю, рано или поздно вам придется сортировать или фильтровать ваши данные ( "200" > "3"?) или использовать некоторые агрегированные функции в отчетах (например, sum() или (avg()). хорошо с текстовым типом данных:)
Ответ 12
Книга, которую я читал по теории базы данных, говорит мне, что стандарт SQL определяет понятие домена. Например, высота и ширина могут быть двумя разными доменами. Хотя оба могут быть сохранены как числовые (10,2), столбец высоты и ширины нельзя сравнивать без кастинга. Это допускает ограничение типа, которое не связано с реализацией.
Мне нравится эта идея в целом, хотя, поскольку я никогда не видел ее реализованной, я не знаю, как она будет ее использовать. Я вижу, что это уменьшит вероятность ошибок при использовании значений, реализация которых будет одинаковой, когда их концептуальная область совершенно другая. Это могло бы также помочь людям сравнивать см и дюймы, например.
Ответ 13
RDBM обычно требуют определения типов столбцов, чтобы он мог быстро выполнять поиск. Если вы хотите получить 5-й столбец каждой строки в огромном наборе данных, определение столбцов - это огромная оптимизация.
Вместо сканирования каждой строки для какой-либо формы разделителя для получения 5-го столбца (если ширина столбца не была фиксированной шириной), RDBM могут просто взять элемент в sizeOf (column1 - 4 (bytes)) + sizeOf (column5 ( байт)). Представьте, насколько быстрее это будет на столе, скажем, 10 000 000 строк.
В качестве альтернативы, если вы не хотите указывать типы каждого столбца, у вас есть два варианта, о которых я знаю. Укажите каждый столбец как varchar (255) и решите, что вы хотите сделать с ним в вызывающей программе. Или вы можете использовать другую систему баз данных, которая использует пары ключ-значение, такие как Redis.
Ответ 14
Ограничение, возможно, самое важное, упомянутое здесь. Существуют типы данных для обеспечения правильности ваших данных, поэтому вы уверены, что можете правильно их обработать. Есть два способа сохранить дату. В типе даты или в виде строки "4 января 1893 года". Но строка могла также быть "4/1 1893", "1/4 1893" или аналогичной. Типы данных ограничивают это и определяют каноническую форму для даты.
Кроме того, тип данных имеет то преимущество, что он может проходить проверки. Строка "0 февраля 1975" принимается как строка, но не должна быть датой. Как насчет "30 февраля 1983 года"? Бедные базы данных, такие как MySQL, не выполняют эти проверки по умолчанию (хотя вы можете настроить MySQL на это - и вы должны!).
типы данных гарантируют согласованность ваших данных. Это одна из самых важных концепций, поскольку сохранение ваших данных разумно избавит вашу голову от безумия.
Ответ 15
База данных - это все о физической памяти, тип данных определяет это!!!