Да я бы не сказал. Традиционно-ориентированные разработчики привыкли к императивному стилю программирования. Сам всё запрограммировал, сам расхлёбываешь. Собственно, что повсеместно и происходит: попытки навязать БД своё видение алгоритма редко бывает удачным, потому что мыслить циклами при работе с БД нельзя. А вот SQL — штука декларативная, там изрядная часть работы происходит за кулисами оптимизатора. И разработчик должен учиться не мешать оптимизатору, и даже наоборот — помогать. То есть переключиться в декларативную парадигму. И администратор тут совершенно ни при чём. Другое дело, что оптимизатор иной раз не справляется, и чтобы разобраться в проблеме и аккуратно её исправить, требуются знания, которые к традиционному программированию отношения вроде как не имеют: все эти трассировки, ожидания, планы запроса... Считать ли это областью ответственности администратора? На мой взгляд, тоже нет.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2011-06-17 06:07 am (UTC)Традиционно-ориентированные разработчики привыкли к императивному стилю программирования. Сам всё запрограммировал, сам расхлёбываешь. Собственно, что повсеместно и происходит: попытки навязать БД своё видение алгоритма редко бывает удачным, потому что мыслить циклами при работе с БД нельзя.
А вот SQL — штука декларативная, там изрядная часть работы происходит за кулисами оптимизатора. И разработчик должен учиться не мешать оптимизатору, и даже наоборот — помогать. То есть переключиться в декларативную парадигму. И администратор тут совершенно ни при чём.
Другое дело, что оптимизатор иной раз не справляется, и чтобы разобраться в проблеме и аккуратно её исправить, требуются знания, которые к традиционному программированию отношения вроде как не имеют: все эти трассировки, ожидания, планы запроса... Считать ли это областью ответственности администратора? На мой взгляд, тоже нет.