Целое число против символа для свойства записи БД против схемы Wordpress

Question

Я задавал подобный вопрос раньше ( integer-vs-char-for-db-record-property ), но наткнулся на то, что противоречит всем рекомендациям, которые я получил в моем предыдущем посте. В Wordpress 3, самом популярном и зрелом сценарии блога с открытым исходным кодом, статус записи сохраняется как VARCHAR(20) в db - «публикация», «черновик», «наследование», «ожидание» и т. Д., А не INT с таблицей поиска или сопоставленными строковыми константами, или CHAR, или чем-то подобным. Это также относится к полю post_type ('post', 'attachment', 'revision' и т. Д.) И некоторым другим полям. Поэтому, чтобы найти все опубликованные сообщения, мне нужно запустить что-то вроде SELECT * FROM posts WHERE post_status = 'published' AND post_type = 'post'. Кроме того, в столбцах post_status, post_type и некоторых других столбцах есть индекс из нескольких столбцов, что, безусловно, ускоряет этот вид поиска. Может кто-нибудь объяснить, почему они сделали это так, а не иначе, и каковы преимущества и недостатки этого подхода?

Answer 1

Нормализация не сводится к замене строк числами или "совместным использованием" строк только потому, что они имеют одинаковые буквы.

Я не знаю их конструкции, но следующий сценарий совершенно нормализован, хотя в нем используются строкив качестве идентификаторов.

create table post_statuses(
   status varchar(20) not null
  ,primary key(status)
);

insert into post_statuses values('publish');
insert into post_statuses values('inherit');
insert into post_statuses values('pending');

create table posts(
   post_id ...
   status varchar(20) not null
  ,primary key(post_id)
  ,foreign key(status) references post_statuses(status)
);

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

Answer 2

То, что некоторые приложения хорошо известны, не означает, что у них был хороший дизайн базы данных.Это имеет тенденцию нарушать правила нормализации.Может быть, они получают лучшую производительность и, возможно, они не смотрели на другие возможности, когда выбрали эту, потому что они не знали лучше.Возможно, они были программистами приложений, проектировавшими базу данных, не очень хорошо понимающими теорию баз данных, или, может быть, это была преднамеренная денормализация с статистикой производительности для ее поддержки.Или, может быть, они не думали о возможности обновить 100 миллионов записей, когда мы решили, что хотим изменить значение с «опубликованного» на что-то другое.Может быть, они тестировали производительность только на избранных, но не на обновлениях.Может быть, ценности совершенно не изменится, поэтому денормализовать не так уж и сложно.Мы не можем знать отсюда.

Answer 3

Я предполагаю, что разработчики WP просто избегали преждевременной оптимизации и вместо этого выбрали лучшую читабельность.

"SELECT * FROM posts WHERE post_status = 'published' AND post_type = 'post'"

немного легче читать, чем

"SELECT * FROM posts WHERE post_status = ".WP_POST_STATUS_PUBLISHED."
    AND post_type = ".WP_POST_TYPE_POST.""

И когда новый разработчик WP запускает запрос select * from ..., таблица базы данных перечисляет «опубликованные», а не 3 или 5, что проще для понимания и отладки.

С точки зрения дискового пространства, любой подход достаточно хорош, я думаю - еще post_status байтов не должно иметь большого значения по сравнению с текстом поста в блоге и всеми другими столбцами. Целое число составляет 8 байт (ну, если не крошечный), а значение «опубликовано», возможно, составляет 10 байт, так что это не имеет большого значения?