Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет. Соответственно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?".

Предполагалось, что это начальство составит "гневное письмо" разработчику, но вместо этого предлагают какие-то обходные пути, чреватые, на мой взгляд, проблемами в дальнейшем. Можно навесить и триггеров before update/delete/insert на родительскую и дочерние таблицы и там уже контролировать, но как-то... не лежит душа к этому. Я пытаюсь следовать правилу "для решения конкретного класса проблем - конкретный класс инструментария". Foreign keys - для своего, триггеры - в общем случае для совсем другого. Можно ли как-нибудь аргументированно разграничить эти два способа через их конкретные плюсы и минусы?

Думаю.............
12 май 08, 07:20    [5648770]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
SimonInBlues
Member

Откуда: Балаково
Сообщений: 264
Вадиман
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет. Соответственно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?".


а нельзя ли вновь ввести в эту таблицу утерянное поле, которое заполнять, например, через триггер, и сохранить т.о. внешние ключи?

ps: а разьве уникальный индекс это не есть по сути первичный ключ и уникальный констрейнт?
12 май 08, 08:11    [5648799]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
мастер Йода
Guest
зло непобедимо.

весь вопрос что выберешь ты: увеличиваешь энтропию вселенной или борешься с этим неизбежным процессом.

разработчик он ведь тоже не дурак (в большинстве своем), а результат сильно зависит от того на какой козе ты к ним подъедешь.

недалекое начальство? Тут два варианта: "пошли вы в жопу" или открывай ему(начальству) перспективы. Но по истечении времени все равно светит первый вариант :)

иди с миром мой юный падаван.
12 май 08, 08:18    [5648803]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
х.з.
Member

Откуда:
Сообщений: 765
SimonInBlues

а нельзя ли вновь ввести в эту таблицу утерянное поле

ты не в теме, поле не удалялось
12 май 08, 08:22    [5648808]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
SimonInBlues
Вадиман
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет. Соответственно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?".


а нельзя ли вновь ввести в эту таблицу утерянное поле, которое заполнять, например, через триггер, и сохранить т.о. внешние ключи?

ps: а разьве уникальный индекс это не есть по сути первичный ключ и уникальный констрейнт?

Нет, это не одно и тоже. Наличие индекса, пусть даже и уникального, ораклу не подскажет, что другая таблица жаждет сослаться на эти индексированные поля. Я уж не говорю про разницу между unique/primary key в null/not null колонках.
12 май 08, 08:49    [5648848]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
мастер Йода
зло непобедимо.

весь вопрос что выберешь ты: увеличиваешь энтропию вселенной или борешься с этим неизбежным процессом.

разработчик он ведь тоже не дурак (в большинстве своем), а результат сильно зависит от того на какой козе ты к ним подъедешь.

недалекое начальство? Тут два варианта: "пошли вы в жопу" или открывай ему(начальству) перспективы. Но по истечении времени все равно светит первый вариант :)

иди с миром мой юный падаван.


Прежде нужно эту козу "оседлать", напугать как следует... или накормить... в зависимости от ситуации. А потом уже в дорогу. Это я к тому, что прежде чем добраться до разработчика, нужно победить начальство :). Я, собственно, над "перспективами" и думаю. Доводы "это нехорошо, это некрасиво" не годятся, им нужны попугаи, которых можно пощупать и измерить
12 май 08, 08:55    [5648855]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Стивка-Бурка
Member

Откуда: из австралийской сказки
Сообщений: 117
мастер Йода
разработчик он ведь тоже не дурак (в большинстве своем)
Мастер Йода, тебе пора опять в падаваны ;-)
12 май 08, 08:58    [5648861]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Вадиман
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет.

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

Вадиман
Соответсвенно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?"

На это можно ответить - тем, что в оракле при многопользовательской работе триггера не обеспечивают целостности.

Вадиман
Предполагалось, что это начальство составит "гневное письмо" разработчику,

Если бы я был разработчиком, то гневное - без кавычек - письмо значительно уменьшило бы шансы на получение вами положительного ответа.

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

Cтремление решить проблему собственными силами в общем понятно, равно как и стремление сказать программисту "сделай" вместо того, чтобы самому писать письма.

Я бы посоветовал не грузить начальство тем, что оно не понимает и не хочет делать. Лучше всего - напрямую выйти на контакт с разработчиками; лучше тем, что если они заведут волынку про "мы не будем, делайте триггеры", это пройдет мимо твоего начальства. Если нет - составь вежливое аргументированное письмо и попроси начальника отправить.

