Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, BVA, Вы писали:


PD>>>А в нем факультеты, значит table faculty с FK на institute. Ну и прочие таблицы — бухгалтерия, отдел кадров и т.д.

BVA>>А вы уверены, что вам нужны отдельные таблицы?
BVA>>То что вы описываете, это оргструкрура.
BVA>>Вуз -> Подразделение -> Дочернее подразделение ... -> что-то
BVA>>Это все ложится в одну таблицу, просто со ссылкой на parent и типом строки.

PD>Не понял.
PD>У вуза десяток, а то и больше полей — название, адрес, реквизиты и пр.
PD>У факультета несколько полей — название, корпус и т.д.
PD>У группы полей немного — название скорее всего, и только.
PD>У отдела кадров свои поля, у бухгалтерии свои

PD>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?

Попробуйте написать список полей для каждой сущности, потом проверьте, на сколько они нормализованы и на сколько совпадают. Из того, что описали не совсем понятно в чем проблема.

После нормализации, таблица иерархии у вас точно будет содержать id, название, тип, id родителя, id руководителя/старосты, возможно что-то еще общее для всех уровней.
Адрес это обычно отдельная сущность (и он будет на каждом уровне иерархии, что бы например у той же бухгалтерии была возможность переехать в отдельное здание).
Реквизиты вуза — пока не понятно, что это. Если это лицензия — то скорее всего это будет тоже отдельная таблица в которой будут все лицензии полученные вузом.

По поиску — тоже нужно понять, какие сценарии использования подразумевают поиск?

Да, еще стоит погуглить по словам
Table-Per-Type
Table-Per-Concrete
Table-Per-Hierarchy