Это как раз тот плохой случай для реляционной модели.
Одна таблица - ухудшение качества отображения информации за счет "искажения" структуры: то что выглядит атрибутами для одного вида деталей - превратилось в значения. А поскольку система запросов строится на использовании атрибутов соответствующие "преобразования запросов". Извлечение информации усложнится.
Здесь еще и то, что некоторые характеристики числовые, а некоторые символьные. Теперь все символьные. Вообще ограничения целостноти на значения накладывать сложнее.
Однако, если все эти недостатки в данной задаче не могут сильно проявиться, то, наверное, решение - одна таблица, может иметь смысл. Обычно это имеет смысл, когда сама информация о характеристиках этих деталей не так важна.

50 таблиц - одна на вид детали - большое число таблиц в общем-то для очень схожих типов сущностей - видов деталей, которык к тому же выглядят как сущности - т.е. возможно появление нового вида деталей. Похоже здесь обратная ситуация то, что похоже на кортеж превращается в отношение. Если в одном запросе про все виды детадлей - 50 таблиц в запросе. А если появится 51, 52 и т.д. - вид деталей? Добавление новых таблиц - измение структуры - новая версия БД, и скорее всего приложения. Структура на то и структура, чтобы быть относительно статичной частью системы (ведь те же запросы еще придется переписывать, где участвуют детали всех видов). В общем это решение тоже плоховато. Конечно, если эти недостатки для конкретной задачи имеют значение.
Решения с изменяющейся структурой - не самым лучшим образом согласуются с идеей статичности понятия структуры, т.е. объективно должно ухудшиться то, для чего это понятие существует.
Думаю, что стоит подумать об объектных возможностях современных ОРСУБД.
Тогда то, что здесь предлагали решить изменчивостью реляционной структуры, можно попробовать - решить с помощью пользовательских типов объетов, а то что реляционным методом так и оставить. Т.е. нивилировать эти недостаки используя преимущества двух этих технологий.
Сейчас большинство лидирующих СУБД поддерживают такую возможность.

Dik76
А то что Вы предлагаете не плохой способ для реляционной модели?


На самом деле, я скорее не предложил, а обратил внимание на возможность рассмотреть подход на основе объектно-реляционной модели данных.
Все-таки чтобы оставаться только в реляционной модели для данного приложения приходится идти на ухищрения при моделировании, последствия которых на протяжении всего жизненного цикла информационной системы не до конца ясны.
Безусловно и ОР подход означает и усложнение запросов, возможно и ОРСУБД еще не совсем достаточно поддерживают объектную составляющую для решения реальных задач. Плюс багов наверное там хватает. Наверное усложнится и программирование. Но плюсом может быть и более адекватное моделирование (тоже пока лишь предположение). И, например, запросы усложнятся только немного в плане синтаксиса, но не в плане компенации ухищрений моделирования. Последнее в общем случае на этапе эксплуатации ИС может оказаться для нее критичным - отрицательно сказаться на продолжительности жизненного цикла.
Но речь идет только о том, чтобы если есть возможность, проверить и этот подход.

Dik76
Предложенное решение в посте 1003997 предполагает использование в рамках реляционной модели, усеченное описание детали в виде объекта. Это решение позволяет гибко добавлять харктеристики детали, без изменения структуры БД и механизма обработки. ИМХО - это плюс и не малый.

Я пытался сказать, что для конкретного проекта возможен любой из предложенных вариантов в зависимости от недостатков для конкретных требований. Более того, скорее всего, вариант предолженный в посте 1003997, скорее всего, на сегодняшний день претендует на то, что реально и будет использовано.
И действительно, как и для однотабличного решения структура БД при добавлении нового вида деталей не меняется. Но дело в самой этой структуре. Бросается в глаза, что характеристика это то, что претендует быть атрибутом, а в этой структуре она - значение атрибута "Имя характеристики". Это выглядит как неадекватность моделирования в РМД. Т.е. то что в ПО выглядит как элемент структуры, в этой модели выглядит как значения данных.
В ОР, возможно, бы удалось оставить характеристику как атрибут объекта. Тем более Вы сами говорите про описание в виде объекта. Может быть, это было бы более адекватно. Хотя согласен, что и тут при реализации могут быть неприятные сюрпризы: на сколько хорошо поддерживается ОР на сегодняшний день тоже не очень ясно. Но ведь интересно.