Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.
В Соединённых Штатах в 1920х годах производство, продажа и импорт алкогольных напитков был запрещён конституционной поправкой. Поправка была отменена спустя 13 лет. За время этого запрета пивная отрасль умерла.
В 1933, когда запрет был снят, несколько зерновых гигантов стали варить пиво. Они полностью монополизировали рынок. И в течении почти 50 лет мы в Штатах пили эту газированную мочу и называли её «пиво». Единственным способом терпеть этот вкус — было пить его очень холодным.
Будучи в 60х подростком, я никогда не понимал его привлекательности. Почему пиво? Это же бледно-жёлтая, противная жидкость получаемая из мочи больных хряков. И я не мог найти ни одного веского плюса.
В 1984 я отправился в Англию, и шоры упали с моих глаз. На конец я понял. Я впервые попробовал пиво и оно оказалось хорошо.
С тех пор ситуация с пивом в США значительно улучшилась. Новые пивоваренные компании растут по всей стране как грибы, и в большинстве случаев пиво, которое они делают, действительно очень хорошее. У нас нет ничего столь прекрасного как биттер (горькое охмелённое пиво), но мы догоняем.
В 80х несколько больших компаний своими базами данных монополизировали рынок. Они сделали это насаждая страх, неуверенность и сомнения среди менеджеров и маркетологов. Слово «реляционный» стало синонимом «качественный», и любой другой способ хранения данных стал запретным.
В те времена я был ведущим разработчиком. Наша система измеряла качество линий связи Т1. Наша модель данных была относительно проста, и мы хранили данные в простых файлах. Это работало нормально.
Но наш маркетолог продолжал говорить нам, что мы должны использовать реляционную базу данных. Он сказал, что клиентам она потребуется. Мне казалось что это странное желание, поскольку тогда мне ещё не продали ни одной системы, и ни один покупатель ни разу не интересовался нашим способом хранения данных. Простые файлы были под запретом.
С точки зрения меня, ведущего разработчика, ответственного за качество программного обеспечения, реляционные базы данных это большой, грубый, медленный геморрой. У нас не было сложных запросов. Нам не нужны были мощные возможности построения отчётов. Нам определённо не нужен был многомегабайтный процесс сидящий в памяти и пожирающий такты. (Учтите это были 80е.) Так что я отбивался от этой идеи как только мог, ведь это было неправильное техническое решение.
Это было политически недальновидно с моей стороны. В течении нескольких месяцев инженер-железячник, который умудрился написать пару строчек кода, был переведён в группу ПО. Ему постепенно поручали всё больше и больше обязанностей, и, в конце концов, он стал называться моим соменеджером. Он и я «разделяли» ответственность за управление командой разработчиков.
Угу, Конечно. Точно. Железячник без реального опыта программирования собирался «помочь» мне управлять командой. И какой, вы думаете, был первый пункт? Почему бы не использовать реляционную базу данных в нашей системе!
Я уволился месяц спустя и начал карьеру консультанта. Это было лучший карьерный ход, который я когда либо делал. Компания, откуда я уволился, больше не существует. Думаю они не заработали ни копейки.
Я наблюдал за рынком реляционных баз данных в 90х. Я видел как все другие технологии хранения данных, такие как объектные базы данных и базы данных на B деревьях, вырождались и умирали. Как пивовары в 20х. К концу 90х уцелели только гиганты.
Эти гиганты гнали волну. Они были богами. Они правили. Во время пузыря доткомов, один из них набрался наглости запустить рекламу на телевидении, в которой заявлялось, что их система была «силой которая управляла интернетом»(the power that drove the internet). Это напомнило мне слоган пива из 70х — «Мну должен зохватить весь кайф, какой смогу». О боже.
Тогда я с ужасом наблюдал, как команда за командой ставила базы данных во главе угла их систем. Они были убеждены бесконечным очковтирательством, что модель данных это самый главный аспект архитектуры и база данных это сердце и душа проекта.
Я был свидетелем возникновения новой должности. Администраторы баз данных! Простым программистам нельзя доверять данные — так гласила маркетинговая чушь. Данные слишком ценны, слишком хрупки, слишком легко повреждаются этой не обученной деревеньщиной. Нам нужны специальные люди для управления данными. Люди, натренированные поставщиками СУБД. Люди, которые будут оберегать и пропагандировать послания гигантов СУБД рынку: «Базы данных это основа. Основа системы, основа предприятия, основа мира и самой вселенной. БУ-ГО-ГА-ГА-ГА-ГА!!!»
Я наблюдал, как SQL пролез в каждый закоулок систем. Я кричал от ужаса из-за систем в которых SQL просочился в интерфейс. Я бесконечно ругался на перенос всей бизнес логики в хранимые процедуры. Я с дрожью и содроганием читал программы рассылки почты, написанные на SQL.
Я бил в набат, видя как таблицы и строки проникают в исходный код системы за системой. Я сигналил об опасности. Я предупреждал. Я говорил, что методика превратилась в амёбу, поглощающую всё в поле видимости. Но я знал, что все мои предупреждения это глас вопиющего в пустыне.
А потом, в первом десятилетии 21го века, запрет был снят, и было рождено движение NOSQL. Я считал это каким-то чудом, сияющим светом озарения. Наконец кто-то осознал, что могут быть в мире системы, которым не нужны большие, жирные, медленные, дорогие, пожирающие память реляционные базы данных!
Я с умилением смотрел как BigTable, Mongo, CouchDB и другие милые маленькие системы баз данных начали расти, прямо как маленькие пивоварни в 80х. Пиво вернулось! И оно становиться вкусным.
Но потом я приметил кое-что. Некоторые системы, использующие эти милые, простые, изящные не реляционные базы данных, были спроектированы вокруг баз данных. Базы данных, завёрнутые в сверкающие новизной фрэймворки, по-прежнему в основе! Это в мозгах проектировщиков аукается ядовитая реляционная рекламная чушь. Они по прежнему делают роковую ошибку.
«Стойте!» — Я закричал. — «Стойте! Вы не понимаете. Вы не понимаете.» Но импульс был слишком велик. Возникла огромная плеяда фреймворков, она обрушилась на нашу отрасль и овладела миром. Эти фреймворки охватили базы данных и бились за захват и удержание ядра вашего приложения. Они были призваны управлять и укращять базы данных. Даже утверждалось, что они могут превратить реляционную базу данных в базу данных NoSQL. И фреймворки громогласно кричали на весь мир: «Положись на меня и я сделаю тебя свободным!».
Название этой статьи «Не БД». Возможно после этих разглагольствований вы получили намёк, почему я назвал её так.
Основа вашего приложения не база данных. И не один или несколько фреймворков, которые вы можете использовать. Основа вашего приложения — сценарии его использования.
Я с ума схожу, когда слышу как разработчик описывает свой проект в стиле: «Tomcat со Spring'ом и Hibernate на Oracle'е». Сама формулировка ставить фреймворки и базы данных во главу угла.
Как Вы думаете, на что похожа архитектура этой системы? Думаете вы найдёте сценарии использования в основе проектирования? Или Вы обнаружите, что исходный код подогнан, чтобы лучше вписываться в модель фреймворка? Заметите ли вы, что бизнес объекты подозрительно напоминают строчки таблиц? Замарает ли все схема данных и фреймворк?
Вот как должно выглядеть приложение. Сценарии использования должны быть самыми важными и наиболее заметными архитектурными объектами. Сценарии использования это основа. Всегда! Базы данных и фреймворки — детали! Вам не нужно выбирать их с самого начала. Вы можете отложить их на потом, до тех пор, пока все сценарии использования и бизнес логика не будут сформулированы, записаны и проверены.
Когда лучше определиться с моделью данных? Когда вы знаете, какие есть объекты данных, как они связаны и как они используются. Когда вы это узнаете? Когда все сценарии использования и бизнес правила записаны и проверенны. К тому моменту вы определились со всеми запросами, отношениями и элементами данных и вы сможете построить модель данных, которая отлично подойдёт к базе данных.
Что-то измениться если вы используете NoSQL базу данных? Конечно, нет! Вы по прежнему сосредоточены на том, чтобы сценарии использования были записаны и проверенны, не обращая внимание на тип базы данных перед тем, как даже подумать о базе данных.
База данных, участвуя в ранних этапах проектирования, исказит архитектуру проекта. Она будет сражаться за сердце системы, и однажды проникнув туда, закрепится там как жевачка в волосах. Надо постараться, чтобы не пустить базу данных в сердце вашей системы. Необходимо постоянно говорить «Нет» искушению скорее заняться базой данных.
Впереди интересное время. Время, когда запрет на различные технологии хранения снят, и мы можем свободно экспериментировать со множеством новых подходов. Но и во время игры с CouchDB, Mongo и BigTable не забывайте: База данных это просто компонент, который не требует немедленных решений.
Автор: 4dmonster
