#database #database-design
#База данных #база данных-дизайн
Вопрос:
Я беспокоюсь о производительности, проектировании и удобочитаемости. Допустим, у меня есть блог, и каждая запись имеет свой статус: опубликована (4), ожидает рассмотрения (2), черновик (1). Как рекомендуется хранить эту информацию в status столбце?
status <======= storing status as string
========
pending
published
draft
status <======= storing status as integer
========
2
4
1
Кроме того, если мы должны хранить целое число, должны ли мы воздержаться от хранения текущего integer: 1, 2, 3, 4, 5 , в отличие от хранения целого числа ^ 2: 2, 4, 8, 16, 32 ?
Большое спасибо.
Ответ №1:
Я думаю, что ваш лучший выбор для повышения производительности, уменьшения объема памяти и удобства чтения — использовать CHAR(1)—(p) ublished, ожидающий (r) eview и (d) raft. Вы можете проверить эти данные либо с помощью ограничения ПРОВЕРКИ, либо ссылки на внешний ключ.
Символ (1) занимает существенно меньше места, чем целое число. Это доступно для чтения непосредственно людьми, поэтому для его понимания не требуется объединение. Поскольку оно меньше по размеру и сразу читается, вы получите более быстрый поиск, чем объединение целого числа, даже в таблице из десятков миллионов строк.
Комментарии:
1. Это хорошая идея. Решает ли этот метод проблемы, о которых упоминал Оли Чарлсворт?
2. Преимущества в отношении пространства / скорости доступа предполагают, что данные не дополняются до размера слова в целях выравнивания. Удобство чтения человеком также решается с помощью перечисления (которое дает вам бесплатную проверку).
3. a) Если данные дополнены до размера слова, то char (1) все равно будет быстрее, чем join, потому что, хотя теперь он того же размера, что и целое число, для него не потребуется объединение. b) Enum — это не SQL. Разные платформы поддерживают это разными и несовместимыми способами. Ни одна из основных коммерческих СУБД вообще не поддерживает это, AFAIK. MySQL и PostgreSQL поддерживают это разными и несовместимыми способами. c) Изменения в перечислении требуют изменения схемы; изменения в таблице, связанной ссылкой на внешний ключ, требуют только вставки строки. (Таким образом, проверка не совсем бесплатна.)
4. Соединение с чем? OP не говорит о соединениях, AFAICS.
5. Соединение с любой таблицей сообщает пользователям, что 1 означает «черновик».
Ответ №2:
Сохранение в виде строки:
- пустая трата места
- чтение / запись занимает больше времени
- сложнее ли индексировать / искать
- затрудняет гарантию достоверности (ничто не мешает кому-либо вставлять произвольные строки)
В идеале, вы должны использовать тип enum для такого рода вещей, если ваша база данных его поддерживает.
Комментарии:
1. Я не могу решить, что лучше. И у вас, и у Catcall оба хороши. Я проголосую за ваш ответ.
2. Причины, по которым перечисление является злом , вероятно, стоит прочитать.
Ответ №3:
Я думаю, что выбранный вами вариант должен зависеть от того, насколько хорошо используемые вами инструменты / фреймворки работают с каждой функцией.
Многие базы данных / ORM плохо справляются с перечислениями, требуя пользовательского кода (не понимают концепцию «перечисляемого типа»).
Тем не менее … вероятно, я бы использовал строки.
Строки:
- используйте больше места, но в вашем случае имена короткие, и вы можете легко прочитать дамп данных без легенды таблицы перечислений. В настоящее время для блога / CMS хранение вряд ли является проблемой
- различия в производительности обычно невелики
- вы не можете легко переставить элементы таблиц перечислений (вы должны принудительно использовать «исходные» целочисленные значения).
Строки также выбираются некоторыми хорошо известными CMS (например, Drupal 7).
Конечно, это поздний ответ, но он может быть полезен другим читателям.
Ответ №4:
Хранение данных в целочисленной форме всегда более надежно, чем в виде символа или строки.
Создайте две таблицы, такие как blog_status и blog_details
В blog_status поддерживайте основной статус blog, как вы сказали черновик, ожидающий и публикуйте структуру таблицы blog_status
Create table blog_status
(
blogstatus_id int,
blogstatus_desc varchar(10),
primary key(blogstatus_id)
)
А затем создайте другую таблицу, в которой вы хотите использовать blog_status таким образом, вы всегда сможете улучшить возможность повторного использования и производительность вашего приложения
Create table blog_details
(
blog_id int,
blog_title varchar(10),
blog_postingdate datetime,
blog_postbox varchar(max),
blog_status int, ---------------------> This should be your blogstatus_id value
primary key(blog_id)
)
Нет смысла использовать выражение или формулу x ^ 2.
Надеюсь, я развеял ваши сомнения. Если вы найдете ответ полезным, пожалуйста, отметьте его как свой ответ, иначе дайте мне знать…
Комментарии:
1. Какое отношение это имеет к вопросу OP?
Ответ №5:
Теоретик базы данных во мне считает, что вам не следует использовать таблицы поиска для атрибутов с одним столбцом, потому что это приводит к ненужному разделению ваших данных; другими словами, вам не нужно иметь таблицу с двумя столбцами (и значением идентификатора и именем атрибута). Однако администратор базы данных во мне считает, что из соображений производительности разделение ваших данных является очень правильным методом. Индексирование, следы на диске и обновления становятся очень простыми при использовании поиска.
Я бы, наверное, разделил это.