"Да, "введение" и "вся реляционная теория" ;)," - а что, мне нравятся такие названия. "Краткий курс..." в пяти томах, "Основы ..." в трех, "Введение в ..." на трех тысячах страниц. Хе...
"...ипользовать в банке СУБД без транзакций это такое же... " - мы в то время говорили то же самое, только более пространно. Ну, что поделать, такую систему купили.
"Непротиворечимость и целостность в любой момент - это да, а сохранность... " - Хм?.. Но разве одной из неотъемлемых составных частей обеспечения непротиворечивости и целостности не является физическая сохранность?
"...но учти, что все что там "фигурирует" это для ТЕБЯ, как разработчика БД" - верно, но только отчасти. Книга посвещена реляционой теории и качествам СУБД, которые должны присутствовать для того, что бы СУБД требованиям теории удовлетворяла. А значит, и для разработчика СУБД. Например Progress 8.2A может хранить в столбце массив и своими средствами нормально с таким столбцом работать. А теперь мне надо обратиться к этим данным через ODBC(рядовой случай, правда?), да причем через драйвер первого уровня совместимости(нет у меня другого). И все, собственно, обратился, можно идти курить. Т.е. стандартом ANSI SQL я ничего сделать не могу, потому, что стандарт предполагает реляционность СУБД. Вот, кстати, отношение SQL и реляционной теории, самое непосредстввенное.
Транзакции имеют к целостности данных отношение самое непосредственное. Просто я под целостностью понимаю и целостность логическую, для больших баз данных(больших по количесву записей) целостность логическая и физическая практически одно и то же. Имеем две таблицы, связанных по ключу отношением типа от on delete cascade. Не имеем транзакций(мне уже тоскливо). Делаем delete из родительской(должна быть открыта неявная транзакция, но ее нет). На полуторамилионной записи delete падает(неважно - почему). Что мы имеем у родителя? Да черт его знает, что мы имеем у родителя. А у дочерней таблицы? То же самое слово мы имеем у потомка. Это можно выяснить запустив что-нибуть проверочное, предварительно выгнав всех из базы, что равнозначно выводу СУБД из экплуатации. Потом выясняется, что не для пятидесяти тысяч записей потомка не имеется родителей(транзакции-то нет, родителя шмякнули, было за потомков взялись, да всех удушить не вышло). Данные потеряны так же хорошо, как если бы навернулся диск с tablespace'ом. Что делать? Backup поднимать и все по новой(если такое возможно, потому, что backup вчерашний, а за сегодня еще сто тысяч записей накидали, с ними-то что?). В общем, тривиальный delete вывел СУБД из строя на несколько часов.
А насчет внешних процедур - да неувязочка вышла. Выразились бы яснее, а то для меня внешняя процедура, это когда перекачал таблицы на клиента и давай по строчкам бегать.
Про Interbase. Не было там ни массового delete, ни незакоммиченного insert. Но даже если твоя гипотеза верна, то interbase она не оправдывает. Ведь сервер не просто упал. Он же потом базу и поднять не смог. Ну не должен сервер от select'a падать, а тем более структуры данных разваливать. Даже изредка.
вот ведь блин, а ... г-н Бес, ну что Вы в Interbase впились ? Вместо того чтобы свои проги переписывать и прочей фигней заниматься, стоило сходить к умным людям и проконсультироваться что к чему. Я уже намекал на кривые руки, могу повторить еще раз. Я достаточно немало времени (более 2-х лет) провел в большом сотрудничестве с Interbase и в т.ч. в различных конфах на тему IB и видел там разные приколы, но я что-то не припоминаю случаев когда бы люди валили базу select'aми, да при этом еще и тестовую (я так понял что до рабочей базы у Вас дело не дошло). О чем это говорит ? Вывод очевиден. Больше всего мне непонятно то, что после такого необъяснимого завала базы Вы не стали разбираться что к чему, а просто сменили платформу СУБД ... :-) ИМХО это более чем странно. Наверное это примерно то же, что после одного зависа компа (может быть из-за перегрева проца, например, или скачка в сети) сносить ОС и потом ее поносить ...
"...я так понял что до рабочей базы у Вас дело не дошло..." - честь мне и хвала, что не дошло. Что я не стал дальше работать с такой СУБД. Это говорит только и исключительно о недюжинном моем, ядрена вошь, уме и неординарной, бляха муха, интуиции! Мне предстояло отдать проект в руки, которые не умеют работать с СУБД! Там не предполагалось админинстратора, даже столовой!
Уф...
Зеер гуд. Предположим, стал бы я разбираться и получил бы ответ вроде того, который любезно предолжил ignite. И что? Дальше - что? Что мне с этим ответом делать?
Еще раз говорю, что если Вы с чем-то не сталкивались, то это не значит, что этого не существует.
Вам известно, уважаемый г-н Анонимус, такое понятие как "порок конструкции"? Interbase содержит(содержал) фатальный порок конструкции, вынудивший меня отказаться от использования означенного Interbase в пользу Sybase Adaptive Server Anywhere 5.0, такого порока не имеющего. Пусть тот, кто работал с тем и с другим осудит мой выбор.
На протяжении нескольких лет, в течении которых я интересовался судьбой системы претензий не было, несмотря на то, что системы была лишена не только какого-то ни было администрирования, но и просто корректного обращения(машину сервер часто выключали просто кнопкой).
Сходные по масштабам системы на Interbase, при менее интенсивной эксплуатации и таком же отсутствии профилактики, которые я имел наблюдать, небратимо выходили из строя, нанося организации сильный геморрой. Если так интересно, я могу дать адреса и той и другой организаций с указанием имен людей, которые могут подтвердить мои слова. Правда за актуальность имен я сейчас не ручаюсь, прошло несколько лет.
No, Полуденный Бес, is right.
If the database fails severely _even_ due to moderately incorrect treatment,
the database is a piece of crap.
I have done _many really bad_ things to the following DBs:
MySQL, PGSQL, Oracle, DB2 of different versions. None of them didn't
really "object" much :) ..well, early MySQL did really fuck up one time,
but it was a beta and well, I let it pass ...
But would that happen one more time, I'll cross MySQL out of my "cool-book".
>"Непротиворечимость и целостность в любой момент - это да, а ? >сохранность... " - Хм?.. Но разве одной из неотъемлемых составных >частей обеспечения непротиворечивости и целостности не является ? >физическая сохранность?
Не бывает ссылочной целостности у того чего нет. Эдак мы начнём говорить о ссылочной целостности "множества всех множеств ...", ну ты помнишь дальше :)
>"...но учти, что все что там "фигурирует" это для ТЕБЯ, как >разработчика БД" - верно, но только отчасти. Книга посвещена >реляционой теории и качествам СУБД, которые должны присутствовать ? >для того, что бы СУБД требованиям теории удовлетворяла. А значит, и >для разработчика СУБД. Например Progress 8.2A может хранить в >столбце массив и своими средствами нормально с таким столбцом >работать. А теперь мне надо обратиться к этим данным через ODBC >(рядовой случай, правда?), да причем через драйвер первого уровня >совместимости(нет у меня другого). И все, собственно, обратился, >можно идти курить. Т.е. стандартом ANSI SQL я ничего сделать не >могу, потому, что стандарт предполагает реляционность СУБД. Вот, >кстати, отношение SQL и реляционной теории, самое непосредстввенное.
Не уловил мысли. Что, Progress не реляционный, и поэтому с ним проблемы ? Да, с нестандартными расширениями всегда проблемы, массивы - прямое нарушение первой нормальной формы - атомарность данных. Не хочешь проблем, действуй как Кодд, Дейт и Озкарахан писали, как теория рекомендует - не используй массивы.
>Транзакции имеют к целостности данных отношение самое >непосредственное. Просто я под целостностью понимаю и целостность >логическую, для больших баз данных(больших по количесву записей) >целостность логическая и физическая практически одно и то же. Имеем >две таблицы, связанных по ключу отношением типа от on delete >cascade. Не имеем транзакций(мне уже тоскливо). Делаем delete из
Ну напутал, ну напутал. Отношения бывают 1:М, М:1, М:М, on delete - это ограничение, кстати, оно ведь не обязятельно - каскад, и даже чаще оно совсем не каскад а какой-нибудь там reject. То есть удалять прийдётся двумя запросами.
>родительской(должна быть открыта неявная транзакция, но ее нет). На >полуторамилионной записи delete падает(неважно - почему). Что мы >имеем у родителя? Да черт его знает, что мы имеем у родителя. А у >дочерней таблицы? То же самое слово мы имеем у потомка. Это можно >выяснить запустив что-нибуть проверочное, предварительно выгнав всех >из базы, что равнозначно выводу СУБД из экплуатации. Потом >выясняется, что не для пятидесяти тысяч записей потомка не имеется >родителей(транзакции-то нет, родителя шмякнули, было за потомков >взялись, да всех удушить не вышло). Данные потеряны так же хорошо, >как если бы навернулся диск с tablespace'ом. Что делать? Backup >поднимать и все по новой(если такое возможно, потому, что backup >вчерашний, а за сегодня еще сто тысяч записей накидали, с ними-то >что?). В общем, тривиальный delete вывел СУБД из строя на несколько >часов.
Опять пример неудачный. Запустили (после сбоя) базу. Пустили туда юзеров. (а ничего страшного - мы ведь эти записи всё равно УДАЛЯТЬ собирались - ну и пусть пока висят, болтаются). Запустили ещё раз тот длинный delete. Он доделал всё что нужно. Остались сироты. Запускаем запрос (ОДИН) который прибивает этих горемык. И ВСЁ. А юзеры пусть себе работают дальше. Кстати такими выбрыками (полуторамиллионный делет) любую СУБД укатать можно. Тот же оракл - про сегмент отката, лог транзакций, слышал ? Не бывает, понимаешь, бесплатного сыра (это я про транзакции, и их стоимость - ресурсную). Такая штука в MySQL может прокатить на ура, и не заметишь, а оракла положить. Нет, данные выживут, но вот работа на пару часов станет - пока там админ разберётся что к чему, покаон место освободит да транзакции накатит (или откатит).
Это я всё к тому, что есть разные задачи. Для них разные СУБД. С разными свойствами и сервисами. И это хорошо. Аминь.
2 ignite
"Не бывает ссылочной целостности у того чего нет" - вот именно, если ты теряешь данные физически, то что говорить о всем остальном?
"Опять пример неудачный. Запустили (после сбоя) базу. Пустили туда юзеров. (а ничего страшного - мы ведь эти записи всё равно УДАЛЯТЬ собирались - ну и пусть пока висят, болтаются). Запустили ещё раз тот длинный delete" - никого никуда не запустили. "Ша! Уже никто никуда не идет!" Ты что. Первый же отчет покажет такую ахинею, за которую могут крепко оттопырить. И как ты собираешься запускать длинный delete по таблице по которой пользователи бродят? Не-е-е-е, так нельзя. Хорошенькое "ура", когда после удаления такой цирк начнется.
Насчет того, что длинной транзакцией любую базу укатать можно - вот это неправда. Нет, то есть, как тут выяснилось Interbase можно, а вот Oracle или Sybase не укатаешь. Получишь либо snapshot too old, либо сообщение о том, что сервер не может увеличить сегмент отката. Ну, это по ситуации. Ничего, попилить транзакцию, сказать:
set transaction use rollback segment rbs_incredible_big,
коммитится каждые 100 тыс записей, а еще и analyze после коммита запустить, я так по несколько миллионов записей удалял.
".. Не уловил мысли..." - мысль была в том, что при соблюдении разработчиками СУБД положений реляционной теории ничья буйная фантазия не породит базу, с которой потом средствами сторонних производителей справиться невозможно. А это дорогого стоит. А то суют чужую разработку, и мыкаешься потом с оракловыми объектами, потому что JDBC через OCI8 просто не работает, а thin драйвер - от и есть thin.
В Sybase свои приколы. Она может сказать, что транзакционный лог переполнен ии приостанавливает транзакцию. Тут шустренько добавляешь еще дофига мегов под лог и едем дальше :)
"Опять пример неудачный. Запустили (после сбоя) базу. Пустили туда юзеров. (а ничего страшного - мы ведь эти записи всё равно УДАЛЯТЬ собирались - ну и пусть пока висят, болтаются). Запустили ещё раз тот длинный delete" - никого никуда не запустили. "Ша! Уже никто никуда не идет!" Ты что. Первый же отчет покажет такую ахинею, за которую Нет, ну если ты ТАК пишешь отчёты, то оно таки да - ТЕБЕ в ТВОЕЙ задаче без транзакций не обойтись, кто ж против. А в другом случае - всё и так будет работать.
могут крепко оттопырить. И как ты собираешься запускать длинный delete по таблице по которой пользователи бродят? Не-е-е-е, так нельзя. Хорошенькое "ура", когда после удаления такой цирк начнется.
Ну исходный то делет на рабочей базе ты запускал ! И отчёты В ТОТ МОМЕНТ как-то шли, а вообще это уже переливание из пустого в порожнее.
Насчет того, что длинной транзакцией любую базу укатать можно - вот это неправда. Нет, то есть, как тут выяснилось Interbase можно, а вот Oracle или Sybase не укатаешь. Получишь либо snapshot too old, либо сообщение о том, что сервер не может увеличить сегмент отката. Ну, это по ситуации. Ничего, попилить транзакцию, сказать: set transaction use rollback segment rbs_incredible_big, коммитится каждые 100 тыс записей, а еще и analyze после коммита запустить, я так по несколько миллионов записей удалял.
Во-первых - не передёргивай - я говорил "укатать СУБД" а не "базу", что есть "две большие разницы" - согласен ? Во-вторых Havoc тебе уже ответил. Да и сам ты возражаешь неубедительно - "попилить транзакцию", это конечно можно, но только подтверждает мою мысль.
".. Не уловил мысли..." - мысль была в том, что при соблюдении разработчиками СУБД положений реляционной теории ничья буйная фантазия не породит базу, с которой потом средствами сторонних производителей справиться невозможно. А это дорогого стоит. А то суют чужую разработку, и мыкаешься потом с оракловыми объектами, потому что JDBC через OCI8 просто не работает, а thin драйвер - от и есть thin.
Так ты и наезжай на разработчиков БД, разработчики СУБД тут ни в чём не виноваты, - они дали средство (расширение), сказали - тут работает - тут не работает. А если твои поставщики мало думали, прежде чем писать - кто в этом виноват ... ?
"ну если ты ТАК пишешь отчёты, то оно таки да - ТЕБЕ в ТВОЕЙ задаче без транзакций не обойтись, кто ж против. А в другом случае - всё и так будет работать. " - это как я пишу отчеты? А ну-ка, конкретизируем задачу: торгаши мы, в первой таблице названия подотчетных магазинов, во второй - продажи по ним. Отчет первый - сумма проданного на надцатое янобря с разбиением по магазинам. Отчет может получится честным. Второй - общая сумма проданного на то же янобря, но в целом. Итого, так сказать(select sum( price * qty ) where ... from child_table). Вопрос знатокам: сойдутся отчеты? Второй вопрос знатокам: где тут транзакция? Подсказка зала: "Рувим! Это называется работать?!"
"В Sybase свои приколы. Она может сказать, что транзакционный лог переполнен ии приостанавливает транзакцию" - можно, я правда, выставлял откат в таком случае. Обычно такое "ж-ж-ж-ж-ж" неспроста.
Там даже есть более лихая штука - last threshold - приращение можно в автомате делать, по необходимости. Но все это было сказано к тому, что нормальную СУБД транзакцией не уработаешь.
Есть и last, можно и своих несколько сделать.
А в Sybase у меня как-то sybsystemproc слетел после падения питания. К счатью это было на тестовой машине и Sybase был только установлен, поэтому ничего героического предпринимать не пришлось :)
