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]
Tweet
Афигеть. Сам придумал? Где-то юзаешь?
Придумал сам, но нигде не использую. Надо бы в категорию humor наверное :)
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…
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.
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) :)
niezłe, ciekawy kawałek kodu :) też pisze w swoim języku skoro reszta jest leniwa i tak robi :P
Нафига это извращение, юзай enum. Для хранения состяния вкл/выкл или для эмуляции бит. поля вполне подходит enum(0, 1)
Надо все-таки в категорию humor :)
Решение плохо тем, что вводит путаницу, т.к. у енумов нумерация начинается с единицы. Получается:
1 => ’0′
2 => ’1′
Вот и “проверяй какого полу твой сосед” после этого…
to Скакунов Александр
Т.е. начинается с еденицы? При чём тут это, во всех запросах используй значины списка без каких либо перестановок. Если я ограничил ввод поля 0, 1 – значит везде будут использоваться эти значения. А что бы избежать путаницы, всегда вешаю на поле комментарий, типа (пример для пола): 0 – женский пол, 1 – мужской. И никакой путанницы.
Если к полю приходится писать комментарий – то это “душок” от которого нужно активно избавляться.
Хм, по вашему комментирование кода, в том числе и БД признак плохого тона? Занимательно….
Никто не говорит что комментирование кода – признак плохого тона.
Признак плохого кода (и ещё чаще дизайна), это когда код не прозрачен для читающего -
тобишь требует комментирования.
И если код требует пространных комментариев – то это первый признак того, что скорее всего в нем встречаются и другие “запахи”.
Прочитать об этом можно например в “Рефакторин” М.Фаулера (где-то в первых главах описываются основные “запахи” дурного кода)
Касательно данного примера: если разработчику приходится лезть читать комментарии, чтоб понять семантику поля/значения-поля в БД, то явно что-то с этим полем не то.
Или это поле называется нелогично, или для него выбран не тот тип данных.
(опять же по Вашему примеру)
Вы же не пишете комментарии к полям login, password, name, surname, is_active?
Почему нужно писать к полю gender?
Часто встречаются моменты, когда для описание какого либо поля удобно использовать числовое значение, например тот же пол (м/ж), либо если есть 3 статуса (вкл/ожидание/выкл). Для такой мелочи вводить отдельную таблицу для связи глупо, вводить аббревиатуры (m/f или enb/pend/dis) не удобно для таких ситуаций отлично подойдёт числовое обозначение состояния. Но вот какое число отвечает за какой статус сторонний человек вряд ли догадается, т.е. если исходить из логических соображений то всё наглядно (0/1/2) скорее всего будут обозначать вкл/ожид/выкл, так вот для того что бы избежать двояковой трактовки обозначений и вводятся коментарии. Естественно их не нужно вешать на все поля, но в исключительных случаях они необходимы. Это моё личное мнение.
P.S. проверь добавление комментов, вчера никак не удалось добавить сообщение.
Это почему же?
Как по мне неудобно постоянное лазить в DDL когда хочешь вспомнить что такое число 2 в поле status.
Именно! Не должен он копаться в DDL чтоб понять что gender=1 – это male, gender=2 – female , а gender=0 – не указано.
Тут нет ни логических соображений ни наглядности. Это результат неявной договоренности. Лично я бы никогда не догадался что 1=ожид. Я бы решил что 0=неактивный, а >0=активный. И я обложу матом своих коллег если увижу в коде что-то вроде:
SELECT id, name, login FROM users WHERE status=2
Код (в том числе и DDL) должен быть понятным для человека!.
В таком случае интересно посмотреть ваш вариант решения задачи со статусами. Согласен, что не всегда удачное решение с использованием цифрового обозачения статусав, однако здесь, как и во всём я придерживаюсь золотой середины. Не нужно перегибать палку и всё будет нормально.
Правильный с теоретической точки зрения вариант решения статусов:
1= активен , 0= не активен, NULL = не установлен
Или же в случае 3х возможных значений:
enum(‘inactive’, ‘wait’, ‘active’)
Ну что ж, можно и так, считаю вопрос исчерпанным.