Другой дизайн, который следует рассмотреть, - это создание отдельных таблиц отношений для каждого типа контента:
article_category (article_id NOT NULL, category_id NOT NULL)
photo_g_category (photo_g_id NOT NULL, category_id NOT NULL)
video_g_category (video_g_id NOT NULL, category_id NOT NULL)
Этот дизайн устраняет необходимость хранить значения NULL, как это требуется в вашем дизайне.Все эти столбцы будут определены как внешние ключи для соответствующих таблиц.
Потерянное пространство не является проблемой для вашего дизайна.(В большинстве механизмов баз данных для хранения значения NULL не используется пространство.)
Более серьезная проблема в вашем проекте - убедиться, что заполнен хотя бы один из столбцов FK содержимого, и разрешить другимноль.Кроме того, ваш дизайн усложняет процесс добавления и удаления отношений, если вы разрешаете заполнять более одного столбца FK контента в строке.
Как вы планируете представлять контент, относящийся к категории, например, 1?
артикул: a, b, c photo_g: p, q video_g: v, w, x, y, z
1 a p v
1 b q w
1 c - x
1 - - y
1 - - z
ИЛИ
1 a - -
1 b - -
1 c - -
1 - p -
1 - q -
1 - - v
1 - - w
1 - - x
1 - - y
1 - - z
Удалениеотношение между категорией 1 и photo_g p будет другим, в одном случае требуется обновление строки, в другом - удаление строки (нет смысла хранить строку, в которой не заполнено ни одно из значений FK содержимого).
Я предлагаю три отдельные таблицы для хранения этих отношений:
article_category:
a 1
b 1
c 1
photo_g_category:
p 1
q 1
video_g_category:
v 1
w 1
x 1
y 1
z 1