#mysql #database-design #schema
#mysql #база данных-дизайн #схема
Вопрос:
какая структура лучше?
table1
postid category1 category2 category3
2 a b d
3 a c null
или
опубликовать таблицу
postid
2
3
таблица category_option
category option
category1 a
category2 b
category3 c
category4 d
option_post таблица
post option
2 a
2 b
2 d
3 a
3 c
кажется, что создать запрос для первой структуры проще, чем для второй структуры.
Комментарии:
1. это действительно зависит от того, чего вы пытаетесь достичь? в общем, второе заполнение должно быть нормализованным видом. так что это может быть лучше, а в некоторых случаях и быстрее; В других случаях первая будет проще и быстрее; дайте более подробную информацию
Ответ №1:
Эти две структуры моделируют разные вещи. Первая жестко допускает только (до) 3 категорий (и различает категории по положению), в то время как вторая может моделировать любое количество категорий (которые не различаются по положению). Какая из них лучше, действительно зависит от того, чего вы пытаетесь достичь…
На чисто техническом уровне вторая может потребовать ОБЪЕДИНЕНИЯ для некоторых запросов, в то время как первая может удовлетворить запрос из одной (и только) таблицы. Является ли это проблемой или нет, опять же, зависит от обстоятельств…
Комментарии:
1. когда вы говорите присоединиться к таблице, вы имеете в виду что-то вроде select * from таблица как t1, таблица как t2 и t1.option = a и t2.option = b и t1.postid = 2 и t1.postid = t2.postid? это запрос оптимизации? есть ли лучшее решение?
2. Да, что-то вроде этого, хотя обычно используется более современный синтаксис (ключевое слово JOIN в Google). ОБЪЕДИНЕНИЕ может быть очень быстрым или очень медленным в зависимости от многих факторов, в том числе от индексов. Я настоятельно рекомендую прочитать use-the-index-luke.com для разветвлений производительности индексов в целом и объединений в частности.
Ответ №2:
Зависит от требований…
Ожидаете ли вы увеличения количества опций с течением времени?
ваш первый вариант намного проще кодировать, второй вариант имеет гораздо более модульный дизайн и масштабируемость.
Комментарии:
1. иногда нарушение нормальной формы ради повышения производительности стоит того, особенно если вы знаете, что это всего лишь временная ситуация, краткосрочный проект или он НИКОГДА не увеличится в размерах. Но вариант 2 — это гораздо больше «Книга и теория» и «правильный» способ сделать это.
Ответ №3:
Это сильно зависит от природы категорий. Если список фиксирован и вряд ли будет расти, то первая структура работает просто отлично, и с ней может быть проще работать. Если список категорий, вероятно, будет расти, то второй вариант будет расти лучше.
Также имеет значение, являются ли значения категории разреженными. Если большинство категорий не будут иметь значений, то второй подход займет гораздо меньше места. Если каждый элемент будет иметь значения в каждой категории, это не проблема.
В данном случае важно понимать, что означает «вероятно». Это не значит, что вы, дизайнер, не думаете, что она будет расти. Это означает, что список категорий хорошо понятен и проработан, и поэтому вряд ли будет расти. Я продолжал искать примеры, но ни один не пришел на ум.
Есть веские причины выбрать первую, но делайте это с осторожностью — переключение на второй вариант в производственной системе будет кошмаром.
Ответ №4:
Вторая лучше. Первое — это нарушение первой нормальной формы:
http://en.wikipedia.org/wiki/First_normal_form#Repeating_groups_across_columns
Ответ №5:
вторая лучше. это типичный случай many2many с таблицей объединения.
если вы сделаете это 1-м способом, что вы собираетесь делать, если появятся новые категории category 4,5,6,7,8 … come? добавить новые столбцы в таблицу?
И я не знаю, есть ли у вас требование типа «сколько записей с параметром категории ‘c'»? 2-ю легко выполнить статистическую обработку, но 1-ю…
Комментарии:
1. Слишком простой ответ. Есть много хороших мест для использования плоской структуры таблицы.
2. Я согласен — это неправильный ответ. Это в высшей степени ситуативно.
Ответ №6:
у category_option должен быть идентификатор категории, чтобы создать таблицу объединения с opton_post, иначе нет способа создать эту структуру 2-й таблицы.
с помощью этой структуры вы можете достичь двух вещей.
1) установите связь «один к одному» с сообщением о категории. (это означает, что вы можете добавить больше категорий в будущем, если это необходимо)
2) в этой структуре значения null автоматически исключаются. это означает, что больше не нужно обрабатывать нулевые значения в таблице или в sql-запросах.
надеюсь, это поможет.