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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Вы можете сделать это другим способом, взломав строки в категорииID, но при поиске любых тем, находящихся в определенной категории, вам придется проходить через каждое поле и запускать LIKE на нем ... Гораздо более ресурсоемкий.

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

Answer 3

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

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

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

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