StalkerSНеобходимо сконструировать базу деталей. Разновидностей деталей около 50, т.е. болты, трафареты и т.д. Разумеется, они имеют разное количество характеристик.

Хотелось-бы услышать Ваше мнение по поводу того, что является более рацональным решением - создать 50 таблиц (по таблице на каждый вид), или создать одну таблицу, запихать в нее все возможные характеристики, а в неиспользуемых полях для конкретного типа использовать null.

Я бы сделал ЧЕТЫРЕ таблицы:
1. Детали (болты, трафареты и т.д.)
2. Характеристики (длина, ширина, толщина и т.д.)
3. Характеристики деталей
4. Единицы измерения

Структура таблиц:
1. Детали ; поля PartID, NamePart
2. Единицы измерения ; поля IzmID, NameIzm
3. Характеристики ; поля CharID, IzmID, NameChar
4. Характеристики деталей ; поля PartID, CharID, Value

При этом, возникает следующая схема данных (стрелочки указывают соответствующие связи (Relations)):

Детали -> Характеристики деталей <- Характеристики <- Единицы измерения

В чем достоинства данной схемы:
- Она расширяема;
- Разные детали могут иметь разное количество характеристик
- Не надо хранить значение Null

В чем недостатки данной схемы:
- Для просмотра/ввода характеристик деталей надо написать соответствующий Select и поместить его во View...

Sergey_SKto Станислав C.
уточните пожалуйста:
Value - какой тип предполагается varchar, float, sql_variant?...
Если Вы заметили, то я не прописывал типы полей. Оставил это на откуп разработчику. Хотя, насколько я понял из первого сообщения топика, здесь подошел бы тип float...
Sergey_SKto Станислав C.
... надо понимать что хранение характеристик не самоцель, вероятно потом нужно будет и расчёты вести расхот, отход, незавершёнка там, да и в разных единицах, кому надо будет в штуках кому в килограммах...
Я бы согласился с Вами, но стояла задача именно сконструировать базу деталей... Приведите мне пример, когда моя схема не сработает... Кроме того,как я уже говорил, предложенная мной модель является расширяемой. Если необходимы пересчеты между единицами измерения, то, наверное, можно ввести коэффициент пересчета, например в виде еще одной таблицы:
а в программе выбирать нужный коэффициент и делать преобразование...

Sergey_SKДа схема замечательная...
если б единственной задачей было найти и распечатать характеристики.
Но на основе этих характеристик потом нужно будет вести расчёты,
Подробностей расчёта - престчёта ни кчему, приведённые мной примеры расчётных задач это только чтоб показать достаточную серьёзность необходимых расчётов.
Был задан КОНКРЕТНЫЙ вопрос:
автор
Необходимо сконструировать базу деталей . Разновидностей деталей около 50, т.е. болты, трафареты и т.д. Разумеется, они имеют разное количество характеристик.

Хотелось-бы услышать Ваше мнение по поводу того, что является более рацональным решением - создать 50 таблиц (по таблице на каждый вид), или создать одну таблицу, запихать в нее все возможные характеристики, а в неиспользуемых полях для конкретного типа использовать null.

Не расширяйте трактовку вопроса. А то ведь так можно расширить его и до CASE-системы...

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

Я не указывал типы полей специально, чтобы указать лишь ИДЕЮ реализации, а не конкретную реализацию. Разработчик, у которого есть голова, возмет ИДЕЮ и, немного модифицировав, применит ее в своей конкретной ситуации, а не будет ждать готового решения...

Sergey_SK
Вот вы предполагаете тип flоat, а как быть с:
1. постоянное вываливание на клиенте в экспоненциальный вид,
2. точность вычислений скажем так, оставляет желать лучшего(это ведь приближённый тип) ?
просто может я типом float пользоваться не умею и поэтому везде где нужны рачсёты пользую decimal.
Это опять же идет речь о КОНКРЕТНОЙ РЕАЛИЗАЦИИ. (мне почему-то кажется, что на SQL Server'e). Соглашусь, МОЖНО использовать тип decimal. Хотя, также НЕ ЗАПРЕЩЕНО использовать и типы char, varchar и др. и проводить преобразование по мере надобности....

Sergey_SK
именно о конкретно ВАШЕЙ реализации и идёт речь,
схема так красиво описана что я смел предположить что она была вами использована на практике.

Конкретно ЭТА схема не была реализована на практике. Но было реализовано несколько подобных при адаптации КИС "Эталон" (ДОС-версия) для нужд нашего предприятия. А конкретно при описании задачи "Производство"...

Sergey_SK
Данная схема давно известна, только вот стоит ли с ней заморачиваться в серьёзных проектах... а вот чтоб кто-то сказал что он её использовал как ядро проекта и не пожалел об этом я ещё не слышал...
Долой реляционную модель из практики! Даешь денормализацию!