Как лучше спроектировать Р-модель БД в данной ситуации?

Андрей Скоржинский, точно, спасибо, я совсем запутался:)
Я попробую поэкспериментировать с этим.

Как лучше спроектировать Р-модель БД в данной ситуации?

Не понял эту фразу. Под "свои поля" что имеется в виду в применении к предметной области?

В данном случае если вся бизнес логика на стороне сервера (не на БД), то вопрос можно снять.

С чем сравниваем? С выполнением sql-запросов? С linq?

Допусти на складе, есть сотни таких элементов:

ID | type | model_id | serial_num | status
1 | RAM | 1    |  kmgle43t | ok
2 | RAM | 1    |  kmfge65t | ok
3 | RAM | 4    |  kmferg5t | ok
4 | CPU | 1    |  km3fdrft | ok
5 | CPU | 1    |  k434fdrft | ok
и т.д

Если я захочу вывести для каждого компонента всю их информацию, например: Модель, размер, интерфейсы, и другие специфические для компонентов данные.
То мне для каждого поля нужно нужно будет делать джоин. Если у типа компонента RAM - 6 атрибутов, чтобы собрать из нужно будет сделать 6 джоинов.
Допустим на складе надо отобразить 100 компонентов RAM с их данными - это будет как минимум 600 джоинов.

Вот на сколько скажется на производительности?

Как лучше спроектировать Р-модель БД в данной ситуации?

Но для этого придётся жёстко писать логику на стороне сервера?
То есть запретить создавать пользователю свои поля и предоставлять только заранее заготовленные и на основе этого строить запросы.

И на сколько это быстрее будет? Ведь придётся делать как минимум 4-5 джойнов для одного компонента. Хотя с другой стороны не придётся плодить под каждый компонент свою сущность. Выглядит интересно.