DBA срач

[metaclass]

Ссылко.

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

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

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

Comments

[metaclass.livejournal.com]

А это в каком стиле разработки-поставки-общения с клиентами делается? Коробочный продукт, заказное приложение, in-house разработка или еще что?

[sergiej.livejournal.com]

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

[vp.livejournal.com]

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

[molnij.livejournal.com]

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

[chepikoff.livejournal.com]

Нельзя не признать, что среднестатический прикладной СНГ софт написан зачастую очень херово и от пожеланий клиентов отмахиваются, как от назойливых мух. Но настоящий админ посылает всех нахуй и делает только свою работу. Либо идет работать крутым DBA, там денег больше.

[max630.livejournal.com]

> За интеграцию как правило берется сумасшедшая деньга

гы :) кто бы мог подумать...

[inhate.livejournal.com]

Есть два варианта:
1) Поставщик решения отвечает за его работу своим баблом согласно SLA. Клиент покупает железо нужной концигруации, лицензии на ПО и далее видит эксплуатируемое поделие сугубо черезе пропиленое в firewall отверстие. Доступ к БД - на чтение, модификация всех данных в целях интеграции - через процедуры.
2) Покупается некай полусырая поделка as-is, которую приходитя допиливать по месту своими силами, интегрировать с чем-либо еще, чего возможно еще не существует. Тогда, конечно, можно всё. Ну и коенчно надо быть готовым к тому, что пидарки будут любой свой баг объяснять действиями эксплуатирующей организации даже не разбираясь с причинами. С такими "партнерами" надо работаьт тихо, аккуратно, иметь крепкие яйца и хорошо составленый контракт.

бывает, конечно...

[az-from-belarus.livejournal.com]

Когда имеет место исторически сложившееся многообразие всяческих баз, да еще разбросанный по разным серваками и т.п. И когда бывает нужно добавлять всяческие имеющие смысл лишь в течение короткого периода функции (при разборе полетов в случившейся внештатной ситуации). Т.е. когда какая-то часть бизнес процессов заведомо постоянно меняется. Ну и когда поставщиков этих самых баз и соответствующих приложений - более одного и даже двух.
Вот только примеры задач, которые привел человек и подходы по их решению - не совсем те. И за такой подход требуется стучать по рукам и действительно снимать с поддержки.
Добавлять в таблицу завязанную в чужой системе поля, индексы и триггеры - моветон. На худой конец - добавляется сбоку таблица, да и то после анализа производительности. И то, если есть поддержка и контакт с разработчиком, то подобные новшества корректней согласовывать.
Ну, приведу пример, когда действительно своему ДБА нужно чего-то делать. Например какая-то информация должна из базы падать на чертежи в автокаде или наоборот извлекаться из автокадовских файлов. А разработочик энто базы с автокадом в жизни ни разу не встречался, а лишь с бухгалтерией имеет дело.

ПС.

[az-from-belarus.livejournal.com]

Вообще, нормальный ДБА должен хорошо понимать границы того, что можно делать самостоятельно, а что нужно обязательно согласовывать. Тот кто вызвал у Вас раздражение в связи с тем что "DBA клиентов лезли в схему данных прикладного софта, "оптимизировали индексы" и занимались прочими улучшениями" - это очень хреновый ДБА, которого лучше гнать метлой.
От таких можно ждать ОЧЕНЬ больших неприятностей измеряемых порой недельными и более доходами предприятия.