MySQL в авиации

>так и не ответил ни на один вопрос - когда и как это происходило

хм. А зачем? Что бы это изменило? Ну положим было на debian/woody, на неразогнанной тачке-рутере. мыскуль из дистрибутива. Происходило _постоянно_. Хм. Кстати очень позабавило утверждени о том, что индексы могут попадать из-за кривого клиента.

>REPAIR TABLE >это все осталось твоей точкой зрения, ничем не подтвержденной

REPAIR TABLE предполагает нарушение целостности таблиц по причинам отличным от аппаратных сбоев и ошибок клиентских программ. СУБД _изначально предполагает_ нарушение структуры данных (причём без генерации каких либо сообщений). Какие ещё нужны "подтверждения"? Неуж такая ностальгия по фокспро-клипперу?

>innodb поддерживает все 4 уровня изоляции

начиная с версии 4.0.x, кторая ещё нет в debian/stable. А значит, пусть пока на грабли понаступают те, кто за это деньги получает.

>DB2, где вообще чехарда с названиями уровней изоляции

...по понятным причинам :)

ланна. Интересно... Если я раскажу о том, что DELETE FROM xx WHERE id=yy выполнялось несколько минут, то опятю же буду послан писать багрепорты?

<цитата> >innodb поддерживает все 4 уровня изоляции

начиная с версии 4.0.x, кторая ещё нет в debian/stable. А значит, пусть пока на грабли понаступают те, кто за это деньги получает. </цитата>

Ах вот оказывается какой у Вас критерий! Надежность или убогость программы оказывается зависит от того, входит ли она в конкретный дистрибутив! Чтож Вы сразу не сказали? ;-) Мы бы и не парились, доказывая вам что-то.. Кстати, А IBM DB2 какой версии в debian/stable?

<цитата> REPAIR TABLE предполагает нарушение целостности таблиц по причинам отличным от аппаратных сбоев </цитата>

Вот для меня это как-то не очевидно. Поясните, почему REPAIR TABLE предполагает нарушение целостности таблиц по причинам отличным от аппаратных сбоев.

>>REPAIR TABLE >это все осталось твоей точкой зрения, ничем >> не подтвержденной

>REPAIR TABLE предполагает нарушение целостности таблиц >по причинам отличным от аппаратных сбоев и ошибок >клиентских программ.

Кто это сказал ? Repair Table предполагает попытку восстановления таблиц из того, что от них осталось, вне зависимости от причины. Втом числе и после аппаратного сбоя.

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

> мыскуль из дистрибутива.

короче это было так давно, что версии уже не помнишь.

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

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

> REPAIR TABLE предполагает нарушение целостности таблиц по причинам отличным от аппаратных сбоев и ошибок клиентских программ.

ссылку на автора, плеасе. Если это твое мнение, то предполагаешь что клиентская прграмма обрушила таблицы? ;-) Читаем:

REPAIR TABLE работает только на таблицах типа MyISAM и эквивалентна выполнению на таблице myisamchk -r table_name

Не больше не меньше. И надежней чем myisamchk. Пояснять не буду.

> Неуж такая ностальгия по фокспро-клипперу?

Не испытываю, поскоку никогда не работал с ними.

> Если я раскажу о том, что DELETE FROM xx WHERE id=yy выполнялось несколько минут, то опятю же буду послан писать багрепорты?

Тебе уже вряд ли что поможет.

----------- hidden

зашел я тут посмотреть скоко постов наваяли (автор новости) и офигел, какая ж@посвербящая проблема однако, сравнение мускуля с другими DBs.

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