Почему мы заботимся о типах данных?
@Ryan: документация о препроцессорах немного мала
@Staale: добавление пользователя в контекст каждый раз, когда вызывается шаблон, DRY
Решение - использовать препроцессор
A : в ваших настройках добавьте
TEMPLATE_CONTEXT_PROCESSORS = (
'myapp.processor_file_name.user',
)
B : в myapp / processor_file_name.py вставьте
def user(request):
if hasattr(request, 'user'):
return {'user':request.user }
return {}
Теперь вы можете использовать функциональные возможности пользовательских объектов в своих шаблонах.
{{ user.get_full_name }}
15 ответов
Вы правы: присвоение типа данных столбцу является деталью реализации и ничего не дает иметь дело с теорией множеств или исчислением, лежащим в основе механизма базы данных. В качестве теоретической модели база данных должна быть «бестиповой» и способной хранить все, что мы ей добавляем.
Но мы должны реализовать базу данных на реальном компьютере с реальными ограничениями. С точки зрения производительности, непрактично, чтобы компьютер динамически пытался выяснить, как лучше всего хранить данные.
Например, предположим, что у вас есть таблица, в которой вы храните несколько миллионов целых чисел. Компьютер мог - правильно - вычислить, что он должен хранить каждую точку данных как целое значение. Но если однажды вы вдруг попытаетесь сохранить строку в этой таблице,
база данных - это физическое хранилище, тип данных определяет это !!!
RDBM обычно требуют определения типов столбцов, чтобы они могли быстро выполнять поиск. Если вы хотите получить 5-й столбец каждой строки в огромном наборе данных, определение столбцов - это огромная оптимизация.
Вместо сканирования каждой строки в поисках некоторой формы разделителя для получения 5-го столбца (если ширина столбца не была фиксированной width), RDBM могут просто взять элемент sizeOf (column1 - 4 (байты)) + sizeOf (column5 (bytes)). Представьте, насколько быстрее это было бы для таблицы из 10 000 000 строк.
В качестве альтернативы, если вы не хотите указывать типы каждого столбца, у вас есть два варианта, о которых я знаю. Укажите каждый столбец как varchar (255) и решите, что вы хотите делать с ним в вызывающей программе. Или вы можете использовать другую систему баз данных, которая использует пары ключ-значение, например Redis .
В книге, которую я читал по теории баз данных, говорится, что стандарт SQL определяет концепцию домен . Например, высота и ширина могут быть двумя разными доменами. Хотя оба могут быть сохранены как числовые (10,2), столбцы высоты и ширины нельзя сравнивать без преобразования типов. Это позволяет "тип" ограничение, не связанное с реализацией.
Мне в целом нравится эта идея, хотя, поскольку я никогда не видел ее реализованной, я не знаю, каково было бы ее использовать. Я вижу, что это уменьшило бы вероятность ошибок при использовании значений, реализация которых одинакова, когда их концептуальная область сильно отличается. Это также может помочь удержать людей, например, от сравнения сантиметров и дюймов.
Вы должны заботиться о типах данных, когда дело касается фильтрации (предложение WHERE) или сортировки (ORDER BY). Например, «200» МЕНЬШЕ, чем «3», если эти значения являются строками, и наоборот, если они являются целыми числами.
Я считаю, что рано или поздно вам придется сортировать или фильтровать свои данные («200»> «3»?) Или использовать некоторые агрегатные функции в отчетах (например, sum () или (avg ()). А пока вы хорошо с типом данных text :)
When you're pushing half a billion rows in 5 months after go live, every byte counts (in our system)
There is no such anti-pattern as "premature optimisation" in database design.
Disk space is cheap, of course, but you use the data in memory.
Не все базы данных работают таким образом. SQLite упоминался ранее, но гораздо более старый набор баз данных также делает это, многозначные базы данных.
Рассмотрим UniVerse (теперь свойство IBM). Он не выполняет никакой проверки данных и не требует, чтобы вы указали, какой это тип. Поиск по-прежнему (относительно) быстр, он занимает меньше места (из-за способа динамического хранения данных).
Вы можете описать, как данные могут выглядеть, используя метаданные (элементы словаря), но это предел о том, как вы ограничиваете данные.
См. статью в википедии о UniVerse
Если вы знаете, что какой-то элемент данных должен быть числовым целым числом, и вы сознательно решили НЕ позволять СУБД заботиться об этом, тогда это становится ВАШЕЙ обязанностью обеспечивать все виды вещей например, целостность данных (обеспечение того, чтобы в столбец нельзя было ввести значение 'A', обеспечение невозможности ввода значения 1,5 в столбец), например, согласованность поведения системы (обеспечение того, чтобы значение '01' считалось равным значение «1», которое отличается от поведения типа String), ...
Типы заботятся обо всем этом за вас.
Хм ... Ваш вопрос немного сбивает с толку.
Если я правильно понимаю, вы спрашиваете, почему мы указываем типы данных для столбцов таблицы, и почему "движок" автоматически определяет что необходимо пользователю.
Типы данных действуют как ограничение - они обеспечивают целостность данных. В столбце типа int никогда не будет букв, и это хорошо. Тип данных не определяется автоматически, вы указываете его при создании базы данных - почти всегда с использованием SQL.
Явные типы данных очень важны для эффективности и хранения. Если они неявные, их нужно «вычислить», и поэтому они несут затраты на скорость. Также было бы трудно реализовать индексы.
Я подозреваю, хотя и не уверен, что наличие явных типов также в среднем требует меньше места для хранения. В частности, для чисел нет сравнения между двоичным int и строкой цифровых символов.
SQLite наплевать.
Другие СУБД используют принципы, которые были разработаны в начале 80 , когда он был жизненно важен для производительности.
Oracle , например, не делает различий между NULL и пустой строкой и сохраняет свои НОМЕР как наборы сотенных цифр .
Сегодня это вряд ли имеет смысл, но это были очень умные решения, когда Oracle разрабатывался.
Однако в одной из разработанных мной баз данных использовались неиндексированные значения, которые хранились. как VARCHAR2 , динамически преобразованный в соответствующие типы данных в зависимости от нескольких условий.
Это была особенная вещь: она использовалась для массовой загрузки пар ключ-значение за один вызов базы данных с использованием коллекции.
Операторы динамического SQL использовались для анализа данных и помещения их в соответствующие таблицы на основе имени ключа.
Все значения были загружены во временный столбец VARCHAR2 как есть, а затем преобразованы в NUMBER и DATETIME для размещения в их столбцах.
Ответ - пространство для хранения и строки фиксированного размера.
Строки фиксированного размера намного, НАМНОГО быстрее для поиска, чем строки переменной длины, потому что вы можете искать непосредственно правильный байт, если вы знать, какой номер записи и поле вы хотите.
Изменить: Сказав, что, если вы используете правильную индексацию в таблицах базы данных, вещи фиксированного размера не так важны, как раньше.
Тип выражает желаемое ограничение на значения столбца.
Я не уверен в истории типов данных в базах данных, но для меня имеет смысл знать тип данных поля.
Когда вам нужно вычислить сумму некоторых поля, которые полностью являются varchar? Если я знаю, что поле является целым числом, имеет смысл вычислить сумму, среднее, максимальное и т. Д.
Ограничение, пожалуй, самое важное, о чем здесь упоминалось. Типы данных существуют для обеспечения правильности ваших данных, поэтому вы можете быть уверены, что сможете правильно ими управлять. Есть два способа сохранить дату. В виде даты или в виде строки «4 января 1893 года». Но строка также могла быть «4/1 1893», «1/4 1893» или аналогичным образом. Типы данных ограничивают это и определяют каноническую форму для даты.
Кроме того, тип данных имеет то преимущество, что он может подвергаться проверкам. Строка «0 февраля 1975 года» принимается как строка, но не как дата. Как насчет «30 февраля 1983 года»? Плохие базы данных, такие как MySQL, не выполняют эти проверки по умолчанию (хотя вы можете настроить MySQL для этого - и вы должны!).
типы данных обеспечат согласованность ваших данных. Это одна из самых важных концепций, поскольку сохранение данных в здравом уме убережет вашу голову от безумия.