BelyА вы переименуйте таблицу "Менеджеры" в "Пользователи" и будет вам счастье.
Давайте объясню еще понятнее. У одного администратора вообще нет доступа на вставку/изменение/удаление к таблице, где хранятся данные о том, кто чей менеджер, какие ФИО и прочие настройки. Он рулит только доступом к системе. Потому что таких систем у него десяток, все они на одном сервере, необходима прозрачная идентификация в домене и еще миллион других причин вплоть до большого объема работы, если в конторе 10000 человек и 50 филиалов. У второго администратора (а вторых, как и первых, может быть много, например, каждый отдел кадров в своем филиале может играть эту роль) задача функционального администрирования. Они имеют полномочия вносить изменения в ФИО, кто чей менеджер и т.п, но не могут рулить доступом к системе.

BelyА что касается реквизитов человека, то заводить отдельную таблицу где будет только ФИО одним полем (к примеру) - считаю нецелесообразным.
Опять же могут быть разные ситуации. Например, информация о субъекте может быть на нескольких языках, может необходимо хранить историю изменений, и т.п. Про "одним полем" - не в тему.

BelyЯ написал "применяют оба этих подхода". Или вы с этим не согласны, что два подхода применяют? :)
Применять и "делать сразу правильно, чтобы потом не было мучительно больно за бесцельно прожитые годы" - две больше разницы. С точки зрения стурктуры БД сделать сразу контроль доступа к данным отдельно от самих данных вообще не представляет проблем. Контроль доступа к "менеджерству" - это только один очень частный случай. Ничем от контроля доступа к справочнику контрагентов, номенклатуры и т.п. он по сути не отличается.

BelyЕсть и другая пословица: Стрелять из пушки по воробьям
Они здесь неприменима, так как нельзя утверждать, что затраты на реализацию одного способа сильно больше затрат на реализацию другого способа. А случае более или менее сложной системы реализация "сразу правильно" выигрышна в разы, потому что система контроля доступа тиражируется как минимум на все справочники.

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

BelyВот вам пример. Система управления подъездной дверью в жилом доме.
Мы находимся в "Проектирование БД". К чему эти неуместные примеры?
Впрочем, если Вы хотите прикрутить к двери БД, тогда надо в нее складывать и заказы на изготовление новых магнитных карт взамен утерянных, и ввод новых пользователей со всеми вытекающими последствиями. Новый пользователь - все проверки - квалифицированный оператор. Заказ на еще один ключ - берем студентку с урезанными полномочиями. Также ничто не мешает одной конторе обслуживать несколько домов, а пользователю такой системы ходить в несколько подъездов по одной карте .

Bely90% функционала описанного вами - просто не будет востребовано никогда и никем, а значит время потраченное на его разработку - было бессмысленное.
Если речь о студенческой самописке - очень даже может быть. Но если контора занимается системами контроля доступа и работает не только с "бюджетными" пятиэтажками, но и элиткой и предприятиями - Вы не правы.

BelyСергей ВаскецовВы не правы.Считайте что я не прав, ваше дело.
При чем тут мое или не мое дело? Вы в качестве аргумента, судя по всему, предлагаете простейшую систему, где вообще нет никакого разграничения прав доступа. Ведь в Вашем примере права доступа относятся не к БД, а БД используется для хранения прав доступа. А раз так, то совершенно не важно, как НЕ делать разграничение прав доступа, можно его НЕ делать универсально и отдельно от данных, можно его НЕ делать по месту и вместе с данными.