Все очень простоА если хранить ссылку на элемнт перечня работ ? Проверять ничего не надо это БД проверяет.
И при удалении "главного" подразделения из перечня работ...?

Все очень простото 2-й вообще ничего не будет гарантировать, т.е. будем иметь несоклько главных подразделений
Лучше сначала разобраться, а потом критиковать. Подразделение главное всегда одно.

Все очень простотрудно(много кода, накладно для базы) реализуемый
Что-то я не понял. Надо написать один раз index и поправить запрос получения главного подразделения в части добавления top 1. Это сложно? Это сложнее, чем писать "по уму" триггер, что светит автору, если проверку нельзя сделать constraint-ом?

Все очень простоНасколько я понял мы говорим о многопользовательском домтупе к БД.
Многопользовательское чтение?
Многопользовательское редактирование состава подразделений в рамках одной работы?
Продолжать?

vitaliy142 вариант - проблем с редактированием нет, но прийдется на клиенте проверять,чтобы пользователи два ПЗ не сделали главными
Главное подразделение может быть всегда только одно даже в том случае, если два значения npp в перечне подразделений совпадают. Просто в этом случае для его определения потребуется использовать еще одно поле (гарантированно уникальный хотя бы в рамках одной работы идентификатор). Например, select top ... order by ... Идея тривиальная же. Важно только, чтобы можно было всегда сказать, какое главное.

Сергей Васкецов Все очень простоА если хранить ссылку на элемнт перечня работ ? Проверять ничего не надо это БД проверяет.
И при удалении "главного" подразделения из перечня работ...?
А также является ли ссылка (главное подразделение) на "дочерний" перечень с подразделениями обязательным полем?

vitaliy14Брррр... какой еще идентификатор!? В таблице связи перечня работ? напишите, пожалуйста , пример
Пример я уже писал:
order by npp,ID_Customer.
ID_Customer можно заменить на ID_JOB_Customer.

Если в интерфейсе и в определении главного подразделения будет одна и та же сортировка, то то подразделение, которое будет в интерфейсе первым, всегда будет главным с точки зрения логики выбора главного подразделения.

vitaliy14А если на самом деле главное id_customer = 5 !?
Если исходить из того, что главное подразделение в интерфейсе всегда первое, то значит для обеспечения "главности" этого подразделения потребуется указать правильные значения npp. Важно только, что ЭТИ ЖЕ значения приоритетов будут использоваться в логике, которая требует определения главного подразделения. И что сервер не сможет возвращать результаты, как ему вздумается, а будет гарантирован порядок возврата используемых подразделений и, следовательно, детерминированность главного подразделения.

Все очень простоМожно устанавливать в NULL средствами БД (.. on delete set NULL)
Можно. Но тогда возникает необходимость дополнительной проверки, а установлено ли для работы главное подразделение. Тогда как в моем случае достаточно указания хотя бы одного любого подразделения, самое первое будет автоматически главным.

Все очень простоТ.е. ты хочешь сказать что если их будет несколько то главным выберется тот , который понравиться серверу TOP 1 ? Ну это же полная чушь!!
Именно что чушь. Именно для этого я и написал про order by. Комбинация полей в секции order by будет УНИКАЛЬНА. Так что никакого произвола в здравом уме со стороны сервера не предполагается.

Все очень простоИмелась ввиду именно многопользовательская запись
Не понял. Где конкретно засада? Даже если в страшном сне предположить, что наряд на работу редактируется одновременно несколькими пользователями, то почему сложнее будет редактировать один список, а не тот же список + еще одно дополнительное поле? Если список не тот же (фактически, без npp), то как в Вашем случае Вы будете объяснять тупым юзерам, почему сервер выдает подразделения в произвольном порядке?

Все очень простос одинаковым порядком сортировки по которому у тебя определяется главное подразделение
Очевидно, Вы что-то недопоняли. То, что Вы пишете, невозможно реализовать даже десяти пользователям. Попробуйте еще раз понять, почему это так.

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

Все очень простоВ вашем случае очень легко два пользователя одновремнно вставляют две записи с одинаковыми npp + какой-то идентификатор. База данных им этого не запретит уникального индекса в данном варианте нет. Что может помешать им сделать это?
Ничего не сможет им помешать, если только они не вставят одно и то же подразделение. Но из этого не следует, что оба подразделения будут главными. Более того, этот вариант разруливается на корню даже для подобных Вам эстетов, если юзерам объяснить, что npp=0 можно использовать только для главного подразделения.

Все очень простоЧто и требовалось доказать. А в предложенным мной вараинте БД им этого не позволит сделать.
Я не понимаю, на каком языке Вам написать, чтобы Вы соизволили прочитать то, что я Вам пишу как минимум дважды. Если не желаете читать и думать - ради бога. Только не надо думать, что я считаю предложенный способ с npp лишенным всяческих недостатков. Я всегда знаю о недостатках того, что предлагаю. Просто я считаю способ с выделенным атрибутом главного подразделения для выбора одного из подразделений из перечня совсем неудачным, если учесть контекст обсуждения и нежелание возиться с триггерами (то есть, нежелание писать код SQL руками). И если от одного из подразделений только лишь и требуется, что считать его главным, то смысла городить какой-то дополнительный огород вообще не вижу.

