Почему мы заботимся о типах данных?
в частности, в системах управления реляционными базами данных, почему нам нужно знать тип данных столбца (более вероятно, атрибут объекта) во время создания?
для меня типы данных как оптимизация, потому что одна точка данных может быть реализован несколькими способами. Не лучше ли назначить семантические роли и ограничения точке данных, а затем заставить механизм внутренне изучить и оптимизировать, какой тип данных лучше всего служит пользователю?
I подозреваю, что здесь тяжелый подъем и почему проще просто спросить пользователя, а не делать работу.
Что вы думаете? Куда мы направляемся? Является ли это реалистичным ожиданием? Или у меня ошибочное предположение?
15 ответов
вы правы: назначение типа данных столбцу является детализацией реализации и не имеет ничего общего с теорией множеств или исчислением ядра СУБД. Как теоретическая модель, база данных должна быть "типичной" и способной хранить все, что мы бросаем на нее.
но мы должны реализовать базу данных на реальном компьютере с реальными ограничениями. С точки зрения производительности непрактично, чтобы компьютер динамически пытался выяснить, как лучше всего хранить данные.
например, предположим, у вас есть таблица, в которой вы храните несколько миллионов целых чисел. Компьютер мог-правильно-вычислить, что он должен хранить каждое данное как интегральное значение. Но если однажды вы вдруг попытаетесь сохранить строку в этой таблице, должен ли компонент database engine остановить все, пока он не преобразует все данные в более общий строковый формат?
к сожалению, указание типа данных является необходимым злом.
ответ-пространство для хранения и строки фиксированного размера.
строки фиксированного размера намного быстрее искать, чем строки переменной длины, потому что вы можете искать непосредственно к правильному байту, если знаете, какой номер записи и поле вы хотите.
Edit: сказав, что, если вы используете правильное индексирование в таблицах базы данных, фиксированные строки не так важны, как раньше.
SQLite не волнует.
другое СУБДиспользовать принципы, которые были разработаны в начале 80, когда это было жизненно важно для производительности.
Oracle, например, не различает NULL и пустая строка, и сохраняет ее NUMBER ' S как наборы столетних цифр.
это вряд ли имеет смысл сегодня, но это были очень умные решения, когда Oracle была развитый.
в одной из баз данных, которые я разработал, хотя, неиндексированные значения были использованы, которые были сохранены как VARCHAR2, динамически кастуемые в соответствующие типы данных в зависимости от нескольких условий.
это была совершенно особая вещь: она использовалась для массовой загрузки пар ключ-значение в одном вызове базы данных с использованием коллекций.
динамический SQL операторы использовались для анализа данных и их размещения в соответствующих таблицах на основе ключа имя.
все значения были загружены во временное VARCHAR2 столбец как есть, а затем преобразуется в NUMBERи DATETIME ' ы должны быть помещены в свои колонки.
явные типы данных огромны для эффективности и хранения. Если они неявны, они должны быть "вычислены" и, следовательно, нести расходы на скорость. Индексы также будет трудно реализовать.
Я бы заподозрил, хотя и не положительно, что наличие явных типов также в среднем требует меньше места для хранения. Для чисел, особенно, нет сравнения между двоичным int и строкой цифровых символов.
тю... Твой вопрос сбивает с толку.
Если я правильно понимаю, вы спрашиваете, почему мы указываем типы данных для столбцов таблицы и почему "движок" автоматически определяет, что нужно пользователю.
типы данных действуют как ограничение-они защищают целостность данных. В столбце int никогда не будет букв, что хорошо. Тип данных не определяется автоматически для вас, вы указываете его при создании база данных-почти всегда использует SQL.
Если вы знаете, что какой-то элемент данных должен быть числовым целым числом, и вы сознательно решили не позволять СУБД заботиться об этом, то вы несете ответственность за обеспечение всех видов вещей, таких как целостность данных (гарантируя, что значение "A" не может быть введено в столбец, гарантируя, что значение 1.5 не может быть введено в столбец), например, согласованность поведения системы (гарантируя, что значение " 01 "считается равным значению "1", это не твое поведение. получить из типа String),...
типы заботятся обо всех этих вещах для вас.
Я не уверен в истории типов данных в базах данных, но для меня имеет смысл знать тип данных поля.
когда вы хотите сделать сумму некоторых полей, которые полностью тип varchar? Если я знаю, что поле является целым числом,имеет смысл сделать сумму, avg, max и т. д.
Не все базы данных работают. SQLite упоминался ранее, но гораздо более старый набор баз данных также делает это, многозначные базы данных.
рассмотрим UniVerse (теперь свойство IBM). Он не выполняет проверку данных и не требует указания типа данных. Поиск по-прежнему (относительно) быстрый, он занимает меньше места (из-за того, как он хранит данные динамически).
вы можете описать, как могут выглядеть данные, используя метаданные (словарь items), но это предел того, как вы ограничиваете данные.
см. статью Википедии на Вселенной
когда вы нажимаете полмиллиарда строк через 5 месяцев после go live, каждый байт считается (в нашей системе)
в дизайне базы данных нет такого анти-шаблона, как "преждевременная оптимизация".
дисковое пространство дешево, конечно, но вы используете данные в памяти.
вы должны заботиться о типах данных, когда дело доходит до фильтрации (предложение WHERE) или сортировки (ORDER BY). Например, "200" ниже, чем "3", если эти значения являются строками, и наоборот, когда они являются целыми числами.
Я считаю, что рано или поздно вам придется сортировать или фильтровать ваши данные ("200" > "3" ?) или использовать некоторые агрегатные функции в отчетах (например, sum () или (avg ()). До тех пор Вы хороши с text datatype:)
книга, которую я читал по теории баз данных, говорит мне, что стандарт SQL определяет концепцию домен. Например, высота и ширина могут быть двумя разными доменами. Хотя оба могут храниться как числовые(10,2), столбец высоты и ширины нельзя сравнивать без приведения. Это позволяет использовать ограничение "тип", которое не связано с реализацией.
Мне нравится эта идея в целом, хотя, поскольку я никогда не видел ее реализации, я не знаю, что это хотелось бы его использовать. Я вижу, что это уменьшит вероятность ошибок при использовании значений, реализация которых будет одинаковой, когда их концептуальная область совершенно различна. Она также может помочь удержать людей от сравнения см и дюймы, например.
СУБД обычно требуют определения типов столбцов, чтобы он мог быстро выполнять поиск. Если вы хотите получить 5-й столбец каждой строки в огромном наборе данных, определение столбцов-огромная оптимизация.
вместо сканирования каждой строки для некоторой формы разделителя для извлечения 5-го столбца(если ширина столбца не была фиксированной шириной), СУБД может просто взять элемент в sizeOf(column1 - 4(байты)) + sizeOf(column5 (байты)). Представьте, насколько быстрее это было бы на столе сказать 10,000,000 строк.
кроме того, если вы не хотите указывать типы каждого столбца, у вас есть два варианта, о которых я знаю. Укажите в каждом столбце как varchar(255) и решите, что вы хотите сделать с ним в вызывающей программе. Или вы можете использовать другую систему баз данных, которая использует пары ключ-значение, такие как Рэдис.
ограничение, пожалуй, самое важное, что здесь упоминается. Типы данных существуют для обеспечения правильности ваших данных, поэтому вы уверены, что можете правильно управлять ими. Есть 2 способа сохранить дату. В виде даты или в виде строки "4 января 1893 года". Но строка также могла быть "4/1 1893", "1/4 1893" или аналогичной. Типы данных ограничивают это и определяют каноническую форму для даты.
кроме того, тип данных имеет то преимущество, что он может пройти проверку. Строка "0 февраля 1975 года" принимается в качестве строки, но не должна быть датой. Как насчет "30 февраля 1983 года"? Плохие базы данных, такие как MySQL, не делают эти проверки по умолчанию (хотя вы можете настроить MySQL для этого-и вы должны!).
типы данных обеспечат согласованность ваших данных. Это одна из самых важных концепций, поскольку сохранение ваших данных в здравом уме избавит вашу голову от безумия.