Как мне присоединиться к правильной таблице «один-к-одному» (супертипа, модель подтипа)?

Question

Я изучал первую, вторую и третью нормальные формы и хочу улучшить работу по нормализации своих таблиц. Отчасти я понял, что никогда не понимал назначение таблиц один на один. Из того, что я понимаю, «необязательные» данные должны быть сгруппированы в другую таблицу, оставляя отдельные объекты без изменений, избегая при этом нюансов ведения нескольких пустых полей в одной монолитной таблице.

Итак, сценарий реального мира. В CMS я хочу поддерживать несколько разных типов «страниц», делая их расширяемыми с помощью дополнительных плагинов, не затрагивая исходную схему. Пока у меня есть эти примеры таблиц:

• Страницы (заголовок, путь, тип и т. Д.)
• ContentPages (аналогично базовой странице, но с полями ключевых слов / описания / содержимого)
• LinkedPages (аналогично базовой странице, но содержит ссылку на другую страницу)
• ProductPages (аналогично базовой странице, но с SKU и другой информацией, связанной с ecomm)

Пока все хорошо. Нет NULL. Самодокументированный дизайн. Суперпечатание / Подтипирование согласовано между моими моделями PHP и базой данных. Все денди.

ИСКЛЮЧИТЬ, учитывая любой идентификатор страницы, я не хочу делать первый запрос, чтобы получить информацию о базовой странице, выяснить, какой это тип страницы, а затем получить соответствующую информацию подтипа с помощью другого запроса. Нужно ли отслеживать это с помощью состояния приложения (или URL-адреса) или есть способ узнать, к какой таблице нужно присоединиться, зная только идентификатор страницы и ничего больше?

Это действительно просто с одной таблицей (очевидно), так как поля NULL подразумевают тип, или ENUM может сказать мне, что это такое. Переключение обратно на 1NF не является приемлемым ответом, так как я уже знаю, как это сделать. Я хочу научиться так;)

ОБНОВЛЕНИЕ: Также хотелось бы отметить, что каждое из свойств подтипа уникально для этого типа. Таким образом, любое общее свойство, общее для всех типов, конечно же, попадет в таблицу базовой страницы. Подтипы не будут иметь никаких других свойств. Это выглядело как логичный способ группировки вложенных таблиц, но, может быть, я побеждаю назначение таблиц один-к-одному с этим расположением ...

Answer 1

Это зависит от того, кто задает вопрос. Если ваш плагин управляет запросом, он может начать с определенного подтипа и присоединиться к супертипу, который, как он знает, должен существовать.

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

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

Answer 2

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

Что ж, в структуре супертипа / подтипа вы должны знать больше, чем идентификатор страницы. Вы также должны знать подтип.

Обычно структура супертипа / подтипа для подтипов 'n' отображается на

• n + 1 таблиц, одна для каждого подтипа, плюс одна для супертипа и
• n обновляемые представления, каждое из которых объединяет супертип с соответствующим подтипом

Таким образом, ваше приложение обычно должно работать с представлениями, а не с базовыми таблицами. (Обычно, но не всегда.)

Если вы не используете представления, то при извлечении номеров идентификаторов страниц из супертипа вы должны также извлечь столбец, который идентифицирует подтип. Нет такой колонки? Исправь это. И посмотрите на эту другую уместную SO проблему проектирования базы данных для супертипа / подтипа с кодом, описанием структуры и логикой, стоящей за ней.

Answer 3

вы можете создать представление, оставив внешнее соединение, объединяющее все подтипы в основной таблице Page.Представление может запрашиваться одним page_id и возвращать одну строку со многими нулевыми значениями, так же, как вы получаете с одной большой таблицей страниц первой нормальной формы.