Все очень простоТо что я предложил это называется модель данных , а то что вы предлагаете это вынесение модели данных в логику приложения. Чувствуете разницу?
Я вообще не понимаю, к чему подобные высокопарные слова и чушь про многоюзерность, если Вы не понимаете, что согласно Вашей же модели главное подразделение должно быть обязательным, а раз в рамках модели данных этого добиться нельзя (ибо нельзя сделать ссылку на несуществующую сущность), то реализация этого (контроля, что не нафигачили подразделений без указания главного) будет ЗА рамками Вашей же модели данных.

Все очень простоЭто поле можно сделать обязательным.
Уф.
1. Состояние работы "есть хотя бы одно подразделение в перечне подразделений, но нет главного подразделения" является ошибочным с точки зрения логики.
2. Состояние работы "главное подразделение указано, но отсутствует в перечне используемых подразделений" является ошибочным исходя предположения и сути такого перечня (см. мой комментарий сильно выше в топике).
3. Если есть желание первым указать неглавное подразделение, исходя из 1 необходимо бить юзера по рукам и запрещать это делать.
4. Если есть желание указать в перечне подразделений главное подразделение, то в момент вставки записи оно должно "скопироваться" в поле "главное подразделение", иначе будет нарушение 1.
5. Если есть желание указать главное подразделение непосредственно в предназначенном для него поле, то необходимо в момент изменения значения данного поля вставить новое значение главного подразделения в перечень всех используемых подразделений, иначе будет нарушение 2. Что делать со старым значением - вообещ непонятно, то ли удалить его из перечня подразделений, то ли оставить.
6. Удалить главное подразделение непосредственно из перечня подразделений нельзя, так как нарушится обязательность поля и (может быть) 1.

Итого:
а) только лишь за пункт 3 я бы уже отказался от обязательности поля в модели.
б) ни 4, ни 5 нельзя реализовать без дополнительного написания кода, выходящего ЗА рамки собственно модели данных.

Все очень просто1. Состояние работы "есть хотя бы одно подразделение в перечне подразделений, но нет главного подразделения" является ошибочным с точки зрения логики.
Если поле сделать обязательным то такого состояния не будет

2. Состояние работы "главное подразделение указано, но отсутствует в перечне используемых подразделений" является ошибочным исходя предположения и сути такого перечня (см. мой комментарий сильно выше в топике).
Выше по топику я писал что ссылка указывается не на само подрпазделение, а на злемент из списка связанных подразделений. Поэтому данная ситуация не допустима

3. Если есть желание первым указать неглавное подразделение, исходя из 1 необходимо бить юзера по рукам и запрещать это делать.
В моем варианте можно связывать с подразделениями и выбирать главный в любом порядке(не только первым)


Если главное подразделение А, а кроме него есть также Б и В, каким образом можно указать в работе подразделения Б и В, а на следующий день указать подразделение А в качестве главного?

Все очень просто
4. Если есть желание указать в перечне подразделений главное подразделение, то в момент вставки записи оно должно "скопироваться" в поле "главное подразделение", иначе будет нарушение 1.
Это особенности реализации пользовательского интерфейса

Выходящее ЗА рамки модели. Что и требовалось доказать. Прочее тоже выходит за рамки модели. Обзывать это "особенностями реализации пользовательского интерфейса" можно, но бессмысленно, это просто словоблудство. Тем более что Вы сами пеняли мне этим выше. Итого, то, что Вы предлагаете, не может быть моделью данных как таковой.

Все очень простоЕсли главное подразделение А, а кроме него есть также Б и В, каким образом можно указать в работе подразделения Б и В, а на следующий день указать подразделение А в качестве главного?
Не понял вопрос. В любое время у работы должно быть одно и только одно подразделение. Это и описывается моделью. Если сегодня одно подразделение главное, а завтра другое, то просто меняешь одну ссылку на другую.
Как можно было не понять столько четко сформулированный вопрос?
1. Согласно задаче автора, у работы может быть сколь угодно много подразделений (фактически, больше нуля), но обязательно есть одно главное подразделение.
2. Подразделения Б и В не являются главными.
3. Главным является подразделение А.
4. Есть желание главное подразделение указать ПОСЛЕДНИМ среди всех подразделений. До этого никаких главных подразделений нет, ни Б ни В им быть не может. Это не какая-то фантастическая ситуация. Например, главным подразделением является контролирующее подразделение, какое именно оно будет - заранее неизвестно (ОТК). То есть это вполне житейская ситуация, не выходящая за рамки задачи автора.

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