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

Вопрос в том, как лучше организовать таблицы для хранения этих данных?
Я придумал 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 В, посмотреть их наличие.


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


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

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

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


У импортных, как правило, нормальный part number - RC0805FR-07300KL, CL05A225KP5NSNC, CC0201JRNPO9BN220 и т.п.

В принципе, там действительно достаточно названия и основных характеристик, плюс ещё PCB Footprint и Schematic Symbol, и информация о наличии.


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

В смысле, таблицы с перечнем компонентов? Есть, в Акцессе, правда, типизация там пока реализована в "зачаточной" форме. Смогу в понедельник выложить.


Есть, но это - не проблема.

Прилагаю таблицы резисторов и конденсаторов. Другие типы не стал включать, т.к. они сейчас просто в отдельной таблице перечислены без характеристик, так что смысла их приводить нет.

Проверил - та СУБД поддерживает получение информации из запросов (по крайней мере в Акцессе); и текстовый формат атрибутов, кстати, тоже.


Там их, скорее всего, не понадобится добавлять.


Кстати да, точно. Спасибо! При связи 1 к 1 - самое то.

В смысле САПР, а не СУБД.

А где об этом можно почитать? Поиск даёт только материалы по 1С.


Максимум, может быть сведения по температуре понадобятся. Остальное - точно нет (упаковка не важна, габариты определяются корпусом, и т.п.).


Здесь это одно и то же.

Да, количество / состав атрибутов здесь не будет меняться.