Здравствуйте, bastrakov, Вы писали:

B>Здравствуйте, KRA, Вы писали:

KRA>>..моя практика показывает, что поддерживать эти тригеры несложно — у меня по крайней мере, с этим проблем не возникало.

B>моя практика показыват, что проблемы с тригеррами начинаются у людей, которые работают с приложением _после_ ухода того, кто помнит про триггеры.
B>вспоминают его трехэтажными словами, после пары дней поиска банальной подмены данных на insert. bo

Не нужно перегибать. Так можно почти любую возможность забраковать, если ею пользоваться неправильно. С этими тригерами проблем нет, потому что они всего лишь не дают сделать бяку (делают проверку), если попытаться её сделать.

Здравствуйте, Neco, Вы писали:

N>>>что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе
L>>Праааавильно. Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
N>ну так в предложенной мной схеме для переноса требуется один апдейт одной строки таблицы enter_object и переносятся сразу один вход и две зоны.

Пардон. Нихт фирштейн? Я вроде написал, что мне ни чего не надо переносить. И задача состоит совсем в другом. причем написал уже 2 или 3 раза.

Здравствуйте, KRA, Вы писали:

L>>>Описание предметной области:

B>>я 3 раза перечитал весь топик. ...и нифига не понял.
еще раз уточняю, что описания я не понял, поэтому дальше по вашим уточнениям иду.

B>>1) почему "вход" связан в обьектом? он должен быть связан с зоной. точнее с 2-мя зонами, которые он разделяет. и какие это обьекты — его волновать не должно.
KRA>Это из предметной области. Есть два объекта "завод" и "фабрика". И одного и другого есть по две зоны "двор" и "цех". Так вот, не существует входа из двора завода в цех фабрики. И именно это ограницение хочется иметь на уровне БД.

"входа из двора завода" — привязан к заводу.
"входа в цех фабрики" — привязан к фабрике.
у них просто нет точек пересечения.

если вы создадите "вход(id=1)" — связанный с "двором" (который уже привязан к "заводу"), и создадите "вход(id=2)" — связанный с "цехом" (который уже привязан к фабрике). то у вас просто будут разные обьекты.

B>>2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна.
KRA>это не понял.

ALTER TABLE моя_таблица
ADD CONSTRAINT имя_моего_ограничения UNIQUE 
(
вход,
обьект
);

там может быть хоть все поля таблицы в ограничении на уникальность.

во

Здравствуйте, Neco, Вы писали:

L>>Те же яица, вид с боку. Проблема в том, что в таблице [area] зона1 принадлежит какому-то [object] т.е. там есть
L>>id name fk_object
N>вот как раз этого fk_object и не должно быть (по крайней мере на него не должен навешиваться ограничивающий функционал).

N>для чего обычно такие ключи добавляют в справочные таблицы?
N>1. для того, чтобы по выбранному объекту отобразить список зон исходя из выбранного объекта
N>2. для того, чтобы перенести зону с одного объекта на другой "единым движением"

Функция 1 как раз самая важная и без неё думаю никак нельзя. Дело не только и не столько в отображении (отображение это следствие), дело в наличии связи между объектами, и представления этой связи в БД. Ваше решение ф-цию 1 не поддерживает, а потому врядли годится.

Здравствуйте, bastrakov, Вы писали:

B>Здравствуйте, KRA, Вы писали:

L>>>>Описание предметной области:

B>>>я 3 раза перечитал весь топик. ...и нифига не понял.
B>еще раз уточняю, что описания я не понял, поэтому дальше по вашим уточнениям иду.
см. ниже

B>"входа из двора завода" — привязан к заводу.
B>"входа в цех фабрики" — привязан к фабрике.
B>у них просто нет точек пересечения.

B>если вы создадите "вход(id=1)" — связанный с "двором" (который уже привязан к "заводу"), и создадите "вход(id=2)" — связанный с "цехом" (который уже привязан к фабрике). то у вас просто будут разные обьекты.

Расширим немного пример. Есть завод. У него есть зоны двор, цех, будка_охранника, склад.
Есть два входа из двора в цех. Один из двора в склад. Один вход из двора в будку. Ещё есть вход из цеха в склад.
Вход не просто привязан к одной зоне. Он привязан сразу к двум зонам (двор, цех). И обе эти зоны должны пренадлежать одному объекту (в даном случае заводу). Нельзя сделать вход из зоны пренадлежащей фабрике в зону пренадлежащюю заводу.


B>>>2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна.
KRA>>это не понял.
B>там может быть хоть все поля таблицы в ограничении на уникальность.

Смотрите выше. Такого вида ограничения для решения задачи не помогут. Или, я, по крайней мере, не вижу как.

Здравствуйте, KRA, Вы писали:

KRA>Расширим немного пример. Есть завод. У него есть зоны двор, цех, будка_охранника, склад.

все. дошло. записать на будущее: если дофига работы — в форумы не писать.
ну вообщем сложно все получается.

1) constraint по значению невозможен с подзапросом. ...а жаль.

2) ну триггер все же видимо надо написать. самый простой выход.

3) если колдовать над схемой (как было в начале) то у меня получилось другое:

ворота:
-вход
-зона

связки:
-обьект1
-вход
-обьект2

т.о. пофиг где одна зона, обе будут привязаны к той, где ворота.
p.s. sorry. в легком цейтноте. во