Целое число против символа для свойства записи БД против схемы 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

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

Answer 2

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

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

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 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 байтов (ну, если это не tinyint), а «опубликовано», возможно, 10 байт, так что не имеет большого значения?