MySQL: As Small As Possible

Рубрика: MySQL | 27 September 2007, 12:13 | Vadim Voituk

Do you know how to create minimal storage table field?
How to store single bit value in most optimized way?

Just do it:
[sql]

CREATE TABLE dummy (
  id int unsigned auto_increment primary key,
  ...
  bitField CHAR(0), # Only "" and NULL values
  ...
);

SELECT bitField="" AS checked, ISNULL(bitField) AS unchecked FROM dummy;

[/sql]

Комментариев: 19

19 Responses to “MySQL: As Small As Possible”

Комментарии:

  1. Скакунов Александр

    Афигеть. Сам придумал? Где-то юзаешь?

  2. vadim

    Придумал сам, но нигде не использую. Надо бы в категорию humor наверное :)

  3. Ziege

    I tested it with MySQL 5.0.17 and it doesn’t make any difference in size, if you use the posted version, TINYINT(1) or a BIT field.

    So your version ist the worst one, because of the additional ISNULL check…

  4. Chabster

    Minimal memory variable footprint is 1 byte. So you cant make it less without DBMS tricks. I mean when bitField column storage is located out of contained row and packed (8 rows are packed into 1 byte + 1 byte for NULL\NOT NULL info. 8 rows = 2 bytes is the best choice). But the overall effort to support this is too high.

  5. vadim

    Chabster, you are right, and i suppose that in the a internal database valve, each 1byte field value extends to integer type size (4 bytes) :)

  6. raveman

    niezłe, ciekawy kawałek kodu :) też pisze w swoim języku skoro reszta jest leniwa i tak robi :P

  7. ICE

    Нафига это извращение, юзай enum. Для хранения состяния вкл/выкл или для эмуляции бит. поля вполне подходит enum(0, 1)

  8. vadim

    Надо все-таки в категорию humor :)

  9. Скакунов Александр

    enum(0, 1)

    Решение плохо тем, что вводит путаницу, т.к. у енумов нумерация начинается с единицы. Получается:
    1 => ’0′
    2 => ’1′

    Вот и “проверяй какого полу твой сосед” после этого…

  10. ICE

    to Скакунов Александр
    Т.е. начинается с еденицы? При чём тут это, во всех запросах используй значины списка без каких либо перестановок. Если я ограничил ввод поля 0, 1 – значит везде будут использоваться эти значения. А что бы избежать путаницы, всегда вешаю на поле комментарий, типа (пример для пола): 0 – женский пол, 1 – мужской. И никакой путанницы.

  11. vadim

    Если к полю приходится писать комментарий – то это “душок” от которого нужно активно избавляться.

  12. ICE

    Хм, по вашему комментирование кода, в том числе и БД признак плохого тона? Занимательно….

  13. vadim

    Никто не говорит что комментирование кода – признак плохого тона.
    Признак плохого кода (и ещё чаще дизайна), это когда код не прозрачен для читающего -
    тобишь требует комментирования.
    И если код требует пространных комментариев – то это первый признак того, что скорее всего в нем встречаются и другие “запахи”.
    Прочитать об этом можно например в “Рефакторин” М.Фаулера (где-то в первых главах описываются основные “запахи” дурного кода)

    Касательно данного примера: если разработчику приходится лезть читать комментарии, чтоб понять семантику поля/значения-поля в БД, то явно что-то с этим полем не то.
    Или это поле называется нелогично, или для него выбран не тот тип данных.

  14. vadim

    (опять же по Вашему примеру)
    Вы же не пишете комментарии к полям login, password, name, surname, is_active?
    Почему нужно писать к полю gender?

  15. ICE

    Часто встречаются моменты, когда для описание какого либо поля удобно использовать числовое значение, например тот же пол (м/ж), либо если есть 3 статуса (вкл/ожидание/выкл). Для такой мелочи вводить отдельную таблицу для связи глупо, вводить аббревиатуры (m/f или enb/pend/dis) не удобно для таких ситуаций отлично подойдёт числовое обозначение состояния. Но вот какое число отвечает за какой статус сторонний человек вряд ли догадается, т.е. если исходить из логических соображений то всё наглядно (0/1/2) скорее всего будут обозначать вкл/ожид/выкл, так вот для того что бы избежать двояковой трактовки обозначений и вводятся коментарии. Естественно их не нужно вешать на все поля, но в исключительных случаях они необходимы. Это моё личное мнение.
    P.S. проверь добавление комментов, вчера никак не удалось добавить сообщение.

  16. vadim

    вводить аббревиатуры (m/f или enb/pend/dis) не удобно

    Это почему же?
    Как по мне неудобно постоянное лазить в DDL когда хочешь вспомнить что такое число 2 в поле status.

    какое число отвечает за какой статус сторонний человек вряд ли догадается

    Именно! Не должен он копаться в DDL чтоб понять что gender=1 – это male, gender=2 – female , а gender=0 – не указано.

    из логических соображений то всё наглядно (0/1/2) скорее всего будут обозначать вкл/ожид/выкл

    Тут нет ни логических соображений ни наглядности. Это результат неявной договоренности. Лично я бы никогда не догадался что 1=ожид. Я бы решил что 0=неактивный, а >0=активный. И я обложу матом своих коллег если увижу в коде что-то вроде:
    SELECT id, name, login FROM users WHERE status=2
    Код (в том числе и DDL) должен быть понятным для человека!.

  17. ICE

    В таком случае интересно посмотреть ваш вариант решения задачи со статусами. Согласен, что не всегда удачное решение с использованием цифрового обозачения статусав, однако здесь, как и во всём я придерживаюсь золотой середины. Не нужно перегибать палку и всё будет нормально.

  18. vadim

    Правильный с теоретической точки зрения вариант решения статусов:
    1= активен , 0= не активен, NULL = не установлен

    Или же в случае 3х возможных значений:
    enum(‘inactive’, ‘wait’, ‘active’)

  19. ICE

    Ну что ж, можно и так, считаю вопрос исчерпанным.

Leave a Reply