Re[4]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 15:22
Оценка: 4 (1)
Здравствуйте, bastrakov, Вы писали:

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


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


B>>>я 3 раза перечитал весь топик. ...и нифига не понял.

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

B>"входа из двора завода" — привязан к заводу.

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

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


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


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

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

Смотрите выше. Такого вида ограничения для решения задачи не помогут. Или, я, по крайней мере, не вижу как.
Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 09:21
Оценка:
Описание предметной области:
Есть вход, который располагается на границе зон (из зоны "улица" в зону "дом" = вход №1). Есть зоны, которые располагаются на разных Объектах (строения, стоянки и т.п.), т.е. есть зона "ПРИХОЖАЯ" принадлежащая Объекту "ДОМ" и есть другая зона "ПРИХОЖАЯ" принадлежащая объекту "РАБОТА". Во всей этой ситуации важно, чтобы вход такой то имел сведения из какой зоны в какую он работает, т.е. если мы знаем "Вход №1", то это значит из "УЛИЦА" в "Прихожая".

Это как бы постулаты, и на предметную область по другому смотреть нельзя.

Внимание, вопрос:
Предполагаемая реализация в виде таблиц
->
Вход Зона -> Объект
->

Т.е. у входа есть 2 зоны. А каждая зона знает на каком объекте она находится.
НО. Вход ведь тоже находится на Объекте, и пользователь может в бить в БД что вход разделяет зоны на разных объектах, а такого быть не может.

Как его ограничить в возможности такого ввода?

P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.
Re: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 09:28
Оценка:
Здравствуйте, loknalori, Вы писали:

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

L>Есть вход, который располагается на границе зон (из зоны "улица" в зону "дом" = вход №1). Есть зоны, которые располагаются на разных Объектах (строения, стоянки и т.п.), т.е. есть зона "ПРИХОЖАЯ" принадлежащая Объекту "ДОМ" и есть другая зона "ПРИХОЖАЯ" принадлежащая объекту "РАБОТА". Во всей этой ситуации важно, чтобы вход такой то имел сведения из какой зоны в какую он работает, т.е. если мы знаем "Вход №1", то это значит из "УЛИЦА" в "Прихожая".

L>Это как бы постулаты, и на предметную область по другому смотреть нельзя.


L>Внимание, вопрос:

L>Предполагаемая реализация в виде таблиц
->>
L>Вход Зона -> Объект
->>

L>Т.е. у входа есть 2 зоны. А каждая зона знает на каком объекте она находится.

L>НО. Вход ведь тоже находится на Объекте, и пользователь может в бить в БД что вход разделяет зоны на разных объектах, а такого быть не может.

Тут не совсем понятно. Если вход располагается на границе зон "улица" и "дом", то какому объекту пренадлежат эти зоны?

L>Как его ограничить в возможности такого ввода?


Можно тригером. При создании входа проверять, что зоны которые он соединяет пренадлежат одному объекту.

L>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.
Re[2]: Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 09:33
Оценка:
KRA>Тут не совсем понятно. Если вход располагается на границе зон "улица" и "дом", то какому объекту пренадлежат эти зоны?

Есть объект "Работа". У нее есть "Улица" и "Внутрь". Это отельная логическая штука, отельный софт и отдельная песня.
Есть объект "Дом". У нее есть "Улица" и "Внутрь". Это отельная логическая штука, отельный софт и отдельная песня.

Общее у них только то, что хранится все это дело в одной БД.

Просто на создании — не получится, там могут модифицировать, удалять, добавлять и т.п.

p.s. объем таблицы не большой
Re[3]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 09:40
Оценка:
Здравствуйте, loknalori, Вы писали:

L>Просто на создании — не получится, там могут модифицировать, удалять, добавлять и т.п.


На добавление и модификацию тоже тригеры навесить. Логику удаления задать с помощью cascade restrict/cascade delete на ограничениях во внешних ключах.

