Все очень простоЭто не словоблудство, а именно особенности реализации ПИ
Эти особенности В рамках модели данных или ЗА ними? Напоминаю, мы находимся в "Проектировании БД".

Все очень простоЕсли с точки зрения предметной области допустимо отсутствие главного подразделения (заранне неизвестно, но станет известно потом), то тогда поле будет необязательным
Потребуется дополнительная проверка на стадии, когда для работы необходимо будет точно знать главное подразделение. Видимо, она будет реализована в виде сообщения об ошибке юзеру "выберите главное подразделение из перечня подразделений", когда тот начнет печатать, например, наряд на работу. Напоминаю про негативное отношение автора вопроса к ручному коду SQL, а также про старика Оккама. Сравните с простейшим решением "npp=0 только для главного подразделения".

Все очень простоНу так его npp=0 тоже ведь нужно устанваливатью и заранне тоже может быть неизвестно какое главное
Это не принципиально, важно только наличие детерминированной сортировки и принципиальной возможности установить/добавить любое подразделение главным в любой момент, если только заранее сильно не обгадиться. Под "обгадиться" я здесь понимаю, например, установить неглавное подразделение со значением npp=maxint и договоренностью, что главным считается первое подразделение в соответствии с сортировкой order by npp desc,id (это еще и намек, что логику сортировки можно немного "подвигать", пока решение не принято), так что главное со значением maxint+1 уже не удастся вставить. В этом смысле использовать в качестве главного подраздедления запись с максимальным значением npp может оказаться удобнее, даже можно в известной степени npp формировать полуавтоматически начиная с маленьких целых значений.

Все очень простоКак в этом случае использование npp=0 может облегчить жизнь? Не говоря уже о том что пользователь по не знанию или намеренно может ввести несколько главных из-за чего, например, перестанет рабоать часть функционала. Что тогда?
Из "npp=0 только для главного подразделения" не следует, что "если у подразделения npp=0, то оно главное". Понятно, что тонкости начинаются в тот момент, когда у двух подразделений с претензиями на главенство одинаковое значение npp (и в ощем случае не обязательно равное нулю). А облегчить жизнь это может существенно. Смысл в том, что подчас формализовать что-то сложнее, чем только лишь объяснить это юзеру. Пользователи обычно знают, какое подразделение главное, а какое - нет. И если человек внес неглавное подразделение с npp=0, или два разных человека внесли (каждый свое, как кто думал) главные подразделения с npp=0, главным будет только одно, зато видно будет, кто как и почему обгадился. А то, что перестанет работать часть функционала, как-то не верится, если только заранее не делать слишком сильных допущений. Также как и в Вашем случае, в том месте, где определяется главное подразделение, логика определения главного подразделения должна быть единой. Пусть это отдельное поле, пусть это функция - пока что не принципиально. Важно только, чтобы алгоритм определения главного подразделения возвращал детерминированный результат, не зависящий от настроения админа, фазы луны и тонкостей поднятия дампа. Если это будет реализовано - ничего никогда не отъедет.

Все очень простоЯ считаю дурным тоном зашивать ассосиации между сущностями (связи) в логику приложения. Очень сложно будет поддерживать такую систему. ИМХО предметная область по возможности должна по максимуму отражаться в модели данных.
В данном сообщении есть внутреннее противоречие. Оно заключается в том, что модель данных всегда зашита в логику приложения. Поэтому деваться некуда.

Все очень простоА вот здесь я тебя не понял. Каким это образом в моем варианте связь "Главное подразделение" зашито в логику приложения?
Очевидно, в приложении есть ОТДЕЛЬНОЕ ВЫДЕЛЕННОЕ ПОЛЕ для отображения и редактирования ссылки на главное подразделение. Это поле специально сделано для главного подразделения, и если поля в интерфейсе нет, а в модели оно есть, никому от этого легче не станет.

Sgt.PepperОбычно считается, что МД отделена от приложения
Не знаю, кем это так считается. По-вашему, любое приложение может работать на любой МД?

