Это отрывок из моей книги Как избежать ИТ-катастроф

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

В 1970 году, после того как Э. Ф. Кодд предложил использовать реляционное исчисление математики в качестве модели для базы данных, потребовалось значительное время, чтобы придумать программную реализацию. Реляционную базу данных действительно легко реализовать, если вас не заботят какие-либо проблемы с эффективностью или хранением. В конце концов, все это описывается в математике как операции между таблицами. Реализовать в памяти легко. Однако заставить реляционную базу данных работать с небольшим объемом памяти и хранить большую часть данных на диске - невероятно трудная проблема. Это было особенно актуально в 1970-х годах, когда память была такой маленькой и дорогой, а скорость передачи данных на диск была такой низкой. Это было настолько сложно, что потребовались годы, чтобы придумать код, который действительно можно было бы использовать в системе.

То, что произошло, было одним из тех идеальных штормов эффектов, которые выдвинули реляционную базу данных на первый план.

Во-первых, имя. Большинство людей неверно истолковали это и думали, что реляционная база данных на самом деле выражает отношения, вместо того, чтобы понимать, что реляционная база данных представляет собой данные, выраженные в виде набора сеток с именованными столбцами и строками данных, которые содержат абсолютно нет истины. информация о взаимоотношениях, но ею можно манипулировать, чтобы выразить любые «отношения», полезные или бесполезные. В реляционной базе данных вы можете выразить совершенно бесполезные отношения так же легко, как и полезные.

Имя было цепляющим. Люди думали: «Да, организации основаны на отношениях, и база данных должна уметь их выражать». Они понятия не имели о разрыве между этой концепцией причинно-следственных связей и абстрактной концепцией математических отношений.

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

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

В то время были и другие архитектуры баз данных. Одной из них была так называемая многозначная база данных, в которой Pick был доминирующей. Он получил свое описание из того факта, что запись может хранить список значений, а не, как в реляционной базе данных, разделять его и хранить в отдельной таблице. Я построил системы, использующие оба типа баз данных, и могу определенно сказать, что это было намного проще и я был более продуктивным с многозначной базой данных, чем с реляционными. Я заметил, что клиенты, использующие многозначные типы баз данных, как правило, были намного счастливее. Изменения были проще, и новые отчеты были быстрыми. Надежность была выше.

Но у него не было такого шумихи, как у «реляционных». IBM была на стороне реляционных технологий, потому что это была теория, разработанная их исследователями, а в те дни IBM была 800-фунтовой гориллой компьютерной индустрии. Итак, если IBM сказала, что это хорошая технология, кто будет с этим спорить? Другие компании увидели возможность. Базы данных всегда были интегрированы в программное обеспечение. Теперь они могут быть отдельными компонентами и оплачиваться отдельно.

Шумиха вокруг названия «реляционный» породила рыночный спрос не только до того, как появился продукт, но даже до того, как кто-то действительно узнал, можно ли его реализовать. Люди говорили о реляционных базах данных, и производители программного обеспечения объявили, что скоро будут готовы. Сочетание этого предварительно проданного спроса и идеи о том, что они могут быть проданы как другой компонент по отдельной цене, было непреодолимым. Компании, понимая, что это может быть очень прибыльно, лихорадочно начали разрабатывать реляционные базы данных.

Учитывая шумиху вокруг этого названия и возникшую мифологию о том, что оно основано на математике, оно выглядело передовым и, ну - сложным - и, следовательно, ценным. Люди «знают», что в физических системах комплекс означает ценность. Чем более технологически сложные компании могли сделать свое программное обеспечение надежным, тем больше они могли бы за него брать.

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

Это создало потребность в миллионах строк исходного кода, созданных большой командой. Это означало, что, судя по количеству кода в программном обеспечении реляционных баз данных, они были сложными, и здравый смысл нашего физического мира говорит, что сложные вещи решают сложные проблемы и, следовательно, являются более ценными. Тот факт, что существовали гораздо лучшие архитектуры баз данных, которые решали бы те же проблемы с гораздо меньшей сложностью, не был в духе времени. Здравый смысл физического мира говорит, что более сложный продукт более ценен, поскольку эта ценность прямо пропорциональна сложности, даже если это не относится к программному обеспечению.

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

Это своего рода самоподкрепляющийся аргумент, который в извращенном смысле довольно элегантен. Но что он сделал, так это дал толчок, который положил начало идеальному шторму.

Этот идеальный шторм был порождением сложности, который стал своего рода золотой лихорадкой среди технологических компаний. База данных как отдельный компонент не имела большого значения в 1960-х и начале 1970-х годов. Большинство приложений включают некоторый готовый код, который записывает и читает файлы на диске. Одна система ERP, которую я написал для национальной инженерной компании, использовала стандартные файлы для хранения данных с простыми индексами для быстрого поиска.

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

Следует отметить, что текстовая природа интерфейса, которая, как мы видели в предыдущей статье, является гигантским недостатком безопасности, действительно сделала возможным упаковывать эти базы данных как отдельные модули. Более сложный интерфейс, который был бы более эффективным и безопасным, потребовал бы более тесной связи между прикладным программным обеспечением и программным обеспечением базы данных. Это сделало бы его менее переносимым между системами. Маркетинговая необходимость упаковать базу данных как отдельный продукт повлияла на архитектуру программного обеспечения - к сожалению, для мировой производительности.

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

