MySQL: хранение нескольких логических значений в одном столбце.Один tinyint (4) -vs- несколько tinyint (4) - PullRequest
Новая
       29

MySQL: хранение нескольких логических значений в одном столбце.Один tinyint (4) -vs- несколько tinyint (4)

3 голосов
/ 17 декабря 2011

Мне нужно хранить 5 логических значений в 1 таблице.Каждое значение может быть сохранено как tinyint (4).Итак, есть 5 крошечных (4).Я собираюсь поместить 5 логических значений в один tinyint (4).Я думаю, что все знают даже лучше, чем я, 5 бит могут быть сохранены в 1 байт без проблем :) Первое значение может быть сохранено как 0 (false) или 1 (true), второе как 0 (false) или 2 (true), третий - 0 или 4, четвертый - 0 или 8, пятый - 0 или 16. Итак, если мы храним сумму этих значений в tinyint (4), мы точно знаем 5 логических значений. 

    For example, stored 21 -> 16 + 4+1.
So, if 21 is stored, we know that:
    Fifth=true
    Fourth=false
    Third=true
    Second=false
    First=true.

Мой вопрос: имеет ли смысл хранить только 1 переменную?Мы выигрываем объем в ДБ (в байтах) и производительность (на 4 столбца меньше, но это всего 4 байта, тогда как вы фактически использовали varchar (1000) в той же таблице), но каждый раз нам приходится «извлекать» правильное логическое значение из «суммыmsgstr "используя функцию php, и это часто случается (скажем, когда пользователь нажимает кнопку).Имеет ли смысл хранить логические значения в виде суммы в 1 столбце или нет, поэтому у вас есть 7 столбцов вместо 11?

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

Спасибо.

Ответы [ 3 ]

6 голосов
/ 17 декабря 2011

Не делайте этого - если только значение не является единственным "непрозрачным" внешним типом данных , например, Enum of flags - если столбцы будет когда-либо использоваться в запросе или когда-либо будет использоваться вне указанного "непрозрачного" типа: используйте дискретные / отдельные поля. (правильного типа, как jmucchiello и МаркР отметил в своих ответах.)

Попытка «для производительности» здесь просто заставит вас ненавидеть базы данных - и эту, в частности, - когда вам придется «исправить» это или обойти некрасивую схему позже. (Если у вас есть проблема с производительностью, вы об этом узнаете ... и знаете достаточно, чтобы выполнить анализ производительности , прежде чем спрашивать.) Дональд Кнут был прав, когда указал, что 97% вещей просто не имеет значения. Так что сделайте это красиво и позвольте базе данных делать то, что чувствуете.

Удачного кодирования.

Если я звучу оживленно выше, это потому, что я пытаюсь помочь другим избежать тех же ошибок, которые я сделал натолкнулся на: -)

2 голосов
/ 17 декабря 2011

Нет, это не имеет смысла.

Либо сохраняйте каждый в своем собственном столбце, ИЛИ используйте специфический для MySQL тип SET, который внутренне использует битовые поля, но более удобочитаемый.

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

1 голос
/ 17 декабря 2011

Почему бы вам не использовать BIT Type и позволить MySQL беспокоиться об оптимизации пространства?

...