Friday, November 25, 2005

Прочитал за последний месяц

OK, за последний месяц я прочитал достаточно много. Отмечу то, что мне больше всего запомнилось;

  • Oracle8i Internal Services for Waits, Latches, Locks, and Memory. Я даже не стану пытаться угадать сколько времени Стив Адамс потратил на исследование написанных в этой книге вещей. Информации в этой книге более чем достаточно для понимания механизмов блокирования и одновременного доступа в Oracle. Местами не слишком легкое чтение, но стоит того.
  • Effective Oracle by Design. Если вы регулярно читаете сайт AskTom, то скорее всего уже знаете 95% того, что написано в этой книге. Как всегда в прекрасном стиле Тома Кайта. Если вы уже прочитали Expert One-on-One Oracle, то знаете, о чем я говорю. Читается легко и приятно. Том отличается уникальной способность объяснять сложные вещи относительно просто, а так же прекрасно чувствует, когда стоит углубляться в детали, если это лучше поможет понять суть обсуждаемого вопроса.
  • Optimizing Oracle Performance. Cary Millsap написал уникальную книгу по оптимизации производительности Oracle. Вы все еще подсчитываете загрузку процессора, а так же другие усредненные показатели системы? Вы делаете то, что никого не волнует. Перестаньте терять своё время, и сосредоточьтесь на оптимизации бизнесс-процессов. Те из Вас, кто когда-либо сталкивались с оптимизацией действительно больших систем на базе Oracle, прочитают эту книгу на одном дыхании.

Tuesday, November 22, 2005

10000 раз

На форуме Howard Rogers'а на мой вгзляд возникло интересное обсуждение.

Все мы любим рассказывать истории про "тупых" разработчиков.

Или.... или нет?

Или нет. Персонально для меня нет деления на основании того, чем вы занимаетесь (я сам занимаюсь и разработкой и администрированием). Поэтому я никогда не смотрел на вещи с точки зрения разработчик/администратор СУБД. Поэтому - я не стану раскрашивать вас в белый или черный цвет на основании только этого.

Что действительно имеет для меня значение - понимаете ли вы то, чем занимаетесь, или нет. Например, прослушав недавно курс для DBA от Oracle University я могу действительно сказать, что курс не выдерживает никакой критики. Почему?

Потому что вместо "почему", курс нацелен на "как". В итоге вы рискуете выйти с этого курса с большим количеством rules of thumb в голове.

  1. Вы увидели А, сделайте Б. Не забудьте записать что вы сделали на бумажке. В следующий раз сделайте так же.
  2. Для ситуации X подходит Y и не подходит Z.
Теперь вы рискуете получить DBA, которого придется спасать от самого себя. Например, возьмём выражение из курса "Bitmap-индексы не подходят для OLTP систем". Прекрасно... но почему? Потому что в силу своей организации они не могут обеспечить достаточную масштабируемость и скорость обработки множества коротких запросов на изменение данных, которые характерны для OLTP систем. DBA, который знает "почему" - всегда сможет сделать правильный вывод о том, можно или нет применять конкретный тип индекса в данной ситуации. Более того, bitmap-индексы более чем способны найти применение в OLTP системах. В любом случае для меня всегда было проще понимать, как работает та или иная технология, и на основании этого делать выводы о её применимости, чем пытаться составить в голове список что с чем совместимо и в какой ситуации (после первой пары сотен технологий вы все равно поймете что это невозможно).

Поэтому это все о том, понимаете ли вы то чем занимаетесь, или нет. Выглядит для вас все черным ящиком или нет. Можете ли вы объяснить "почему" или нет.

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

Это не "10000-е сообщение о тупом разработчике" это "10000-й разработчик который не имеет представления о том, чем он занимается".