Описание предметной области:
Есть вход, который располагается на границе зон (из зоны "улица" в зону "дом" = вход №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>во
Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
bo
