VetalВсем здравствуйте!
во-первых: мне не нравится на концептуальном уровне, что News ненапрямую зависит от Site как через NewsType, так и через Rubric.
Таким образом, теоретически может быть возможность, что для некоторой новости ее тип новости будет принадлежать одному сайту, а рубрика другому сайту.

Дык а зачем вы так сделали?
Замените связи NewsType_Site и Rubric_Site которые сейчас 1-ко-многим, на связи многие-ко-многим. Соответственно развертываем связи многие-ко-многим и получаем две новые таблицы только с идентификаторам - SiteNewsTypes и SiteRubrics.

Подумайте также может стоит новости, фоторепортажи, интервью, анонсы и т.п сделать подтипами некоторого общего предка "абстрактная статья", т.е. реализовать наследование в виде связи 1-к-1. По крайней мере на первоначальном этапе проектирования не рекомендуется сводить подтипы в одну сущность с признаком типа. Скорее всего атрибуты фоторепортажа будут иными чем у обычной новости.

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

Решается введением альтернативного ключа по идентификатору рубрики и сайту.

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

Имхо, это проконтролирвать надо на уровне бизнес-логики.
Vetal
Кроме того, у меня ж в таблицах NewsType и Rubric ключи были составные, и первые их атрибуты являются ключом таблицы Site. Мне что, в Вашем случае необходимо создавать суррогатный ключ в таблицах Rubric и NewsType?

Да, создать суррогатный и не увлекаться особо естественными.
автор?? По идее автора новость находится на одном сайте, в единственной рубрике и имеет единственный тип.
Видимо так. тогда чего проще - Сайт<-рубрика<-новость + сайт-допустимые типы новостей. А контролировать допустимость ввода новости с конкретным типом - на уровне бизнес-логики.

авторПри этом если таблица содержит 25 различных типов новостей, то мне получается нужно создать 25+1 таблиц. При этом придется делать джойн больших таблиц, в моем случае до миллиона записей, когда можно было бы обойтись и без этого джойна, если все будет в одной таблице. Это сказывается на производительности.
А вы думаете смещение модели в сторону EAV менее скажется в производительности? По крайней мере модель на наследовании будет поддаваться оптимизации и легкому перепроектированию для повышения производительности, а EAV - уже нет.
И JOIN тут как раз даже может увеличить производительнось впротивовес тому, если бы у вас существовала одна таблица на миллионы записей.

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

авторОбьясните пожалуйста, чем ваше предложение лучше? Я хочу понять, может, я и ошибаюсь...
Оно не лучше, просто это позволяет при концептуальном моделировании выявить все сущности (если это ,конечно, возможно на этапе проектирования) и избежать возможных ошибок проектирования. Впоследствии, если модель окажется простой, схема может свестись к первоначально вами предложенному использованию идентификатора типа.