Есть конечно вариант сделать меньше контроля в тригерах (точнее вообще без контроля в тригерах). Для этого нужно ввести понятие "граница зон". Новая таблица для сущностей "Граница зоны". Для каждой пары граничащих зон там создавать запись. И на неё уже ссылаться во входах. Границы зон можно тригером создавать, если между всеми зонами есть соприкосновение, или вручную. Тогда больше контроля и проверок, чтоб лишних дверей не наделали, но больше работы пользователю/внедренцу.
Re[4]: Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 09:46
Оценка:
Здравствуйте, KRA, Вы писали:

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


L>>Просто на создании — не получится, там могут модифицировать, удалять, добавлять и т.п.


KRA>На добавление и модификацию тоже тригеры навесить. Логику удаления задать с помощью cascade restrict/cascade delete на ограничениях во внешних ключах.


KRA>Есть конечно вариант сделать меньше контроля в тригерах (точнее вообще без контроля в тригерах). Для этого нужно ввести понятие "граница зон". Новая таблица для сущностей "Граница зоны". Для каждой пары граничащих зон там создавать запись. И на неё уже ссылаться во входах. Границы зон можно тригером создавать, если между всеми зонами есть соприкосновение, или вручную. Тогда больше контроля и проверок, чтоб лишних дверей не наделали, но больше работы пользователю/внедренцу.


Это не вариант. Точно такая же проблема. Граничность зон караз и задаются понятием "Граница зоны". И если кто то введет что "Есть граница между сервером 1 и сервером 2", то так и будет. А так быть не должно.

Обвешивать все тригерами не хочу. Потом весь этот колхоз поддерживать придется.
Re: Как ограничить схему данных.
От: Neco  
Дата: 16.06.09 09:53
Оценка:
Здравствуйте, loknalori, Вы писали:

L>Как его ограничить в возможности такого ввода?

в данном конкретном случае, я бы ввёл доп. таблицу.

т.е. имеем:
table [enter]
id name
1 вход1
2 вход2

table [area]
id name
10 зона1
20 зона2

table [object]
id name
100 obj1
200 obj2

вводим доп. таблицу enter_object
table [enter_object]
id enter_id object_id
1000 1 200

и поскольку, как я понял предметную область, вход может принадлежать только одному объекту налагаем на эту таблицу contraint по уникальности на enter_id

далее добавляем таблицу для связки входов и зон
table [enter_object_area]
enter_object_id area_id
1000 10
1000 20
всю ночь не ем, весь день не сплю — устаю
Re[5]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 09:55
Оценка:
Здравствуйте, loknalori, Вы писали:

L>Обвешивать все тригерами не хочу. Потом весь этот колхоз поддерживать придется.


Думаю, что без тригеров тут не обойтись. Насчёт "колхоза" не согласен — это обычный подход.
Re[2]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 09:58
Оценка:
Здравствуйте, Neco, Вы писали:

N>далее добавляем таблицу для связки входов и зон

N>table [enter_object_area]
N>enter_object_id area_id
N>1000 10
N>1000 20


Та же самая проблема будет. Нечего не запрещает в enter_object_area вставить запись з зонами из разных объектов.
Re[2]: Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 10:04
Оценка:
Здравствуйте, 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
Re: Как ограничить схему данных.
От: wildwind Россия  
Дата: 16.06.09 10:13
Оценка:
Здравствуйте, loknalori, Вы писали:

L>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.


Если посмотреть на "зону" как частный случай "объекта", и разрешить объектам включать друг друга, станет проще, нет?
Re[6]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 10:17
Оценка:
Здравствуйте, KRA, Вы писали:

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


L>>Обвешивать все тригерами не хочу. Потом весь этот колхоз поддерживать придется.


KRA>Думаю, что без тригеров тут не обойтись. Насчёт "колхоза" не согласен — это обычный подход.


