Наболело

[akylli]

Вот скажите мне, пожалуйста, нахрена вообще нужны всякие DB Architect, App DBA и прочие проектировщики?

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

Первая же таблица показала:
SQL> select count(COLUMN), COLUMN from OWNER.TABLE_NAME group by COLUMN;

COUNT(COLUMN) COLUMN
866 localFault
8151 remoteFault
45 userFault

SQL> desc OWNER.TABLE_NAME;
Name Null? Type
------------------------------------------------------------------------ -------- -------------------------------------------------
COLUMN VARCHAR2(255)

Вот нахрена так делать? И так почти везде. К стенке таких проектировщиков.

Просто наболело поддерживать такие вот базы.

[shkoda]

Зато они на собеседованиях правильно ответили "кем они хотят быть через 5 лет" и "ваши плохие какчества".

В самом деле зря паришься из-за 9к записей

По твоему примеру, еще во времена клипера видел полянку "трактор\не_трактор" для одной автобазы Это во времена, когда первичные ключи делали строчными для экономии места.

[akylli]

Зато они на собеседованиях правильно ответили "кем они хотят быть через 5 лет" и "ваши плохие какчества".

В самом деле зря паришься из-за 9к записей

По твоему примеру, еще во времена клипера видел полянку "трактор\не_трактор" для одной автобазы Это во времена, когда первичные ключи делали строчными для экономии места.

Ну 9к это первая попавшаяся. Другие таблицы были такие же. Там индексы тока за 10G уже зашкаливали ...

Мне просто обидно видеть, как ресурсы впустую расходуются из-за таких примитивных косяков... Хотя пока они есть, есть работа и у нас

[Marina]

Вот скажите мне, пожалуйста, нахрена вообще нужны всякие DB Architect, App DBA и прочие проектировщики?

А разве выделенные относятся к проектировщикам?
Они же разработчики, нет?

[UpS]

А разве выделенные относятся к проектировщикам?
Они же разработчики, нет?

+1
Архитектор в такое низкоувовневое не полезет. Его задача концепцию описать решения и анализировать и переводить в решение business requirements. Ну а что там уже програмеры накатали ему неизвестно. Да и вообще, если код выдает нужный результат и еще и за требуемое в business requirements время, то какая разница что там внутри?

[akylli]

А разве выделенные относятся к проектировщикам?
Они же разработчики, нет?

Для меня вообще Application DBA что-то темное и непонятное. У нас они как раз занимаются всякой оптимизацией. Ну там индекс где сделать, табличку добавить...

Хотя все это обыкновыенный DBA может с легкостью делать..

[shkoda]

А разве выделенные относятся к проектировщикам?
Они же разработчики, нет?

Apps DBA вполне могут клепать дефекты на такие "решения". По крайней мере уже не в одной моей конторе клепают

Да и вообще, если код выдает нужный результат и еще и за требуемое в business requirements время, то какая разница что там внутри?

У кода не одна характеристика "выдавать что надо за требуемое время". Одна из них - сокращать TCO системы.
Очень давно я привел такой примерчик своему шэфу. Была некая подсистемка, которая решала поставленные перед ней бизнесом задачи. Реализована она была достаточно через Ж, но программеры (3штуки) именно так и отмазывались: "работает - не трогай, Заказчик - доволен". Подсистемка занимала 4 проца, вместо 1го. Расчеты стоимости на тот момент:
- CPU board 290к/4CPU*3CPU=217k , умножить на 2 для DR = 434k
- Oracle Licenses - 3*(40k+20k)*0.18=212.4k
- Oracle support = 212.4k*0.23=48.9k
Итого эти "специалисты" натворили на 646.4к сразу и потом еще по 48.9к ежегодно. Если учесть з.п. программера на тот момент, то это их з.п. лет за 10-15.
На самом деле затраты больше, т.к. еще есть затраты на суппорт HW. Мощность сервера растет заметно медленнее роста его цены: сервер с 16 процами стоит Х, но с 32 уже вполне может быть и 4*Х, а с 64 и 10*Х.

Касательно места указанного akylli , тут тоже не так однозначно как кажется на первый программерский взгляд. Надо учесть ряд факторов:
- стоимость места в SAN на порядки выше стоимости винта в писюке. 1-2TB это то, за что вполне могут напрячь побиться, если контора денежку конечно считает.
- дополнительные денежки за лицензии на storage software. Всякие BCV лицензируются по месту.
- место часто умножается на 10-20-50, т.к. еще надо DR\standby\reporting\development\etc.
- это дополнительное время на восстановление в случае чего
- это бОльшее окно бэкапа и бОльшее количество лент
- это дополнительное время при создании environments для самих же программеров