Вадиман
Я пытаюсь следовать правилу "для решения конкретного класса проблем - конкретный класс инструментария".

Подход верный, но не всегда стоит применять его чересчур буквально. По ситуации возможны разные решения; как вариант - на тестовой БД создать нужный вам ключ и отлаживаться с FK, а на боевой просто повесить job, который будет раз в сутки искать подвисшие ключи и писать вам, если что-то сломается.

Вадиман
Можно ли как-нибудь аргументированно разграничить эти два способа через их конкретные плюсы и минусы?

Да. Поищите в форуме - здесь обосновывалось, что триггеры не могут без сильных блокировок обеспечить целостность по связям.
12 май 08, 09:01    [5648865]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
Вадиман
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет. Соответственно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?".

Предполагалось, что это начальство составит "гневное письмо" разработчику, но вместо этого предлагают какие-то обходные пути, чреватые, на мой взгляд, проблемами в дальнейшем. Можно навесить и триггеров before update/delete/insert на родительскую и дочерние таблицы и там уже контролировать, но как-то... не лежит душа к этому. Я пытаюсь следовать правилу "для решения конкретного класса проблем - конкретный класс инструментария". Foreign keys - для своего, триггеры - в общем случае для совсем другого. Можно ли как-нибудь аргументированно разграничить эти два способа через их конкретные плюсы и минусы?

Думаю.............

Добавь constaraint UNIQUE(FIELD_NAME) USING INDEX_NAME, и восстанавливай FK... Все просто, как 2 байта переслать.
12 май 08, 09:08    [5648874]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
Softwarer, спасибо, я примерно такого ответа ждал. По поводу "гневных писем" - это просто речевой оборот, 4-ехлетний опыт общения дал свои плоды :) Никто ничего гневного бы не писал. И про первичный ключ - это их недосмотр, связанный с набором головняков после ввода новой схемы партиционирования таблицы. Как я сейчас узнал, нынешний уникальный индекс был временным решением, но оно сильно затянулось, и очень похоже, что про него просто забыли. Или забили.

Спасибо еще раз.
12 май 08, 09:09    [5648877]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
RA\/EN
Вадиман
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет. Соответственно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?".

Предполагалось, что это начальство составит "гневное письмо" разработчику, но вместо этого предлагают какие-то обходные пути, чреватые, на мой взгляд, проблемами в дальнейшем. Можно навесить и триггеров before update/delete/insert на родительскую и дочерние таблицы и там уже контролировать, но как-то... не лежит душа к этому. Я пытаюсь следовать правилу "для решения конкретного класса проблем - конкретный класс инструментария". Foreign keys - для своего, триггеры - в общем случае для совсем другого. Можно ли как-нибудь аргументированно разграничить эти два способа через их конкретные плюсы и минусы?

Думаю.............

Добавь constaraint UNIQUE(FIELD_NAME) USING INDEX_NAME, и восстанавливай FK... Все просто, как 2 байта переслать.

Да была б это моя таблица - без проблем :) Хотя, в таком случае я бы и не трогал первичный ключ. Просто по принятой у нас схеме "объекты разработчика" так просто не трогаются. По разным причинам. Достаточно хотя бы того, что потом руки оторвут, когда выяснят - "кто нажал кнопку" :).
12 май 08, 09:12    [5648882]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
RA\/EN
Добавь constaraint UNIQUE(FIELD_NAME) USING INDEX_NAME, и восстанавливай FK... Все просто, как 2 байта переслать.

Я был бы более осторожен с подобными советами... я вполне представляю себе ситуацию, когда разработчики решили убрать ключ потому, что "чересчур умный" фреймворк находит эту метаинформацию и "неудачно" ее использует - например, делает редактируемым набор данных, которым это категорически противопоказано. Безусловно, решать проблемы таким образом - очень плохая практика, но и корежить чужую схему надо... аккуратно, иначе возможны очень неожиданные проблемы.
12 май 08, 09:15    [5648887]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
softwarer

Вадиман
Я пытаюсь следовать правилу "для решения конкретного класса проблем - конкретный класс инструментария".