Вдогонку. По-моему, Вы несколько преувеличиваете проблему. Во-первых, тригера нужно всего два, на вставку и на изменение. Во-вторых, моя практика показывает, что поддерживать эти тригеры несложно — у меня по крайней мере, с этим проблем не возникало.
Re[2]: Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 10:20
Оценка:
Здравствуйте, wildwind, Вы писали:

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


L>>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.


W>Если посмотреть на "зону" как частный случай "объекта", и разрешить объектам включать друг друга, станет проще, нет?


Нет, станет хуже, но в другом месте. :-D Описанный мной подход, это как раз попытка уйти от вложенности и перекрытия объектов (описывать долго, но там куча не удобств на прикладном уровне).
Re[2]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 10:22
Оценка:
Здравствуйте, wildwind, Вы писали:

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


L>>P.S. предметную область описал, т.к. м.б. будут идеи как по другому таблицы спроектировать.


W>Если посмотреть на "зону" как частный случай "объекта", и разрешить объектам включать друг друга, станет проще, нет?


Чесно говоря не вижу как от этого станет проще. Поясните.
Re[3]: Как ограничить схему данных.
От: Neco  
Дата: 16.06.09 10:22
Оценка:
L>Это 2 разные улицы. На разных объектах(серверах). И в предложенном случае проблема та же — как заставить в [enter_object_area] связать зоны из правильных объектов (т.е. уж если одна зона из obj1, то и втора должна быть из obj1)?
в моём варианте таблиц зона не связывается с объектом непосредственно — вообще в самих lookup-таблицах связок нет.
две зоны вяжутся сразу к связке вход+объект. причём каждый вход привязан к одному объекту (а добавив уникальный constraint на колонку area_id в таблице enter_object_area, можно добиться того, что каждая зона будет привязываться к каждому входу лишь раз).
и соль поста была в доп. таблице — путём ввода которой можно добавлять уникальные constaraint, которые невозможно добавлять в обычные таблицы с составными ключами (как если бы была одна таблица с тройным ключом enter_id,area_id,object_id).

если можно — скопипасте мои таблицы и вставьте туда те id, которые недопустимы.
всю ночь не ем, весь день не сплю — устаю
Re[3]: Как ограничить схему данных.
От: Neco  
Дата: 16.06.09 10:53
Оценка:
L>Те же яица, вид с боку. :-) Проблема в том, что в таблице [area] зона1 принадлежит какому-то [object] т.е. там есть
L>id name fk_object
вот как раз этого fk_object и не должно быть (по крайней мере на него не должен навешиваться ограничивающий функционал).

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

что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе — поскольку на зону завязан вход, на этот же вход завязана другая зона, которая по первому апдейту переноситься не обязана и тупо останется на старом объекте. значит, тут либо сущности надо пересмотреть, либо жертвовать этой возможностью. мой вариант — это жертвование этой возможностью, поскольку вы можете оставить данный fk_object, но при его апдейте ничего само никуда не перенесётся (если и переносить, то ручками), т.е. на этом fk останется только функционал №1 — фильтрация по выбранному объекту.
а перенос зоны с объекта на объект можно сделать хранимой процедурой, которая будет выполнять конкретную бизнес-задачу по требованию (апдейтить справочник и "рабочую" таблицу enter_object, а случае нахождения зависимой зоны в enter_object_area переносить зависимую зону или выдавать exception — по вкусу). мне кажется лучше, чем куча триггеров срабатывающих когда надо и не надо.
всю ночь не ем, весь день не сплю — устаю
Re[4]: Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 11:42
Оценка:
Здравствуйте, Neco, Вы писали:

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


N>что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе

