Есть 3 таблицы
tprcs - процессы и их описание
MAIN1 - структура изделия, дерево
spztmp - описывает какой процесс назначен для выполнения на эту деталь на этом изделии
уникальный номер детали - codever
Есть ли возможность какими-нибудь ключами, индексами или еще как обеспечить чтобы при занесении в spztmp записи о назначении процесса значения codever в MAIN1 и tprcs были одинаковыми?
Пока все решается проверкой через код, но может быть можно и по другому?
PS - очень прошу, не надо вопросов зачем мне это надо и почему все организовано так а не иначе

Спасибо.... буду пробовать, но пока совсем не понимаю как....

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

Это неочевидно. Более того - невозможно. И не относится к теме данного топика уж точно. Буду очень благодарен, если кто-нибудь поможет вместо обсуждения структуры составить инструкцию ALTER TABLE ADD CONSTRAINT...

to ПЕНСИОНЕРКА - Хорошо
Таблица MAIN1
Code
OWN код узла и его вышестоящий код - для создания дерева изделия
sernn - уникальный код главного изделия(главной сборки)
codever - уникальный код детали
qt - количество деталей в узле
остальные поля ИМХО несущественны для решаемой задачи

Таблица tprcs
CODE - уникальный код процесса
CODEVER - уникальный номер детали, для которой создан процесс
Остальное - несущественно

Таблица spztmp
CODE - уникальный код записи, в дальнейшем нигде не используется, подумываю удалить
CODM1 - CODE из таблицы MAIN1
cdtp - код назначенного к выполнению для этой детали именно в этой позиции общего дерева изделия процесса
остальное несущественно

Процессов (CODE из tprcs) может быть несколько для одной и той же детали(codever)
На деталь из сборки(code из MAIN1) процесс может быть не назначен, назначен один или назначено несколько процессов

Цель вопроса - предотвратить назначение процессов, разработанных для другой детали.
Как я уже писал - программно через запросы и код я это отслеживаю, но хотелось бы использовать возможности SQL и заодно научиться новому....

На той схеме, что вначале видно, что связь именно по ключевым полям


На той схеме, что сверху я не показал много таблиц, и в честности таблицу VERS с ключевым уникальным полем CODE (codever во всех остальных таблицах), по которому и осуществляется связь с ними
Надеюсь, что из поста выше станет понятно, почему codever присутствует и в табл MAIN1 и и в TPRCS.

Картинка эту я нарисовал для этой темы и пропустил при рисовании , в реальности там правильная связь, такая же как и правая

Мы что сейчас обсуждаем? Спасибо за информацию, но я был бы вам значительно более благодарен, если бы вы помогли реально, а не переводили тему непонятно куда и непонятно зачем.

Darkman, Я задал простой в общем вопрос, точно описал какие поля, где что и как. Не надо тут копаться нигде, не надо обсуждать названия полей, не надо обсуждать структуру базы - вопрос касается только 3-х таблиц.
ЗЫ если не знаете, как помочь реально, то и правда, лучше здесь не писать, не оффтопить.

Mea culpa... confiteor...



Думал про подобное - это действительно самый простой выход. НО очень хотелось(хочется:)) ADD(CHECK) CONSTRAINT понять и научится применять...

Убедили, не буду удалять...

Попробовал так


Выдает ошибку - Ошибка синтаксиса в предложении ограничения CHECK №№ -217217900
Кто поможет разобраться?
Зы - простые CONSTRAINTы научился создавать и удалять

Я естественно знаком с этими понятиями в меньшей степени, чем Вы. И я естественно внимательно прочитал то что вы написали - Второе, требующее анализа и изменения структуры - заново провести анализ. Если появилось требование безуслов6ного соответствия - значит, codever является атрибутом либо сущности из tprcs, либо сущности из MAIN1, и должно присутствовать только там, а для сущности другой таблицы оно должно получаться по связи.

И считаю, что дал объяснения почему все так вот здесь
Таблица MAIN1
Code
OWN код узла и его вышестоящий код - для создания дерева изделия
sernn - уникальный код главного изделия(главной сборки)
codever - уникальный код детали
qt - количество деталей в узле
остальные поля ИМХО несущественны для решаемой задачи

Таблица tprcs
CODE - уникальный код процесса
CODEVER - уникальный номер детали, для которой создан процесс
Остальное - несущественно

Таблица spztmp
CODE - уникальный код записи, в дальнейшем нигде не используется, подумываю удалить
CODM1 - CODE из таблицы MAIN1
cdtp - код назначенного к выполнению для этой детали именно в этой позиции общего дерева изделия процесса
остальное несущественно

Процессов (CODE из tprcs) может быть несколько для одной и той же детали(codever)
На деталь из сборки(code из MAIN1) процесс может быть не назначен, назначен один или назначено несколько процессов

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

