Это вызывает проблемы с таблицей, связанной с несколькими типами контента?

Question

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

Вот пример: у меня есть пять видов контента, и у всех них есть заголовок.Итак, я не могу просто использовать таблицу заголовков для всех пяти типов контента?

Расширение этого примера: технически название - это имяЛюди и места имеют имена.Было бы плохо помещать все мои заголовки контента, имена людей и топонимы в таблицу имен?Почему разделить на place_name, person_name, content_title?

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

Answer 1

Я бы так не поступил.

Если есть несколько столбцов, которые являются одинаковыми среди нескольких таблиц, вы должны действительно нормализовать их до 1 таблицы.

И примером этого могут быть несколько типов пользователей, которым требуются разные столбцы, но все они имеют некоторые характеристики (например, имя, адрес, номер телефона, адрес электронной почты) Они могут быть нормализованы до 1 таблицы, на которую затем ссылаются все другие таблицы через внешний ключ. (см. http://en.wikipedia.org/wiki/Database_normalization)

Ваш пример показывает только 1 общий столбец, который не стоит нормализовать. Это даже снизит производительность при попытке получить ваши данные, потому что вам нужно объединить две таблицы, чтобы получить все данные; 1 из которых (тот, что с заголовками) содержит много данных, от которых вам не потребуются все данные, тем самым увеличивая нагрузку на сервер.

Answer 2

Для типизации данных таким способом лучше всего использовать таблицу (т. Е. name) и вложенную таблицу (т. Е. name_type), а затем использовать ограничение FK.Используйте FK constraint, потому что InnoDB не поддерживает ограничения столбцов, а механизм MyISAM не подходит для этого (он гораздо менее надежен и многофункциональн, и его действительно нужно использовать только для производительности).

Этот вид нормализации хорош, но его следует выполнять с типом столбца свободного формата, например VARCHAR(40), а не с ENUM.Используйте триггеры, чтобы ограничить ввод, чтобы он соответствовал типам, которые вы хотите поддерживать.

Answer 3

Хотя нормализация - это очень хорошая практика, позволяющая избежать избыточности и обеспечить согласованность, иногда она может ухудшить производительность.Например, для таблицы person, в которой есть такие столбцы, как name, adress, dob, не очень хорошая производительность, если иметь picture в одной таблице.Размер изображения может составлять около 1 МБ, а оставшиеся столбцы могут занимать не более 1 КБ.Представьте, сколько блоков данных необходимо прочитать, даже если вы хотите указать только имена и адреса людей, живущих в определенном городе, - если вы храните все в одной таблице.

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