Подход верный, но не всегда стоит применять его чересчур буквально. По ситуации возможны разные решения; как вариант - на тестовой БД создать нужный вам ключ и отлаживаться с FK, а на боевой просто повесить job, который будет раз в сутки искать подвисшие ключи и писать вам, если что-то сломается.


Вот этого бы тоже не хотелось делать, ибо в течение периода, пока этот job не будет работать (т.е. когда будет зафиксирована "странная" ситуация в базе) может произойти что-нибудь нехорошее... например, выписки клиенту по почте отправят. И неважно, что ночью ситуация исправится, на утро клиент выставит претензии "где мои деньги? они были, а теперь нет" :). Образно, абстрактно, но все же...
12 май 08, 09:19    [5648895]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Вадиман

Я не зря сказал "по ситуации". Если не удастся договориться с разработчиками, надо искать решение для конкретного случая. Например, посмотреть, не удастся ли организовать проверку целостности через mat view - помнится, делал я такой трюк.
12 май 08, 09:46    [5649001]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Вадиман
Member

Откуда: Владивосток
Сообщений: 1072
час рылся на форуме, подбирал различные ключевые слова :) Попадались темы несколько отстраненные. Softwarer, не могли бы вы подбросить ссылку на топик, о котором упоминали? Если не трудно (я про принципиальную невозможность обеспечения ссылочной целостности в триггерах)
12 май 08, 10:46    [5649338]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
Вадиман
час рылся на форуме, подбирал различные ключевые слова :) Попадались темы несколько отстраненные. Softwarer, не могли бы вы подбросить ссылку на топик, о котором упоминали? Если не трудно (я про принципиальную невозможность обеспечения ссылочной целостности в триггерах)