Приношу извинения за то , что первоначальная картинка не полностью отражала действительность и привожу то как есть на самом деле

Далее - ваш текст
Первое, очевидное, решение - создание уникального индекса (code, codever) и связывание таблиц именно по этому выражению, а не просто по (code).
Что имелось ввиду? Создать уникальный составной индекс для табл TPRCS из code+codever? Что это даст? code и так уникальный и что не заноси в codever индекс не даст никаких ограничений
В табл MAIN1 уже есть составной уникальный индекс из codever+own+sernn
Связь между таблицами осуществляется по уникальному(счетчик) и ключевому полю
Если я все же ошибаюсь, то прошу меня поправить

Честно сказать - про self-join не слышал в таком контексте
Дерево строится на основании связи code-own..... оно строится..... 15000 поз - 3-5 сек.... Меня устраивает, что не так?




Если убрать sernn запросом по дереву можно получить головную позицию(code по MAIN1) -например 186211. В другой таблице есть информация о том, что наше главное изделие с внутренним номером( sernn)=56 будет смонтировано на изделии заказчика № ХХХХХХ
Как связать эту информацию? Как отобрать необходимые 15-20000 записей именно для этого главного изделия для построения дерева и для других операций? У меня это реализовано, работает быстро, дает мне все нужные мне возможности.
Можно ли сделать по другому - наверное можно, но для этого надо понять что это мне даст в итоге



А вот это, Akina, определяется не Вашим мнением, основанном на безусловно большом опыте, а бизнеслогикой и имеющимися на предприятии в данный момент реальностями. Данная модель данных разрабатывалась под них и им соответствует. В детали здесь вдаваться не буду ибо просто не имею права



Ваше право
Зы - на всякий случай напишу - уже организована и действует передача ресурсных спецификаций и маршрутных карт в ЕРП систему.

Вот этого я не понял....


Вот это - понял. Все именно так, как написано

АА, понял
Типа есть таблица узлы, есть таблица детали и есть таблица - процессы? И они связаны по ключевым полям?
А в сборочном чертеже например есть 15 сборочных единиц(узлов) и 25 разных деталей. В разные таблицу их пихать?
А в тех сборочных единицах также есть сборочные единицы и детали. И так на 8-15 уровней вглубь
Я не представляю как будет работать в этих условиях предложенная вами схема...


А на каждую деталь может быть несколько разных процессов, которые используются в зависимости от конкретных условий, если сделать прямую связь от узла в MAIN1 к процессу - то на каждый узел придется создавать новый процесс и от этого база данных раздуется неимоверно. А я сейчас имею возможность использовать ранее разработанные процессы без лишнего увеличения объема базы, и также одновременно использовать несколько процессов на одну деталь

Потому что я ее не показал. Там вообще около 70 разных таблиц - что всех показывать?
Тут вон три таблицы показал - кипеша на 2 страницы и все не по существу вопроса.
Блин - как а анекдоте - пока ж*пу не покажешь - туалетную бумагу тебе не продадут.....
Все, дальнейшее обсуждение структуры только после того как кто-нибудь знающий поможет мне составить инструкцию ALTER TABLE

При всем уважении..... Ну нет у меня никакого желания и времени дискутировать о почти философских категориях в отвлеченном смысле....
Я знаю одно - моя схема работает и дает нужную информацию в нужном объеме... А как я там это называю - деталь, узел, сборочная единица - без разницы

Sdku - Я ничо в жизни не видел, ничо не знаю, перед вашей мудростью преклоняюсь....
Сделайте пожалуйста такое огромное одолжение..... Помогите ALTER TABLE написать....
Или свалите в туман со своим флудом

У меня есть одно и точно правильное мнение - я нахожусь на Русском форуме, где вместо ответа на вопрос "как это сделать" тебе сначала докажут что это тебе не надо и ты вообще ничего не знаешь.
Вот в меру сил и борюсь с этой особенностью
ЗЫ а про то что могут быть другие глобальные решения которые будут работать(читай - правильные) - я выше писал. Но мое - уже работает и поэтому оно тоже - правильное

Эх! кто ж мне теперь про ALTER TABLE расскажет поможет-то...... Так и зачахну видать......

Да уж, дай спокойно зачахнуть

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

Ты The Bill. На всякий уточню - я не программист, а уж тем более нанятый. Я начальник технологического отдела.( Это не к понтам, а что бы это чудо наконец отвалило в туман и не мешало решать реальные проблемы) Я сам эту систему пишу, я же и главный пользователь и обслуживать ее кто-то кроме меня будет только если меня с должности уволят(чего в принципе никогда нельзя исключить).

Да приготовил уже - сам готов и поставить и проставиться если что))

Выкладываю