vitaliy14но главное только одно ! (для этого есть поле IS_MAIN (yes/no))
Видимо, речь про дополнительную табличку и связь M:N? Так вот, в случае такой таблички есть методы попроще, без IS_MAIN-ов.

vitaliy14Пример бы мне?
Делаете поле типа npp (номер по порядку). При выводе на печать сортируете по нему (все равно определенность нужна, а таким способом легко вручную управлять порядком записей). Главное подразделение - то, которое первое (с минимальным npp). Никаких ненужных триггеров. Если нужна гарантированная сортировка даже при совпадении значений npp, добавляете в перечень полей сортировки идентификатор. Надеюсь, уникальный индекс уже есть в этой таблице по паре полей "работа" и "подразделение"?

vitaliy14Нужно сделать unique индекс по полям ID_JOB - ID_Customer - NPP?
Не-а, только по паре полей ID_JOB и ID_Customer.

vitaliy14И считать NPP c 1 для главного?
Да можно и с нуля. Не принципиально.

Сортировка может быть типа
order by sign(npp) desc,npp,ID_Customer
или
order by npp,ID_Customer.
В первом случае все новые строки с нулевым значением npp будут "падать в конец".
ID_Customer можно заменить на ID_JOB_Customer.
Записей таких по сути немного будет, так что что бы Вы ни выдумали (в части сортировки), для сервера это будет не напряжно.

vitaliy14Два ПЗ главных?
Главное - первое - всегда одно.
Впрочем, можете сделать дополнительный уникальный индекс по ID_JOB и npp, если уж так хочется.

vitaliy14unique индекс только по полям ID_JOB - NPP - чтобы не было двух главных подразделений н а одну работу?
1. Можно сделать уникальный индекс. Тогда при редактировании необходимо будет разруливать ситуацию (на уровне интерфейса, видимо), когда потребуется поменять местами два подразделения.
2. Можно не делать уникальный индекс, а обойтись сортировкой. Для получения главного подразделения использовать select top 1 ...., тогда ошибки нарушения индекса не будет (так как не будет индекса).
3. Можно сделать ссылку на главное подразделение как отдельный атрибут работы. В таком случае потребуется в зависимости от постановки задачи либо проверять, что ссылки на главное подразделение нет в перечне подразделений, либо наоборот, требовать в перечне подразделений ссылку на главное. То есть, в зависимости от логики, список подразделений будет либо списком всех используемых подразделений, либо списком всех вспомогательных подразделений. С моей точки зрения, решение идиотское как по постановке, так и по трудозатратам.

Все очень простоНет Работа должна сылать на главное подразделение
Прокомментировал сообщением выше.

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

Все очень простото 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. Есть желание главное подразделение указать ПОСЛЕДНИМ среди всех подразделений. До этого никаких главных подразделений нет, ни Б ни В им быть не может. Это не какая-то фантастическая ситуация. Например, главным подразделением является контролирующее подразделение, какое именно оно будет - заранее неизвестно (ОТК). То есть это вполне житейская ситуация, не выходящая за рамки задачи автора.

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

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

Все очень простоЕсли с точки зрения предметной области допустимо отсутствие главного подразделения (заранне неизвестно, но станет известно потом), то тогда поле будет необязательным
Потребуется дополнительная проверка на стадии, когда для работы необходимо будет точно знать главное подразделение. Видимо, она будет реализована в виде сообщения об ошибке юзеру "выберите главное подразделение из перечня подразделений", когда тот начнет печатать, например, наряд на работу. Напоминаю про негативное отношение автора вопроса к ручному коду 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, главным будет только одно, зато видно будет, кто как и почему обгадился. А то, что перестанет работать часть функционала, как-то не верится, если только заранее не делать слишком сильных допущений. Также как и в Вашем случае, в том месте, где определяется главное подразделение, логика определения главного подразделения должна быть единой. Пусть это отдельное поле, пусть это функция - пока что не принципиально. Важно только, чтобы алгоритм определения главного подразделения возвращал детерминированный результат, не зависящий от настроения админа, фазы луны и тонкостей поднятия дампа. Если это будет реализовано - ничего никогда не отъедет.