DBA срач

[metaclass]

Ссылко.

Вы мне скажите, это что, действительно принято, чтобы DBA клиентов лезли в схему данных прикладного софта, "оптимизировали индексы" и занимались прочими улучшениями?

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

Я понимаю, что для больших объемов данных могут понадобится какие-то дополнительные действия по настройке, но очевидно, что делать их должны совместно админы клиента и представители поставщика софта, чтобы не оказалось, что у 200 клиентов 200 разных баз и никто не знает, что там и как.

Comments

[sergiej.livejournal.com]

Оптимализация индексов обычно разрешена DBA, но не в таком режиме: ковырялся увидел да и поставил индекс. А в нормальном потоке разработки, нашёл проблему, написал: обнаружено неоптимальная работа запроса такого-то в связи с отсутствием индекса/кривыми джоинами/кривыми руками, в связи с этим прошу внести в схему такие-то изменения и разработчикам модуля ХХХ оптимализировать их криворукий запрос, либо докупить очередные 32 гигабайта памяти, чтобы база могла работать с этой кривизной.
Естественно в режиме хотфикса DBA может хоть всю базу на голову поставить, что не позволяет ему делать что хочется, схема это часть приложения. А если он там для оптимализации копает что-то чисто в администрации базы, без изменения схемы - флаг ему в руки.

[vp.livejournal.com]

вот, только так и можно

[molnij.livejournal.com]

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