А триггеры - это не вмешательство в схему разработчика?
Я тоже вполне могу представить систему, где ссылочная целостность нарушается внутри транзакции (например, DEFERRED CONSTRAINT), а накрученнеые "сверху" триггеры поломают функционал. Это встречается чаще crazy фрейморков, определяющих доступность данных на редактирование по наличию PK/UK.
Не ищите ответа на форуме, а проконсультируйстесь с разработчиками системы, как можно "залепить" проблему до патча (особенно учитывая Ваше высказывание: "это их недосмотр, связанный с набором головняков после ввода новой схемы партиционирования таблицы. Как я сейчас узнал, нынешний уникальный индекс был временным решением, но оно сильно затянулось, и очень похоже, что про него просто забыли. Или забили.").
12 май 08, 11:27    [5649584]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
[quot softwarer
На это можно ответить - тем, что в оракле при многопользовательской работе триггера не обеспечивают целостности.
[/quot]

Уточнить можно?
Ведь триггеры, сами по себе, вообще ничего не обеспечивают. Обеспечивает код, который в них написан.
Речь идет о том, что можно потерять целостность и при "правильном" коде?
12 май 08, 11:39    [5649658]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
мастер Йода

"как победить зло"
"зло непобедимо"


какая слабая теоретическая подготовка

зло побеждать не нужно
жизнь - это поиск добра (пользы) среди зла

в данном случае, нужно извлечь пользу (видимо финансовую) из этого конкретного зла
12 май 08, 11:49    [5649722]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
SimonInBlues
Member

Откуда: Балаково
Сообщений: 264
х.з.
SimonInBlues

а нельзя ли вновь ввести в эту таблицу утерянное поле

ты не в теме, поле не удалялось

похоже и правда поле есть :(
тогда в чем проблема - присоединяюсь к рекомендации RAVEN-а. И лучше предварительно связаться с их программерами и уточнить, чем было вызвано такое изменение таблицы - может и правда - удалили банально по недосмотру.
12 май 08, 12:31    [5650029]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Вадиман
Softwarer, не могли бы вы подбросить ссылку на топик, о котором упоминали? Если не трудно (я про принципиальную невозможность обеспечения ссылочной целостности в триггерах)

Действительно, быстро не находится. Принципиально возможно, просто слишком дорого, придется использовать более глобальные блокировки. Кроме того, я еще не видел случая, когда авторы этой идеи не делали ошибок в своих триггерах; скажем, https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=541534&pg=1#5478323 - очередной пример. Именно ссылочную целостность, если не ошибаюсь, можно реализовать без lock table, только на select for update, но и там, стоит использовать before delete вместо after delete - и все, суши весла.
12 май 08, 14:55    [5651068]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
softwarer
Вадиман
Softwarer, не могли бы вы подбросить ссылку на топик, о котором упоминали? Если не трудно (я про принципиальную невозможность обеспечения ссылочной целостности в триггерах)

Действительно, быстро не находится. Принципиально возможно, просто слишком дорого, придется использовать более глобальные блокировки. Кроме того, я еще не видел случая, когда авторы этой идеи не делали ошибок в своих триггерах; скажем, https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=541534&pg=1#5478323 - очередной пример. Именно ссылочную целостность, если не ошибаюсь, можно реализовать без lock table, только на select for update, но и там, стоит использовать before delete вместо after delete - и все, суши весла.


Странная проблема, странное решение.
Была там здравая мысль, про создание третьей таблицы, которая бы и хранила первичный ключ из вышеупомянутых двух таблиц и тип, указывающий на одну из них...
Но, как я понял, ей не воспользовались....
12 май 08, 17:08    [5652046]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
uranic
Member

Откуда:
Сообщений: 309
softwarer
Действительно, быстро не находится. Принципиально возможно, просто слишком дорого, придется использовать более глобальные блокировки. Кроме того, я еще не видел случая, когда авторы этой идеи не делали ошибок в своих триггерах; скажем, https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=541534&pg=1#5478323 - очередной пример. Именно ссылочную целостность, если не ошибаюсь, можно реализовать без lock table, только на select for update, но и там, стоит использовать before delete вместо after delete - и все, суши весла.


Спасибо за ссылку. Сам никогда целостность на тригерах не реализовывал, но вопрос меня заинтересовал. Решил посмотреть как с этим дела у Sybase PowerDesigner, в котором, при проектировании Refernces можно указать один из способов реализации (trgger либо declarative). Посмотрел код, который генерит PowerDesigner, при реализации целостности на триггерах, протестировал. Та же ошибка что и в ссылке выше: в многопользовательской системе тригера от PowerDesigner не гарантируют целостности.
12 май 08, 18:44    [5652639]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
stax..
Guest
Вадиман
Ситуация: есть 3d-party ПО на ее же, 3d-party, базе. После каких-то патчей обнаружилось, что одна из ядерных таблиц лишилась напрочь первичного ключа. Горе-разработчики заменили его уникальным индексом. Даже уникального constraint'а нет. Соответственно, все foreign keys с разработанных нами структур на эту таблицу грохнулись. Засветили проблему перед начальством (в свете обеспечения ссылочной целостности на уровне базы), а оно сразу в ответ: "Ну а триггеры чем не решение?".

Предполагалось, что это начальство составит "гневное письмо" разработчику, но вместо этого предлагают какие-то обходные пути, чреватые, на мой взгляд, проблемами в дальнейшем. Можно навесить и триггеров before update/delete/insert на родительскую и дочерние таблицы и там уже контролировать, но как-то... не лежит душа к этому. Я пытаюсь следовать правилу "для решения конкретного класса проблем - конкретный класс инструментария". Foreign keys - для своего, триггеры - в общем случае для совсем другого. Можно ли как-нибудь аргументированно разграничить эти два способа через их конкретные плюсы и минусы?

Думаю.............

пусть предложат код на триггерах реализации FK во многопользовательской системе,
имхо не так просто
......
stax
12 май 08, 18:52    [5652678]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
uranic
Сам никогда целостность на тригерах не реализовывал

Вопрос заинтересовал меня, думаю, раз уж не нашел старых материалов, вечером покопаюсь как следует.

uranic
Решил посмотреть как с этим дела у Sybase PowerDesigner,

И у ErWin-а тоже плохо.
12 май 08, 18:56    [5652701]     Ответить | Цитировать Сообщить модератору
 Re: Как победить зло?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
stax..
пусть предложат код на триггерах реализации FK во многопользовательской системе, имхо не так просто

Скажем так, вот такой вариант

create trigger child_bi before insert on child
begin
  for cr in (select 1 from parent where parent_id = :new.parent_id for update) loop
    return;
  end loop;
  raise_application_error (-20100, 'Parent ' || :new.parent_id || ' not found');
end;

create trigger parent_ad after delete on child
begin
  for cr in (select child_id from child where parent_id = :old.parent_id) loop
    raise_application_error (-20100, 'Child record found: ' || cr.child_id);
  end loop;
end;

я сходу сломать не смог (update, само собой, пока не рассматривал).
12 май 08, 19:03    [5652742]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить