OCP  
line decor
  Начало  ::  
line decor
   
 
JABORAC Април 2006

Всички го усещаме. Тихото напрежение между developers и DBAs. Сякаш не сме в един отбор. Сякаш нямаме общи цели. Сякаш сме конкуренти, а не колеги и приятели. От къде извира това напрежение?

Идва от живота в различни светове. Да, вярвно, повечето DBA са били програмисти някога. Поне в България, наблюденията ми са такива. Но веднъж станали DBA, ние много бързо (само за година - две) забравяме как се пише код. Е, имаме си нашия PL/SQL, може да драснем нещо мъничко и на Java. Но това няма нищо общо с работата на програмистите.

От другата страна стоят девелопърите. Те са обучавани на разни езици, писали са по много проекти с разни продукти, може би дори върху разни платформи. Може да са писали database приложения, графични приложения, драйвери, всякакви приложения.... Изследвали са разни алгоритми (поне в МЕИ-то), или пък не са - няма значение. За тях БД е Just A Bunch Of Rows And Columns (JABORAC). Те не изпитват нуждата от първичен ключ. Не могат да си представят как работи заявката им. Не са чували за оптимизатора на заявките, да не говорим - да го познават. Не познават нашите приятели PMON, SMON, DBWR, LGWR, CKPT и компания. Какви са основните проблеми в тяхното мислене? Проблема е в мисълта за БД като "черна кутия".

1. "Пускам една заявка и тя минава". Това е то. Как става, защо? БД е една черна кутия. Има едни заявки на входа и едни резултати на изхода
Е, ако не мислиш за това как се раползгат данните, кой ги чете, кой ги записва, кой ги премята - няма как да измислиш добра заявка. "Но я чакай! Това какво се случва в БД не е моя работа! Има си администратори..." Обаче DBA не могат да измислят всеки един SQL в приложението.

2. "Дали сме XXXXX долара/евро/лева за най-добрия database engine. Той ще се справи дори и с милионни таблици."
Да, така е. Ще се справи. Но само ако попиташ "учтиво". Мисълта, че БД може да понесе всяко произволно натоварване е много опасна. Особено опасна е ако се зароди в мениджърско съзнание. А мениджърските съзнания имат склонността да зараждат такива мисли. Още по-лошо е последствието: "Ама то работи много бавно. Направи го да работи бързо!".

3. "Аз само една малка заявчица тук ще си пусна...."
И така няколко десетки хиляди пъти. От няколко стотин работни станции. И после идват едни странни въпроси... Тази грешка има и много лошо разклонение. По принцип девелопърите пишат (обикновено) приложение, което ще се изпълнява на компютъра не един потребител и ще каквото потребителя иска в момента. Обаче БД е една, БД е обща. Проблемите за скалируемаостта са значително по-безобидни в application-а, от колкото в БД.

4. "Дай да го напишем някак, после ще го оптимизираме".
Ах, как съм излизал от кожата си от такива неща... "Дай да го направим така" - "Ама така ще е бавно" - "Нищо, направи го, после ще го мислим". Нещото се пише, пуска се в production и после "Ама то е много бавно, оправи го". Много подъл подход. И за проблема обикновено се обвинява БД - тя не работела както трябва. За това DBA трябва много стабилно да отблъсква опити за този подход. Практиката сочи, че това е много много тежък удар в по--късен (и много неподходящ) момент.

5. "Знам, че това е тежка заявка. Ще предупредим потребителя да чака/Ще я пуснем в backgroud"
Това е малко както малката заявчица, пусната хиляди пъти. Липса на скалируемост. Защото ако един потребител пусне тежката заявка и чака, и втори, и трети... потребителите с леките заявки започват да нервничат, защото и техните неща започват да се бавят драстично. И това обикновено става когато някоя фактура трябва да се пусне много спешно, ето го, клиента чака и потропва.... Пускането на заявката в backgroud е като заравянето на главата на щтрауса, който се опитва да се скрие. Не помага.

6. "Не ме занимавай с първични ключове/нормализация/еди-какво си..."
Да, трудно се обяснява на програмиста, че не работи с автоматизиран Excell Spreadsheet, а с RDBMS. Колкото и странно да е, програмиситите ходят на курсове за програмиране, семинари за development tools, четат статии за алгоритми, образоват се с много книжки, но не се интересуват от релационния модел. А Едгар Код го е събрал на 12 страници (е, и теорията на отностиелността е публикуван от Айнщайн на 3 странички, но това е друга тема)

7. "Нашето приложение трябва да бъде database-independent".
Ах, ако можех да вземам по една стотинка за вски 1000 долара, пропилени поради "database-independent" приложения... Това е тема за една цяла статия. Или за 10. Освен че database independance е невъзможен ако не се изгради отделен, голям, тежък и скъп abstraction layer, това е и огромен проблем за производителност/скалируемост и т.н. Различните БД работят по толкова различен начин, че просто няма никакъв начин, какъвто и стандарт за ANSI SQL да има наложен над приложението, то да се вземе от едната БД и да тръгне на друга. Е, освен ако не е тип "курсов проект". А така се пропускат тооолкова много ползи от различите database features... На практика се заплаща висока цена и не се постига нищо. Абсолютно.

Решението е в обучение. Задължително. И качествено. Поне на основите. Сигурен съм, че девелъпърите нямат нищо против да изклушат някоя добра лекция за БД. Просто такава не се предлага. За това database екипа трябва да поеме нещата в свои ръце и да съчини една-две лекции, които да се развиват през няколко месеца. Програмистите, по своята природа, не са лоши. Искат да се развиват. Ако успеем да предизвикаме интереса им, те дори ще питат за още. Наистина, просто трябва да се започне от нещо. Истината е, че при изграждането на едно database приложение не може да се игнорира database частта. Тя си е в името, даже.

Явор

Ако успея да съчиня добра лекция ще я тествам върху нашия development екип. Нядявам се да има добри последствия. Ако е така - обещатам да кача слайдовете :-)