Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, KRA, Вы писали:
L>>>>Описание предметной области:
B>>>я 3 раза перечитал весь топик. ...и нифига не понял. B>еще раз уточняю, что описания я не понял, поэтому дальше по вашим уточнениям иду.
см. ниже
B>"входа из двора завода" — привязан к заводу. B>"входа в цех фабрики" — привязан к фабрике. B>у них просто нет точек пересечения.
B>если вы создадите "вход(id=1)" — связанный с "двором" (который уже привязан к "заводу"), и создадите "вход(id=2)" — связанный с "цехом" (который уже привязан к фабрике). то у вас просто будут разные обьекты.
Расширим немного пример. Есть завод. У него есть зоны двор, цех, будка_охранника, склад.
Есть два входа из двора в цех. Один из двора в склад. Один вход из двора в будку. Ещё есть вход из цеха в склад.
Вход не просто привязан к одной зоне. Он привязан сразу к двум зонам (двор, цех). И обе эти зоны должны пренадлежать одному объекту (в даном случае заводу). Нельзя сделать вход из зоны пренадлежащей фабрике в зону пренадлежащюю заводу.
B>>>2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна. KRA>>это не понял. B>там может быть хоть все поля таблицы в ограничении на уникальность.
Смотрите выше. Такого вида ограничения для решения задачи не помогут. Или, я, по крайней мере, не вижу как.
Описание предметной области:
Есть вход, который располагается на границе зон (из зоны "улица" в зону "дом" = вход №1). Есть зоны, которые располагаются на разных Объектах (строения, стоянки и т.п.), т.е. есть зона "ПРИХОЖАЯ" принадлежащая Объекту "ДОМ" и есть другая зона "ПРИХОЖАЯ" принадлежащая объекту "РАБОТА". Во всей этой ситуации важно, чтобы вход такой то имел сведения из какой зоны в какую он работает, т.е. если мы знаем "Вход №1", то это значит из "УЛИЦА" в "Прихожая".
Это как бы постулаты, и на предметную область по другому смотреть нельзя.
Внимание, вопрос:
Предполагаемая реализация в виде таблиц ->
Вход Зона -> Объект ->
Т.е. у входа есть 2 зоны. А каждая зона знает на каком объекте она находится.
НО. Вход ведь тоже находится на Объекте, и пользователь может в бить в БД что вход разделяет зоны на разных объектах, а такого быть не может.
Как его ограничить в возможности такого ввода?
P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.
Здравствуйте, loknalori, Вы писали:
L>Описание предметной области: L>Есть вход, который располагается на границе зон (из зоны "улица" в зону "дом" = вход №1). Есть зоны, которые располагаются на разных Объектах (строения, стоянки и т.п.), т.е. есть зона "ПРИХОЖАЯ" принадлежащая Объекту "ДОМ" и есть другая зона "ПРИХОЖАЯ" принадлежащая объекту "РАБОТА". Во всей этой ситуации важно, чтобы вход такой то имел сведения из какой зоны в какую он работает, т.е. если мы знаем "Вход №1", то это значит из "УЛИЦА" в "Прихожая".
L>Это как бы постулаты, и на предметную область по другому смотреть нельзя.
L>Внимание, вопрос: L>Предполагаемая реализация в виде таблиц ->> L>Вход Зона -> Объект ->>
L>Т.е. у входа есть 2 зоны. А каждая зона знает на каком объекте она находится. L>НО. Вход ведь тоже находится на Объекте, и пользователь может в бить в БД что вход разделяет зоны на разных объектах, а такого быть не может.
Тут не совсем понятно. Если вход располагается на границе зон "улица" и "дом", то какому объекту пренадлежат эти зоны?
L>Как его ограничить в возможности такого ввода?
Можно тригером. При создании входа проверять, что зоны которые он соединяет пренадлежат одному объекту.
L>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.
KRA>Тут не совсем понятно. Если вход располагается на границе зон "улица" и "дом", то какому объекту пренадлежат эти зоны?
Есть объект "Работа". У нее есть "Улица" и "Внутрь". Это отельная логическая штука, отельный софт и отдельная песня.
Есть объект "Дом". У нее есть "Улица" и "Внутрь". Это отельная логическая штука, отельный софт и отдельная песня.
Общее у них только то, что хранится все это дело в одной БД.
Просто на создании — не получится, там могут модифицировать, удалять, добавлять и т.п.
Здравствуйте, loknalori, Вы писали:
L>Просто на создании — не получится, там могут модифицировать, удалять, добавлять и т.п.
На добавление и модификацию тоже тригеры навесить. Логику удаления задать с помощью cascade restrict/cascade delete на ограничениях во внешних ключах.
Есть конечно вариант сделать меньше контроля в тригерах (точнее вообще без контроля в тригерах). Для этого нужно ввести понятие "граница зон". Новая таблица для сущностей "Граница зоны". Для каждой пары граничащих зон там создавать запись. И на неё уже ссылаться во входах. Границы зон можно тригером создавать, если между всеми зонами есть соприкосновение, или вручную. Тогда больше контроля и проверок, чтоб лишних дверей не наделали, но больше работы пользователю/внедренцу.
Здравствуйте, KRA, Вы писали:
KRA>Здравствуйте, loknalori, Вы писали:
L>>Просто на создании — не получится, там могут модифицировать, удалять, добавлять и т.п.
KRA>На добавление и модификацию тоже тригеры навесить. Логику удаления задать с помощью cascade restrict/cascade delete на ограничениях во внешних ключах.
KRA>Есть конечно вариант сделать меньше контроля в тригерах (точнее вообще без контроля в тригерах). Для этого нужно ввести понятие "граница зон". Новая таблица для сущностей "Граница зоны". Для каждой пары граничащих зон там создавать запись. И на неё уже ссылаться во входах. Границы зон можно тригером создавать, если между всеми зонами есть соприкосновение, или вручную. Тогда больше контроля и проверок, чтоб лишних дверей не наделали, но больше работы пользователю/внедренцу.
Это не вариант. Точно такая же проблема. Граничность зон караз и задаются понятием "Граница зоны". И если кто то введет что "Есть граница между сервером 1 и сервером 2", то так и будет. А так быть не должно.
Обвешивать все тригерами не хочу. Потом весь этот колхоз поддерживать придется.
и поскольку, как я понял предметную область, вход может принадлежать только одному объекту налагаем на эту таблицу contraint по уникальности на enter_id
далее добавляем таблицу для связки входов и зон
table [enter_object_area]
enter_object_id area_id
1000 10
1000 20
Здравствуйте, Neco, Вы писали:
N>Здравствуйте, loknalori, Вы писали:
L>>Как его ограничить в возможности такого ввода? N>в данном конкретном случае, я бы ввёл доп. таблицу.
Те же яица, вид с боку. Проблема в том, что в таблице [area] зона1 принадлежит какому-то [object] т.е. там есть
id name fk_object
10 улица 100
20 улица 200
Это 2 разные улицы. На разных объектах(серверах). И в предложенном случае проблема та же — как заставить в [enter_object_area] связать зоны из правильных объектов (т.е. уж если одна зона из obj1, то и втора должна быть из obj1)?
А так — просто взгляд под другим углом. В моей схеме, зона привязана к объекту, а вход к зоне. А тут наоборот. А проблема та же.
N>т.е. имеем: N>table [enter] N>id name N>1 вход1 N>2 вход2
N>table [area] N>id name N>10 зона1 N>20 зона2
N>table [object] N>id name N>100 obj1 N>200 obj2
N>вводим доп. таблицу enter_object N>table [enter_object] N>id enter_id object_id N>1000 1 200
N>далее добавляем таблицу для связки входов и зон N>table [enter_object_area] N>enter_object_id area_id N>1000 10 N>1000 20
Здравствуйте, KRA, Вы писали:
KRA>Здравствуйте, loknalori, Вы писали:
L>>Обвешивать все тригерами не хочу. Потом весь этот колхоз поддерживать придется.
KRA>Думаю, что без тригеров тут не обойтись. Насчёт "колхоза" не согласен — это обычный подход.
Вдогонку. По-моему, Вы несколько преувеличиваете проблему. Во-первых, тригера нужно всего два, на вставку и на изменение. Во-вторых, моя практика показывает, что поддерживать эти тригеры несложно — у меня по крайней мере, с этим проблем не возникало.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, loknalori, Вы писали:
L>>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.
W>Если посмотреть на "зону" как частный случай "объекта", и разрешить объектам включать друг друга, станет проще, нет?
Нет, станет хуже, но в другом месте. :-D Описанный мной подход, это как раз попытка уйти от вложенности и перекрытия объектов (описывать долго, но там куча не удобств на прикладном уровне).
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, loknalori, Вы писали:
L>>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.
W>Если посмотреть на "зону" как частный случай "объекта", и разрешить объектам включать друг друга, станет проще, нет?
Чесно говоря не вижу как от этого станет проще. Поясните.
L>Это 2 разные улицы. На разных объектах(серверах). И в предложенном случае проблема та же — как заставить в [enter_object_area] связать зоны из правильных объектов (т.е. уж если одна зона из obj1, то и втора должна быть из obj1)?
в моём варианте таблиц зона не связывается с объектом непосредственно — вообще в самих lookup-таблицах связок нет.
две зоны вяжутся сразу к связке вход+объект. причём каждый вход привязан к одному объекту (а добавив уникальный constraint на колонку area_id в таблице enter_object_area, можно добиться того, что каждая зона будет привязываться к каждому входу лишь раз).
и соль поста была в доп. таблице — путём ввода которой можно добавлять уникальные constaraint, которые невозможно добавлять в обычные таблицы с составными ключами (как если бы была одна таблица с тройным ключом enter_id,area_id,object_id).
если можно — скопипасте мои таблицы и вставьте туда те id, которые недопустимы.
L>Те же яица, вид с боку. :-) Проблема в том, что в таблице [area] зона1 принадлежит какому-то [object] т.е. там есть L>id name fk_object
вот как раз этого fk_object и не должно быть (по крайней мере на него не должен навешиваться ограничивающий функционал).
для чего обычно такие ключи добавляют в справочные таблицы?
1. для того, чтобы по выбранному объекту отобразить список зон исходя из выбранного объекта
2. для того, чтобы перенести зону с одного объекта на другой "единым движением"
что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе — поскольку на зону завязан вход, на этот же вход завязана другая зона, которая по первому апдейту переноситься не обязана и тупо останется на старом объекте. значит, тут либо сущности надо пересмотреть, либо жертвовать этой возможностью. мой вариант — это жертвование этой возможностью, поскольку вы можете оставить данный fk_object, но при его апдейте ничего само никуда не перенесётся (если и переносить, то ручками), т.е. на этом fk останется только функционал №1 — фильтрация по выбранному объекту.
а перенос зоны с объекта на объект можно сделать хранимой процедурой, которая будет выполнять конкретную бизнес-задачу по требованию (апдейтить справочник и "рабочую" таблицу enter_object, а случае нахождения зависимой зоны в enter_object_area переносить зависимую зону или выдавать exception — по вкусу). мне кажется лучше, чем куча триггеров срабатывающих когда надо и не надо.
Здравствуйте, Neco, Вы писали:
N>2. для того, чтобы перенести зону с одного объекта на другой "единым движением"
N>что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе
Праааавильно. Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
N>>что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе L>Праааавильно. ;) Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
ну так в предложенной мной схеме для переноса требуется один апдейт одной строки таблицы enter_object и переносятся сразу один вход и две зоны.
Здравствуйте, loknalori, Вы писали:
L>Описание предметной области:
я 3 раза перечитал весь топик. ...и нифига не понял.
1) почему "вход" связан в обьектом? он должен быть связан с зоной. точнее с 2-мя зонами, которые он разделяет. и какие это обьекты — его волновать не должно.
2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна.
во
Здравствуйте, KRA, Вы писали:
KRA>..моя практика показывает, что поддерживать эти тригеры несложно — у меня по крайней мере, с этим проблем не возникало.
моя практика показыват, что проблемы с тригеррами начинаются у людей, которые работают с приложением _после_ ухода того, кто помнит про триггеры.
вспоминают его трехэтажными словами, после пары дней поиска банальной подмены данных на insert. bo
Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, loknalori, Вы писали:
L>>Описание предметной области:
B>я 3 раза перечитал весь топик. ...и нифига не понял. B>1) почему "вход" связан в обьектом? он должен быть связан с зоной. точнее с 2-мя зонами, которые он разделяет. и какие это обьекты — его волновать не должно.
Это из предметной области. Есть два объекта "завод" и "фабрика". И одного и другого есть по две зоны "двор" и "цех". Так вот, не существует входа из двора завода в цех фабрики. И именно это ограницение хочется иметь на уровне БД. B>2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна.
это не понял. B>во
Здравствуйте, 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>это не понял.
Здравствуйте, Neco, Вы писали:
L>>Те же яица, вид с боку. Проблема в том, что в таблице [area] зона1 принадлежит какому-то [object] т.е. там есть L>>id name fk_object N>вот как раз этого fk_object и не должно быть (по крайней мере на него не должен навешиваться ограничивающий функционал).
N>для чего обычно такие ключи добавляют в справочные таблицы? N>1. для того, чтобы по выбранному объекту отобразить список зон исходя из выбранного объекта N>2. для того, чтобы перенести зону с одного объекта на другой "единым движением"
Функция 1 как раз самая важная и без неё думаю никак нельзя. Дело не только и не столько в отображении (отображение это следствие), дело в наличии связи между объектами, и представления этой связи в БД. Ваше решение ф-цию 1 не поддерживает, а потому врядли годится.
Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
bo
во