Я уже упоминал об избыточности ответов из реляционных баз данных. Каждый «набор результатов» обычно имеет информацию заголовка, дублированную в каждой записи.

Например, табель учета рабочего времени имеет верхнюю часть (заголовок) с номером сотрудника и датой. Табель учета рабочего времени имеет список строк переменной длины, в котором указаны отработанные часы и проект. Чтобы сохранить в реляционной базе данных, все заголовки хранятся в одной таблице, а все строки со временем и проектом хранятся в другой. Итак, когда вы хотите вернуть табель учета рабочего времени, база данных должна просканировать подробные строки для всех табелей учета рабочего времени (это может быть очень большое количество) и выбрать те, которые принадлежат нужному вам табелю. Это возвращает список подробных строк, к каждой из которых прикреплена информация заголовка. Другими словами, если у вас есть десять записей времени в расписании, вы получите обратно десять строк с информацией о времени и проекте плюс информация заголовка, то есть номер сотрудника, дата и т. Д. Таким образом, этот номер сотрудника и т. Д. Дублируется десятью раз. В более медленных сетях для передачи этого большого количества избыточных данных требуется много времени. В спешке разделить системы на большее количество компонентов, чтобы за них можно было оплачивать отдельно, некоторые компании осознали, что эта избыточность влияет на скорость, с которой результаты возвращаются по сетям, потому что предыдущие сети были очень медленными.

То, что было дальше, является прекрасным примером того, как взять последствия плохо спроектированной технологии и продать решение для нее. Во всей избыточности нет необходимости. Программа хочет расписание с одной копией заголовка, а не этот искусственный, чрезмерно большой набор данных, из которого можно построить расписание. Но вместо решения основной проблемы, заключающейся в том, что реляционная база данных была не очень хороша в сетевых средах из-за этого неэффективного способа возврата данных, компании-разработчики программного обеспечения решили вместо этого продавать программное обеспечение, которое удаляло бы и повторно вставляло эту избыточность. В частности, код удалил все лишние копии заголовка перед его отправкой по сети, а принимающая программа вернула все обратно, чтобы программист получил его в том виде, в каком он был отправлен. Прелесть этого в том, что компании должны брать деньги за это программное обеспечение. Они дали ему название «промежуточное ПО». Было гораздо выгоднее продавать программное обеспечение для компенсации архитектурных дефектов, чем исправлять саму архитектуру и делать ее логичной и эффективной.

Наличие базы данных как отдельного объекта, часто на отдельном сервере, означало, что возникла целая проблема аутентификации, поэтому код интерфейса базы данных должен был быть установлен на клиентах. Затем промежуточное программное обеспечение, если оно использовалось, должно было быть вставлено между этим и программным обеспечением сетевой связи. Это начинает быть очень сложным. Шансы на неудачу бывают самые разные. Есть два конца промежуточного программного обеспечения, которые необходимо поддерживать в синхронизации, что касается версий.

Вся эта сложность приносила деньги. Корпорации были готовы платить большие деньги за повышение скорости и покупку программного обеспечения для баз данных. Все чаще и чаще ERP-системы превращались в модули для монетизации. Разделение на дополнительные модули значительно усложняет систему. Удивительно, как принуждение частей к самодостаточности и недопущение того, чтобы они ожидали, что там будут другие модули, может создать некоторые сложные логические проблемы, которые программист должен решить. Но программы, которые определяют эти решения, принимаются компаниями-разработчиками программного обеспечения, поэтому для конечного пользователя прибыль важнее стабильности. Фактически, нестабильность также является центром прибыли. Вы можете винить проблемы с программным обеспечением в плохом обучении и продавать дополнительные учебные курсы. Дополнительный доход поступает от платы за консультационные услуги, платы за обслуживание и обновлений.

К концу 80-х годов золотая лихорадка была в самом разгаре. Деньги начали поступать в индустрию корпоративного программного обеспечения. Оказывается, сложность очень выгодна.

Так оно и оставалось последние тридцать лет. Это привело к усложнению и негибкости ERP-систем, что в значительной степени увеличило количество отказов.

Однако во всем этом есть скрытая ирония. Базы данных - это аномалия, которая будет существовать только в течение определенного периода времени, пока наше оборудование все еще находится в примитивной стадии. Будущие поколения будут рассматривать базы данных в том же свете, что и мы с глючными кнутами - полезными в прошлом, но теперь просто забытой частью старых технологий. (См. Базы данных: Будущие ошибки в программном обеспечении)

Это отрывок из моей книги Как избежать ИТ-катастроф, в которой совершенно иной взгляд на корпоративные вычисления.

✉️ Подпишитесь на рассылку еженедельно Email Blast от CodeBurst 🐦 Подпишитесь на CodeBurst на Twitter , просмотрите 🗺️ Дорожная карта веб-разработчиков на 2018 год и 🕸️ Изучите веб-разработку с полным стеком .