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

Вопрос в том, как лучше организовать таблицы для хранения этих данных?
Я придумал 3 варианта, но ни один из них меня не устраивает.

1) Отдельная таблица для каждого типа
Резисторы (id, наименование, производитель, сопротивление, допуск, номинальная мощность, температурный коэффициент, корпус)
Конденсаторы (...)
Недостатки:
- Дублирование всех связанных таблиц
- Дублирование всех форм (или же придумывание сложных костылей)

2) Отдельные таблицы для типов + сводная таблица
Таблицы для типов такие же, как в п. 1, сводная таблица содержит имя таблицы типов и номер записи:
idИмя_таблицыНомер_записи1Резисторы12Конденсаторы1
Этот вариант мне кажется наиболее оптимальным, но:
- Не будет обеспечения целостности данных
- Невозможно в запросе задать имя таблицы, считав его из сводной таблицы. Единственный выход - формировать запросы в VBA.

3) Сводная таблица с неопределёнными атрибутами
idнаименованиепроизводительтипзначение1величина1значение2величина2атрибут1атрибут21RC0402JR-0722RLYageoрезистор22Ом62.5Вт04022CL31B102KBCNNNCSamsungконденсатор1000пФ50ВX7R12063AD9850BRSZAnalog DevicesмикросхемаDDSSSOP-28
Недостатки:
- Избыточные атрибуты
- Работа с данными сложнее, чем в случае таблиц со строго определёнными атрибутами; так же могут возникнуть затруднения, если потребуется модифицировать структуру таблицы
- Таблицы, связанные с атрибутами, будут содержать беспорядочный набор данных (в данном примере - таблица - источник значений атрибута "величина1" содержит единицы измерения и сопротивления, и ёмкости, а источник значений атрибута "атрибут1" - и тип диэлектрика конденсатора, и тип микросхемы).

Существуют ли более лучшие способы решения этой задачи? В т.ч. связанные с переходом на другую СУБД.

Спасибо за ответы!
Посмотрел EAV - там, вроде бы, все значения хранятся в виде текста, или же создаются несколько "параллельных" полей для разных типов данных. Это не очень удобно.
Насколько понял, EAV - хороший подход, когда число типов и свойств практически неограничено, и может изменяться в течение времени. Но в данной задаче всё же довольно ограниченный набор типов, и у каждого из них - фиксированный набор свойств. Поэтому, как мне кажется, если использовать здесь модель EAV, то это неоправданно усложнит БД. Здесь даже получить из этих данных таблицу вида "Название резистора"-"Сопротивление"-"Вольтаж"-"Корпус" - уже проблема, у меня получилось это сделать только при помощи перекрестного запроса.


Не очень понятно: в Акцессе же нет такого типа данных как массив, или имеется в виду массив, записанный в виде строки?


Может быть, существуют СУБД, поддерживающие метатаблицы как в варианте 2? Т.е. таблица, содержащая имена таблиц или ссылки/указатели на них, чтобы реализовать возможность обращения к нужной таблице без костылей в виде программной генерации кода запроса?

Появилась ещё одна идея: примерно такая сводная таблица компонентов:
idимятипсвойства_резисторысвойства_конденсаторысвойства_микросхемы1RC0402JR-0722RLрезистор92CL31B102KBCNNNCконденсатор53AD9850BRSZмикросхема1
Где значение атрибутов "свойства_..." - id записи в соответствующей таблице характеристик. Соответственно, для каждого типа - отдельная таблица с характеристиками. Недостаток - если всего будет N типов, то в сводной таблице у каждой записи будет N-1 неиспользуемых атрибутов.

Насколько понял, там все типы данных реализованы через строки, а это не есть здорово с точки зрения размера базы и быстродействия.


Тоже вариант, но здесь не очень хорошо то, что для всех записей в этой таблице будет множество "лишних" пустых полей. И ещё некоторые поля, по-видимому, необходимо будет продублировать. Например, у резисторов и у микросхем совершенно разные типы корпусов, поэтому потребуются столбцы Корпус_резистор и Корпус_микросхема (или же сделать один столбец Корпус, но перечислить все возможные корпуса для всех типов в одной связанной таблице, что тоже не очень хорошо). Или количество: у электронных компонентов количество целое, у проводов - действительное (длина).

Точно это количество не обговорено (оно должно определиться в процессе), но примерно около 30.


Кстати, да - объёмы сравнительно небольшие, порядка нескольких десятков тысяч записей.


А какие?

Спасибо за пример! Я уже, по советам участников, попробовал реализовать что-то типа-этого, но здесь 2 проблемы: сравнительно сложно получить таблицу вида "Название резистора"-"Сопротивление"-"Вольтаж"-"Корпус" (и её нельзя редактировать), а также все значения в текстовом виде, что затрудняет их сравнение между собой / операции с ними.


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


В первую очередь - найти все подходящие компоненты, например, все конденсаторы с определённым типом корпуса, ёмкостью от 200 до 300 пФ и напряжением не меньше 50 В, посмотреть их наличие.


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


Спасибо за советы, буду смотреть.

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