Valentin KotelnitskiПравильно думаете насчет EntityTypeId и EntityId. Я считаю, что это естественное решение.Лучше так: Не нужно лишний раз вводить пользовательскую типизацию. Все равно, с появлением нового типа (новой сущности), для которого будет требоваться комментарий, приложение будет дорабатываться.
Valentin KotelnitskiСсылочная целостность будет реализовываться (все проверки будут производиться) в Вашем приложении, работающем с базой.Реализовывать ссылочную целостность на уровне приложения плохо. Не надо подменять функционал СУБД.

Sweet_Alkazar _VVP_Не нужно лишний раз вводить пользовательскую типизацию
а что имеется ввиду?
Селекты всё равно под каждую сущность свои писать, чтобы вытащить комментарий.
Если у нас есть 10 млн. комментариев, то добавив сущность и поле EntiyN+1_Id получим
10 млн. NULL
Да и справочник типов сущностей всяко полезно иметь
Что-то не осознаю приемуществ о_О
Тут уже проходила ссылка на топик Тома Кайта "Вопрос по дизайну" . Почитайте, очень полезно, там как раз на данную тему.

Про справочник типов сущностей - используйте стандартный словарь СУБД. Это значит, что любая реляционная СУБД предоставляет словарь таблиц. Например: oracle - all_objects и т.д., mssql 2k - sysobjects и т.д. Используйте комментарии к объектам СУБД.

Я хочу сказать, что эти словари уже есть, они доступны и их можно и нужно использовать. Попытка построить еще один словарь ничего нового не даст. На эту тему опять же процитирую Кайта:
КайтThis is not a made up data model, one that I crafted just to make a point. This is an
actual data model that I've seen people try to use. Their goal is ultimate flexibility.
They don't know what OBJECTS they need, they don't know what ATTRIBUTES they will have.
Well - that is what the database was written for in the first place: Oracle implemented
this thing called SQL to define OBJECTS and ATTRIBUTES and lets you use SQL to query
them. You are trying to put a generic layer on top of a generic layer - and it fails each
and every time except for the most trivial of applications.
ПереводЭто ( создание пользовательского словаря ) не построит модель данных, отличную от только что показанной ( типовой словарь СУБД ). Эта реальная модель данных, я видел людей, пытавшихся ее использовать. Их целью была ультрагибкость. Они не знали объектов, которые им нужны, и не знают аттрибутов этих объектов.
Ну что же - это как раз то, для чего база данных ( СУБД ) была написана: Oracle реализует эти вещи, вызывая SQL для определения объектов и аттрибутов, позволяя вам использовать SQL для доступа к ним.
Вы же пытаетесь ( you are trying to put ) положить общий уровень на общий уровень - это будет давать сбой всегда и каждый раз, кроме может быть тривиальных приложений.

Valentin KotelnitskiНе годится для большого числа Entity.
И насчет селектов Sweet_Alkazar прав.
I also think he will know what objects he needs.

1. Большое количество - это сколько? 10, 20, 30 сущностей - вполне нормальная таблица комментариев получиться. Вы попробуйте сделать alter table add column с дефолтом NULL на таблице 10 млн. записей в нормальной СУБД. Это влет отработает, вы даже не заметите, и размер не измениться. .

2. Насчет селектов , и кстати добавлений аттрибутов в сущность "комментарии".
Если создавать свой словарь: вы все равно будете заполнять словарь ваших данных - кучей insert`ов и потом править приложение, чтобы оно принимало новую сущность.
В конце концов можно каждую сущность спроектировать от предка, который знает свое имя и умеет сам построить запрос на получение комментариев - одно голое наследование в данном случае, причем с минимумом полиморфизма на задание названия сущности.
Примите соглашение об именовании и "будет вам счастье".

3. А я полагаю , что автор темы пока что не вполне хорошо представляет рамки своего проекта. Иначе разговоров о 10 млн. комментариев и N+1 сущностей не было бы. Причем N+1 трактуется как очень большое число.

Sweet_AlkazarПодозревал, но не был уверенДа, бывают неожиданные откровения.

Sweet_Alkazar
1. Хм, чтобы полиморфизм заюзать в формировании селекта на клиенте
- то завсегда
а вот
- неожиданно слегка))
Кстати, лучше строить параметрические запросы для конкрентных значений, а для выбора имени колонок использовать названия сущностей: Тогда для каждой сущности у вас получиться статический запрос, который прокешируется в дереве запросов СУБД и не будет каждый раз парситься, и будет нормальное задание значений параметров.

Sweet_Alkazar2. Откуда куча инсертов если создавать свой словарь(таблице EntityType) не пойму?
Имхо, Приложение править по трудоемкости, что там что там одинаковоДа, по трудоемкости примерно одинаково.
Только в случае использования словаря СУБД, язык использования уже определен и стандартизован на мировом уровне - подмножество DDL языка SQL.
В случае своего словаря придется проектировать словарь, да еще и язык к нему (набор и последовательность INSERT, UPDATE и DELETE).

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

Valentin Kotelnitski2VVP
НеэлегантноВалентин, вы бы потрудились почитать ссылку и даже оценить скорость работы.
Вот вам пример из соседнего раздела, который показывает 5-кратный проигрыш в скорости метода с "собственным" словарем по сравнению с этим "неэлегантным" (как вы изволили выразиться) методом.

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

А по-моему элегантность статического словаря заключается в следующем:
1. Скорость выборок данных и даже изменений структуры СУБД на порядок выше.
2. Используется типовой язык определения словаря сущностей - SQL DDL.
3. Статический словарь позволяет "увидеть" графическое представление структуры БД - любые CASE или БД-менеджеры.
4. Словарь не надо проектировать, он уже есть в СУБД - возрастает скорость и универсальность разработки.

Наконец, хотите свой словарь? Сделайте систему въюх поверх sysobjects, syscomments, syscolumns и т.д. (для MSSQL, для Oracle тоже есть аналоги системного словаря) - вот вам собственный словарь.

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