vovan_z _мод
Изделие - это одна сущность. Ессно разные типы одной сущности имеют разные атрибуты, но это видно только на экране, а в БД д.б. одна таблица на одну сущность.
Аргунемент начальника таков - что типа если я все свалю в одну табилцу, все атрибуты этих одинаковых (а он грит разных) сущностей то начнется каша, и будет не понятно какие поля к одному типу, а какое к другому, и пришедший после меня человек не разберется никогда. И еще получается не нормализованная схема, т.к. запись в таблице имеет поля, которые к этой записи не относятся.
В общем я так понимаю что надо выбрать подход:
1. Нормализованная схема, но неудобно с ней работать
2. Не совсем нормализованная, но зато очень удобная для работы
третьего не дано!

Я правильно понимаю?
имхо стоит хранить все подразделения в одной таблице - таблице которая будет описывать сущность подразделения. по мне так все подразделения вне зависимости от их уровня есть сущности одного рода.
с другой стороны если по логике бизнес процессов это различные сущности то разделение таблиц оправдано. но не знаю что то причин считать их различными сущностями.
по моему любое организационное подразделение имеет одни и те же характеристики - название, уровень в ОАО, начальник, зам, сотрудники... но эти свойства имхо лучше не хранить в той же таблице, а хранить эти сущности в отдельной таблице и связывать их при помощи кросс-таблиц с таблицей подразделений. вроде бы это классический способ описания организационной структуры

vovan_zт.е. правильный подход таков:
Сделать древовидный справочник подразделений с полями скажем:
pod_id (PK)
pod_name
podtype_id (FK ссылка на тип подразделения)
pod_par_id (ссылка на pod_id) для оргинизации дерева

и потом сделать для каждого типа подразделения с различными атрибутами свою таблицу атрибутов.(например filial,office...)

Все так думают?
http://www.sql.ru/forum/actualthread.aspx?tid=507182&pg=-1

тема по моему для тебя