В чем разница, используя tinyint или smallint (если применимо), а не только int делать? Или ограничение поля char на минимальные символы?
Эти варианты влияют на производительность или просто выделенное пространство?
Насколько важно выбирать наименьший возможный тип данных при проектировании базы данных?
Ответ 1
В индексированном поле со значительно большой таблицей размер вашего поля может существенно повлиять на производительность. На неиндексированном поле его не так важно, что ему еще нужно записать дополнительные данные.
Тем не менее, время простоя большого стола может составлять несколько минут или даже несколько часов, поэтому не делайте их меньше, чем вы себе представляете.
Ответ 2
Да, это также влияет на производительность.
Если индексы больше, для чтения их с диска требуется больше времени, и меньше можно кэшировать в памяти.
Ответ 3
Я часто видел эти три недостатка конструкции схемы, вызывающие проблемы:
- Поле varchar (n) было создано с n, которое было достаточно большим для образца данных, который ввел разработчик, а не для глобальной совокупности: отлично в модульных тестах, тихих усечениях в реальном мире.
- Используется varchar (n), где данные являются фиксированными. Это маскирует ошибки данных.
- A char (n), используемый для данных переменной длины. Это обеспечивает повышение производительности (позволяя данным сидеть в строке в строке на диске, но весь код клиента (и различные сохраненные procs/views и т.д.) Должен справляться с проблемами заполнения пробелов (и часто они этого не делают). Пробел может быть трудно отследить, потому что пробелы не отображаются слишком хорошо, а различные библиотеки/SQL-клиенты подавляют их.
Я никогда не видел хорошо преднамеренного (т.е. не только используя varchar (255) для всех cols), но консервативный выбор неправильного размера данных вызывает значительные проблемы с производительностью. По значимости я имею в виду фактор 10. Я регулярно вижу недостатки алгоритмического дизайна (отсутствующие индексы, отправка слишком большого количества данных по кабелю и т.д.), Что приводит к значительно большему результату.
Ответ 4
Оба, в некоторых случаях. Но imo, это скорее вопрос дизайна, чем соображения производительности и хранения. Причина, по которой вы не делаете все varchar(...), заключается в том, что она не точно отражает, какие данные должны храниться там, и это снижает целостность данных и безопасность типов.