Проектирование универсальной структуры БД Опции

[Litkevich Yuriy]

Задался вопросом как бы так запроектировать структуру БД, чтобы её для всех задач использовать.
За основу взял такую задачу - справочник по радиоэлектронным компонентам.
Суть его такова, есть типы компонентов (конденсаторы, резисторы, ...). У каждого типа есть обязательный набор характеристик (для конденсаторв: Напряжение и ёмкость, для резисторов: сопротивление и мощьность). Также у каждого типа есть специфические характеристики, но необязательные (для конденсаторов: ТКЕ-температурный коэфициент ёмкости, для резисторов: ТКС - температурный коэфициент сопротивления).
Плюс к этому у каждого компонента может быть уникальная, важная характеристика.
Разумеется у каждого элемента есть марка (наименование)

Дерево элементов можно представить так:

|
|-конденсаторы
|    |- К50-35 16В  100мкФ ±20% (ёмкость-100мкФ, напряжение-16В, допуск по ёмкости ±20%)
|    |- К50-35 35В  2200мкФ ±20% (ёмкость-2200мкФ, напряжение-35В, допуск по ёмкости ±20%)
|-Резисторы
|    |- С2-32-1 100 ±5% (сопротивление-100 Ом, мощьность 1Вт, допуск по сопротивлению ±5%)
|    |- С2-29-0,5 1к ±0,5% (сопротивление-1 кОм, мощьность 0,5Вт, допуск по сопротивлению ±0,5%)

В интернете встречал такие термины - "сущьности" и "свойства сущьностей", вроде как такими терминами оперируют при проектировании БД.
Видимо это какой-то подход, на манер шаблонов проектирования программ.

Где-то так должен выглядеть процесс настройки заготовки БД:


вот с типами и элементами вроде реализация сравнительно простая, а со свойствами не совсем понятно, т.к. тип данных может быть разный.
И ещё, хотелось бы для каждого свойства задавать, некое связанное свойство, например, для "напряжения" - еденицу измерения - "Вольты" (тип: "строка")

Может кто-нибудь подсказать, где про такие вещи почитать?

[Sokoloff]

Как уже сказали это будет медленнее чем база написанная под конкретную задачу.
На мой взгляд, это похоже на создание нового языка программирования. Я бы шел снизу вверх, и мне это видится примерно так:

Базовые типы.
Строка, целое, десятичное, дата, время и.т.д. Представлены таблицами вида [ID, Value].

Ссылки (указатели)
Каждая таблица имеет свой TableID. Ссылка это пара TableID и ID записи в соответствующей таблице. Ссылка может ссылаться на все типы, включая массивы и объекты.
Если нужны ссылки на ссылки, то к базовым классам добавляем таблицу ссылок вида [ID, RefTableID, RefID] .

Массивы
В таблице массивов хранятся не значения, а ссылки на значения, поэтому в массиве можно хранить элементы разных типов. Вид таблицы: [ID, ArrayID, Index, RefTableID, RefID]. ArrayId - поле по которому можно отделить элементы одного массива от другого.

Объекты или коллекции
Наборы именованных ссылок, вид [ID, ObjectID, Key, RefTableID, RefID] . В твоем случае конденсаторы и резисторы представляются именно ими. Ссылка может ссылаться на что угодно даже на другой объект, т.е. мы можем хранить деревья, строить списки и.т.п.

Классы
Если хотим иметь более строгие объекты, то создаем еще таблицу в которой перечислены поля объектов, их типы и опции полей. Что-то типа [ID, ObjectID, FieldType(храниться TableID), Required ...].


Работать напрямую с таблицами нельзя, нужно писать хранимки. Для поддержания целостности, нужны триггеры.


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