Праааавильно. Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
Re[5]: Как ограничить схему данных.
От: Neco  
Дата: 16.06.09 11:50
Оценка:
N>>что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе
L>Праааавильно. ;) Именно это и требуется. И чтоб ни дай Бог чтобы кто-то мог связать зоны разных объектов.
ну так в предложенной мной схеме для переноса требуется один апдейт одной строки таблицы enter_object и переносятся сразу один вход и две зоны.
всю ночь не ем, весь день не сплю — устаю
Re: Как ограничить схему данных.
От: bastrakov Россия http://bastrakof.livejournal.com/
Дата: 16.06.09 12:50
Оценка:
Здравствуйте, loknalori, Вы писали:

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


я 3 раза перечитал весь топик. ...и нифига не понял.
1) почему "вход" связан в обьектом? он должен быть связан с зоной. точнее с 2-мя зонами, которые он разделяет. и какие это обьекты — его волновать не должно.
2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна.
во
Re[7]: Как ограничить схему данных.
От: bastrakov Россия http://bastrakof.livejournal.com/
Дата: 16.06.09 12:53
Оценка:
Здравствуйте, KRA, Вы писали:

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


моя практика показыват, что проблемы с тригеррами начинаются у людей, которые работают с приложением _после_ ухода того, кто помнит про триггеры.
вспоминают его трехэтажными словами, после пары дней поиска банальной подмены данных на insert. bo
Re[2]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 12:54
Оценка:
Здравствуйте, bastrakov, Вы писали:

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


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


B>я 3 раза перечитал весь топик. ...и нифига не понял.

B>1) почему "вход" связан в обьектом? он должен быть связан с зоной. точнее с 2-мя зонами, которые он разделяет. и какие это обьекты — его волновать не должно.
Это из предметной области. Есть два объекта "завод" и "фабрика". И одного и другого есть по две зоны "двор" и "цех". Так вот, не существует входа из двора завода в цех фабрики. И именно это ограницение хочется иметь на уровне БД.
B>2) по-любому, можно наложить ограничение на 2 поля. ну типа, что данная связка "вход-обьект" должна быть уникальна.
это не понял.
B>во
Re[8]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 12:57
Оценка:
Здравствуйте, bastrakov, Вы писали:

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


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


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

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

Не нужно перегибать. Так можно почти любую возможность забраковать, если ею пользоваться неправильно. С этими тригерами проблем нет, потому что они всего лишь не дают сделать бяку (делают проверку), если попытаться её сделать.
Re[6]: Как ограничить схему данных.
От: loknalori Россия  
Дата: 16.06.09 14:44
Оценка:
Здравствуйте, Neco, Вы писали:

N>>>что имеем в вашем случае — простой перенос зоны с одного объекта на другой невозможен в принципе

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

Пардон. Нихт фирштейн? Я вроде написал, что мне ни чего не надо переносить. И задача состоит совсем в другом. причем написал уже 2 или 3 раза.
Re[3]: Как ограничить схему данных.
От: bastrakov Россия http://bastrakof.livejournal.com/
Дата: 16.06.09 14:54
Оценка:
Здравствуйте, KRA, Вы писали:

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


B>>я 3 раза перечитал весь топик. ...и нифига не понял.

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

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

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

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

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

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

KRA>это не понял.

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

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

во
Re[4]: Как ограничить схему данных.
От: KRA Украина  
Дата: 16.06.09 14:56
Оценка:
Здравствуйте, Neco, Вы писали:

L>>Те же яица, вид с боку. Проблема в том, что в таблице [area] зона1 принадлежит какому-то [object] т.е. там есть

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

N>для чего обычно такие ключи добавляют в справочные таблицы?

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

Функция 1 как раз самая важная и без неё думаю никак нельзя. Дело не только и не столько в отображении (отображение это следствие), дело в наличии связи между объектами, и представления этой связи в БД. Ваше решение ф-цию 1 не поддерживает, а потому врядли годится.
Re[5]: Как ограничить схему данных.
От: bastrakov Россия http://bastrakof.livejournal.com/
Дата: 18.06.09 08:53
Оценка:
Здравствуйте, KRA, Вы писали:

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


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

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

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

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

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

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

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