MySQL: длина полей.Это действительно имеет значение?

Question

Я работаю с некоторыми уровнями абстракции базы данных, и большинство из них используют такие атрибуты, как "String", который является VARCHAR 250 или INTEGER, который имеет длину 11 цифр.Но, например, у меня есть что-то, что будет длиной менее 250 символов.Должен ли я пойти и сделать это меньше?Это действительно имеет какое-то ценное значение?

Заранее спасибо!

Answer 1

INT длина ничего не делает. Все INT 4 байта. Номер, который вы можете установить, используется только для zerofill (и кто его использует!?).

Длина VARCHAR делает больше. Это максимальная длина поля. VARCHAR сохраняется так, что сохраняются только фактические данные, поэтому длина не имеет значения. В наши дни вы можете иметь больше VARCHAR, чем 255 байт (256 ^ 2-1). Разница заключается в байтах, которые используются для длины поля. VARCHAR (100) и VARCHAR (8) и VARCHAR (255) используют 1 байт для сохранения длины поля. VARCHAR (1000) использует 2.

Надеюсь, это поможет =)

редактировать
Я почти всегда делаю свои VARCHAR 250 длиной. Фактическая длина должна быть проверена в приложении в любом случае. Для больших полей я использую ТЕКСТ (и они хранятся по-разному, поэтому могут быть намного дольше).

редактировать
Я не знаю, насколько это актуально, но раньше мне это помогало (понимаю): http://help.scibit.com/Mascon/masconMySQL_Field_Types.html

Answer 2

Во-первых, помните, что база данных предназначена для хранения фактов и предназначена для защиты от неверных данных. Таким образом, причина, по которой вы не хотите, чтобы пользователь вводил 250 символов для имени, состоит в том, что пользователь будет помещать в него все виды данных, которые не являются именами. Они напишут все свое имя, размер нижнего белья, роман о том, что они сделали прошлым летом, и так далее. Таким образом, вы хотите стремиться к тому, чтобы данные были максимально точными. ошибка - предполагать, что приложение является единственным средством защиты от неверных данных. Вы хотите, чтобы пользователи сообщили вам, что у них возникла проблема с добавлением Войны в мире в данный столбец.

Таким образом, самый важный вопрос: «Какое наиболее подходящее значение для хранимых данных?» В идеале вы должны использовать int и проверочное ограничение, чтобы гарантировать, что значения имеют соответствующий диапазон (например, больше нуля, меньше миллиарда и т. д.). К сожалению, это один из самых больших недостатков MySQL: он не соблюдает ограничения проверки. Это просто означает, что вы должны реализовать эти проверки целостности в триггерах, что, по общему признанию, является более громоздким.

Будет ли разница между int (4 байта) существенно отличаться от tinyint (1 байт)? Очевидно, это зависит от объема данных. Если у вас будет не более 10 строк, ответ, очевидно, нет. Если у вас будет 10 миллиардов строк, ответ, очевидно, «Да». Впрочем, ИМО, это преждевременная оптимизация. Намного лучше сначала сосредоточиться на обеспечении правильности.

Для текста вам следует спросить, должны ли ваши данные поддерживать значения на китайском, японском или не ANSI (т. Е. Использовать nvarchar или varchar)? Представляет ли это значение код реального мира, такой как код валюты или код банка, который имеет конкретную спецификацию?

Answer 3

Не очень уверен в MySQL, но в MS SQL это имеет значение только для достаточно больших баз данных.Как правило, мне нравится использовать меньшие поля для а) экономии места (никогда не помешает практиковать хорошие привычки) и б) для подразумеваемой проверки (если вы знаете, что определенное поле никогда не должно содержать более 10 символов, зачем разрешать одиннадцать, пустьодин 250?).

Answer 4

Правильный размер поля служит для ограничения неверных данных, которые могут быть введены. Например, предположим, что у вас есть поле номера телефона.Если вы разрешите 250 символов, вы часто будете сталкиваться с такими вещами, как приведенные ниже, в поле телефона (пример не был взят случайным образом):

Call the good-looking blonde secretary instead.

Итак, первое ограничение длины является частью того, как мы применяем данныеправила целостности.Как таковой, это критично.

Во-вторых, на странице данных очень мало места, и хотя некоторые базы данных позволят вам создавать таблицы, в которых потенциальная запись длиннее ширины страницы данных, они часто не позволяют вам фактически превыситьэто при хранении данных.Это может привести к некоторым очень трудным для поиска ошибок, когда внезапно одна запись не может быть сохранена.Я не знаю о MySql и о том, делает ли он это, но я знаю, что SQL Server это делает, и очень трудно понять, что не так.Поэтому правильное значение данных может иметь решающее значение для предотвращения ошибок.

Answer 5

Я думаю, что Руди не прав, не все INT являются 4 байтами ... в MySQL у вас есть:

tinyint = 1 байт, smallint = 2 байта, mediumint = 3 байта, int = 4 байта, bigint= 8 байт.

Я думаю, что Руди относится к «отображению с», то есть к числу, которое вы ставите в скобках при создании столбца, например:

age INT (3)

Вы указываете СУБД только на ПОКАЗАТЬ не более 3-х чисел.

И VARCHAR - это (символьная строка переменной длины), так что если вы объявите, скажем, имя varchar (5000), и вы сохраняете имя типа «Mario», вы используете только 7 байтов (5 для данных и 2 для длины значения).