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

Question

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

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

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

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

Answer 1

Ограничение, пожалуй, самая важная вещь, упомянутая здесь. Типы данных существуют для обеспечения правильности ваших данных, поэтому вы уверены, что можете правильно ими манипулировать. Есть 2 способа сохранить дату. В виде даты или в виде строки "4 января 1893 года". Но строка также могла быть "4/1 1893", "1/4 1893" или подобной. Типы данных ограничивают это и определяют каноническую форму для даты.

Кроме того, тип данных имеет то преимущество, что он может проходить проверки. Строка «0 февраля 1975 года» принимается как строка, но не должна быть датой. Как насчет "30 февраля 1983 года"? Бедные базы данных, такие как MySQL, не выполняют эти проверки по умолчанию (хотя вы можете настроить MySQL для этого - и вам следует!).

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

Answer 2

Книга, которую я читал по теории баз данных, говорит мне, что стандарт SQL определяет концепцию домена . Например, высота и ширина могут быть двумя разными доменами. Хотя оба могут быть сохранены как числовые (10,2), столбцы высоты и ширины нельзя сравнивать без приведения. Это допускает ограничение типа, которое не связано с реализацией.

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

Answer 3

Вы должны заботиться о типах данных, когда речь идет о фильтрации (предложение WHERE) или сортировке (ORDER BY). Например, «200» является НИЖЕ, чем «3», если эти значения являются строками, и наоборот, когда они являются целыми числами.

Я считаю, что рано или поздно вам придется отсортировать или отфильтровать ваши данные ("200"> "3"?) Или использовать некоторые статистические функции в отчетах (например, sum () или (avg ()). хорошо с типом текста:)

Answer 4

СУБД обычно требуют определения типов столбцов, чтобы они могли быстро выполнять поиск. Если вы хотите получить 5-й столбец каждой строки в огромном наборе данных, определение столбцов - это огромная оптимизация.

Вместо сканирования каждой строки на наличие какой-либо формы разделителя для извлечения 5-го столбца (если ширина столбца не была фиксированной ширины), RDBM могут просто взять элемент с sizeOf (column1 - 4 (bytes)) + sizeOf (column5 ( байт)). Представьте себе, насколько быстрее это будет на столе, скажем, 10 000 000 строк.

В качестве альтернативы, если вы не хотите указывать типы каждого столбца, у вас есть два варианта, которые мне известны. Укажите каждый столбец как varchar (255) и решите, что вы хотите с ним делать в вызывающей программе. Или вы можете использовать другую систему базы данных, которая использует пары ключ-значение, такие как Redis .

Answer 5

база данных - это физическое хранилище, тип данных определяет это