[akylli]

Архитектор в такое низкоувовневое не полезет. Его задача концепцию описать решения и анализировать и переводить в решение business requirements. Ну а что там уже програмеры накатали ему неизвестно.

Вот тут я не соглашусь. То, что вы описали - это Data Architect a не Database. Плюс вы путаете программирование и физическую структуры базы.

Да и вообще, если код выдает нужный результат и еще и за требуемое в business requirements время, то какая разница что там внутри?

Опять же я ничего не говорил про код. Код то может быть и правильным, но вот скорость получения результатов не оптимальна. Ведь есть разница между чтением 10Гб и 100Мб

Плюс дополнительные издержки в виде увеличенного использование памяти, дисков, бэкапа и т.д
В идеале application программист должен работать с базой, как с черным ящиком. То есть нужно, например, получить кол-во заказа за какой то день, то дергаются процедуры базы и получается результат. А вот процедуры пишут уже другие программисты, хорошо знакомые с базой. Какой плюс? Можно менять структуры базы как угодно, и надо будет только переписать процедуры, не трогая бизнес логику.

Хотя все это и спорно, но имхо это самый лучший и оптимальный вариант.

Вообще-то частенько обязанности всех этих Architect, App DBA и DBA туманны и пересекаются.

[akylli]

Apps DBA вполне могут клепать дефекты на такие "решения". По крайней мере уже не в одной моей конторе клепают


У кода не одна характеристика "выдавать что надо за требуемое время". Одна из них - сокращать TCO системы.
Очень давно я привел такой примерчик своему шэфу. Была некая подсистемка, которая решала поставленные перед ней бизнесом задачи. Реализована она была достаточно через Ж, но программеры (3штуки) именно так и отмазывались: "работает - не трогай, Заказчик - доволен". Подсистемка занимала 4 проца, вместо 1го. Расчеты стоимости на тот момент:
- CPU board 290к/4CPU*3CPU=217k , умножить на 2 для DR = 434k
- Oracle Licenses - 3*(40k+20k)*0.18=212.4k
- Oracle support = 212.4k*0.23=48.9k
Итого эти "специалисты" натворили на 646.4к сразу и потом еще по 48.9к ежегодно. Если учесть з.п. программера на тот момент, то это их з.п. лет за 10-15.
На самом деле затраты больше, т.к. еще есть затраты на суппорт HW. Мощность сервера растет заметно медленнее роста его цены: сервер с 16 процами стоит Х, но с 32 уже вполне может быть и 4*Х, а с 64 и 10*Х.

Касательно места указанного akylli , тут тоже не так однозначно как кажется на первый программерский взгляд. Надо учесть ряд факторов:
- стоимость места в SAN на порядки выше стоимости винта в писюке. 1-2TB это то, за что вполне могут напрячь побиться, если контора денежку конечно считает.
- дополнительные денежки за лицензии на storage software. Всякие BCV лицензируются по месту.
- место часто умножается на 10-20-50, т.к. еще надо DR\standby\reporting\development\etc.
- это дополнительное время на восстановление в случае чего
- это бОльшее окно бэкапа и бОльшее количество лент
- это дополнительное время при создании environments для самих же программеров

Все верно шкода описал. У нас тот же терабайт переходит в UAT, Test, DEV + время на синхронизацию всего этого.

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

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

[Bormental]

Зато они на собеседованиях правильно ответили "кем они хотят быть через 5 лет" и "ваши плохие какчества".

a кстати как правильно отвечать?

[shkoda]

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

Если ты очень далеко от бабкодающих, то скорее всего не получиться. Но ведь не всем же насрать что у вас бардак? Может есть кто выше, кому не насрать и он поближе к бабкодающим?
Уже дважды в разных конторах от достаточно больших манагеров слышал формулировку: "Надо соблюдать баланс качества и количества индусов".

a кстати как правильно отвечать?

Правду

[Bormental]

Правду

неправилъный ответ
правда нужна только венерологу, а в собеседовании она вредна

[akylli]

неправилъный ответ
правда нужна только венерологу, а в собеседовании она вредна

Ну это смотря какая правда.

[akylli]

Если ты очень далеко от бабкодающих, то скорее всего не получиться. Но ведь не всем же насрать что у вас бардак? Может есть кто выше, кому не насрать и он поближе к бабкодающим?
Уже дважды в разных конторах от достаточно больших манагеров слышал формулировку: "Надо соблюдать баланс качества и количества индусов".

Правду

Мы просто тупо оутсорсим базы данных.

[Zaporozhets]

a кстати как правильно отвечать?