Sgt.PepperКакое из них главное - то, которое вернет сервер по top 1?.. с order by по какому аттрибуту?..
Я же писал примеры. Например, order by npp, id_cust. Или другие, например, с npp desc. Важно только, чтобы npp было первым полем, и чтобы комбинация полей была уникальна.

Sgt.PepperНу, допустим, он вернет c id_cust=1, но тут юзер посчитал, что это неправильно, какие ему сделать движения, чтобы главным стал id_cust=2?
Очевидно, раз на значение id_cust повлиять нельзя, то надо изменять npp. Например, уменьшить у главного или увеличить у неглавного, если сортировка по npp по возрастанию.

Sgt.PepperПо моему с МД (а лучше сказать просто РБД) может работать несколько приложений именно потому что данные отделены от приложений и это считается большим достижением в инфотехнологиях. Для Вас это новость?
Сравните с тем, что Вы написали Выше ("Обычно считается, что МД отделена от приложения"). По-вашему, данные и модель данных - это одно и то же?

Sgt.Pepper Сергей ВаскецовОчевидно, раз на значение id_cust повлиять нельзя, то надо изменять npp. Например, уменьшить у главного или увеличить у неглавного, если сортировка по npp по возрастанию.
Так решения нет?.. Вы на ходу придумываете?..
Вообще-то в моем предложении ИЛИ разделяет 2 возможных решения, выбирайте любое, какое нравится. Результат - нужное подразделение станет главным - в обоих случаях будет достижим. И придумываю я не находу, а уже как 2-ю страницу пытаюсь это донести для неумеющих пользоваться глазами и мозгом.

Sgt.PepperНу вот Вы говорите в приложении будет поле для главного подразделения. Какие действия с вышеуказанной таблицей должны произойти при его (поля) изменении?..
по шагам, для тупых, пожалуйста... :)
Я как раз не говорил, что надо делать отдельно поле для главного подразделения, если это только для галочки, что оно "главное". Но если уж хотите, то при его изменении, видимо, должно выполняться нечто типа update rabota set id_main_cust=N where id_rabota=M. За один шаг.

Sgt.PepperКак все запуталось!
Отмечу, после Вашей неверной предпосылки "Ну вот Вы говорите в приложении будет поле для главного подразделения". В случае процитированной Вами таблицы с NPP никакого отдельного поля "Главное подразделение" нет ввиду его ненужности.

Sgt.Pepper Сергей ВаскецовЯ как раз не говорил, что надо делать отдельно поле для главного подразделения, если это только для галочки, что оно "главное".
А здесь?
Это было развитие "конкурирующей" идеи. За нее пусть отвечает ее автор.

Все очень простоникак не отражается в модели данных а хранится только в логике приложения.
Пожалуй, я пасану.

Sgt.PepperПросто прелесть!.. Так значит "update rabota set id_main_cust=N" вернет ошибку?..
Смех без причины?

Sgt.PepperОК, но что-то есть, что помогает юзеру сказать "А вот это будет главное"?..
Да. В перечне подразделений оно будет первым. Или последним. Как захотите. Если сделать функцию, возвращающую по работе ее главное подразделение, можно и отдельно его отображать.

Sgt.PepperПо-моему у Вас вышло бы быстрее если бы Вы вместо последних двух страниц описали последовательность действий :)
По-моему, кто хотел, уже все давно понял. И таблица, и что делать - все давно написано.

Sgt.Pepper Сергей ВаскецовСмех без причины?
Не, ну правда, Сергей, почему без причины. Вы написали update, который использует несуществующие поля типа id_main_cust. Или оно нужно? Ответьте определенно и тогда разговор можно продолжать в серьезном ключе, без смеха...
Вы считаете, что каждому новоприходящему в топик я должен все разжевать по новой? Попробуйте прочитать все, невзирая на многабукав. Если это не поможет понять, почему и когда работает то, что я предлагаю, очевидно, объяснение, что нельзя выдергивать фразы из контекста и путать два разных контекста Вам тоже не поможет.

Sgt.Pepperпросто скажите (да/нет) нужен атрибут id_main_cust в таблице Работа-ПЗ (подразделение заказчика)
----------------------------------------------
ID_JOB_Customer
ID_JOB
ID_Customer
NPP
?
не нужен.