Должен ли я сделать другую таблицу или просто использовать массивы? (Нормализовать или не нормализовать)

Question

В настоящее время темы отсортированы по 3 основным категориям. Существует возможность добавить не только 3 категории, но высшие должностные лица хотят реализовать возможность добавлять более 1 категории к теме.

Мой оригинальный дизайн базы данных имеет идентификатор категории в качестве внешнего ключа в таблице информации о теме. Вероятно, это была плохая идея с самого начала, но я полагал, что они настроены только на 3 категории, и при таком подходе будет меньше запросов.

Итак, из того, что я вижу, у меня есть два варианта: 1) Введите categoryID как разделенную запятыми строку, которую я анализирую на конце php. 2) Перестройте БД и извлеките categoryID в его собственную таблицу categoryID и topicID.

Мне было интересно, что все думают об этом. Мой первый инстинкт был реструктурировать базу данных. Но первый вариант, когда я думаю об этом, проще всего реализовать и реже всего сломать что-то существующее, изменив БД. Это также может привести к ненормализации и открыть возможность противоречивых данных.

Я прочитал, что нормализация хороша, если вы принимаете на себя риск получения противоречивых данных в обмен на производительность. По вашему мнению, я много выиграю в производительности для этого риска? Буду признателен за любую информацию о том, что мне следует сделать в этой ситуации.

Спасибо за помощь,
Леви

Answer 1

Не следует путать денормализацию (хорошим примером которой является сохранение количества голосов по вопросу SO вместе с вопросом в отличие от расчета его каждый раз из таблицы «голосов») с мерзостью, представляющей собой разделенный запятыми список идентификаторов.

Смоделируйте правильное отношение «многие ко многим»; Есть так много вещей, которые могут (и будут) пойти не так, используя разделенный запятыми подход. Чтобы назвать несколько:

1. Нет ссылочной целостности.
2. Почти невозможно использовать в объединениях.
3. Невозможно адекватно индексировать; немасштабирующиеся.

Answer 2

Если вам нужно что-то сделать в СУБД с отдельными элементами, не сохраняйте их в виде списка. Это заставит ваши запросы работать как собака, поскольку ваши таблицы становятся больше. Конечно, если вы когда-нибудь будете обрабатывать список как единое целое, все в порядке, так что хранить их таким образом.

Но вам лучше быть уверенным, что вы всегда будете рассматривать список как единое целое, а не обманывать, говоря, что они единое целое, а затем разбивать их на части где-то еще - лучше позволить СУБД сделать это за вас .

Вы должны всегда сначала делать 3NF, затем, если и только если у вас есть проблемы с производительностью, денормализовать скорость.

Те поля, о которых вы говорите в вопросе, не относятся к тому, что вы будете рассматривать как единое целое. Вам нужно будет что-то сделать с отдельными элементами в списках, чтобы их можно было разбить на другую таблицу.

Answer 3

Лучшим вариантом будет иметь базу данных, как вы сказали, для пары categoryID-topicID, чтобы найти, к каким категориям относятся темы.

Вы МОЖЕТЕ сделать это другим способом, взорвав строки в categoryID, но когда вы будете искать какие-либо темы, относящиеся к определенной категории, вам придется пробежаться по каждому полю и запустить на нем LIKE ... Многое более ресурсоемкий.

Потратьте время на реструктуризацию БД, и вы получите гораздо лучший результат.