Что я говорю деловым людям о том, почему реляционные базы данных настолько плохи
Ниже приводится то, что я написал в своей книге Как избежать ИТ-катастроф, чтобы объяснить деловым людям, почему реляционные базы данных являются причиной стольких проблем в корпоративных системах. Это нетехническое объяснение, предназначенное для широкой аудитории, но я подумал, что для технической аудитории может быть интересно прочитать то, что, по моему мнению, следует рассказать неспециалистам.
В 1970-х годах доктор Кодд и доктор Дейт из IBM предложили новый тип базы данных. Это называлось «реляционной» базой данных. Я никогда не видел никаких признаков того, что доктор Кодд или доктор Дэйт когда-либо создавали реальную корпоративную систему. Если бы они это сделали, я думаю, они бы поняли, что реляционное исчисление просто не подходит для корпоративных систем. Им не нужно было на самом деле заставлять систему работать, все, что им нужно было сделать, это привести сильно надуманные академические примеры. Любой, кто работал в окопах корпоративных систем, знал, что реальная жизнь намного сложнее. Просто сложно писать корпоративное программное обеспечение. Это пересечение компьютера и человеческого поведения, и действительно трудно получить вещи, которые удовлетворяют эти иногда противоречивые потребности.
В то время я работал над программными системами для большого союза, и я помню, что все говорили о реляционных базах данных. Дело было не в том, что кто-то из них действительно знал, что такое реляционная база данных, но они слышали этот термин, и это звучало хорошо. Это было в то время, когда компьютерные термины начали входить в обиход в бизнесе. В газетных киосках начали появляться такие журналы, как Byte и PC Mag, и некоторые из статей были опубликованы в газетах. Идея базы данных была привлекательной; идея чего-то, что хранит данные, например, картотеки. Это такая концепция физического мира, что она стала тем, о чем начали говорить люди, которые действительно мало о ней знали.
Затем было название «реляционный». Были истории о том, как это позволит вам «путешествовать» по вашим данным. Получите название отдела руководителя проекта проекта и тому подобное. Но на самом деле слово «отношение» в «реляционном» относится к математическому понятию отношения, которое представляет собой набор групп данных. Если две вещи находятся в группе, они считаются связанными. Фактически, математическая теория отношений избегает концепции связи между связанными объектами и определяет отношения как совокупность связанных вещей. Любой такой набор является соотношением в математической теории. Это полностью удалено из нашей бизнес-ориентированной концепции отношений, где должна быть какая-то связь. Если бы у вас была группа пар объектов и кто-то сказал вам, что они связаны, вы бы стали искать какую-то связь. Есть головоломки, которые решаются таким образом, и нам нужно искать скрытый фактор. Это очень человеческий инстинкт поиска шаблонов. Но теорию математических отношений это не волнует. Их можно считать отношениями, даже если они образовались случайно.
Когда я преподавал математическую логику в Йоркском университете, я читал курс математической теории отношений. Некоторые студенты просто не могли отказаться от отношений как от каких-то правил. Абстрактная концепция, на которой основывалась теория, была тем, чего они просто не могли понять. Когда я услышал, что IBM выступила с предложением о базе данных на основе реляционного исчисления, я был поражен. К тому времени я написал много корпоративного программного обеспечения, и я не мог понять, чем может быть полезна попытка навязать все в такой формальной и абстрактной структуре.
На мой взгляд, это был один из самых значительных факторов, способствовавших сложности и переполнению системы. Позвольте мне пройти через эту технологию и показать вам некоторые из ее проблем.
Вы когда-нибудь видели старый фильм, действие которого происходит, вероятно, в 1920-х или 1930-х годах, где кто-то читает телеграмму?
Всегда было что-то вроде:
УДАЛИЛИСЬ С ДЭННИ СТОПОМ, МЕДОВЫЙ МЕСЯЦ В МАДРИДЕ ОСТАНОВИТСЯ СЛАВНО СЧАСТЛИВЫЙ СТОП
Они всегда были такими, со всеми этими СТОПами. О чем все это было?
Чтобы понять это, мы должны вернуться к англо-бурской войне, которая была ужасной войной, которую британцы вели на рубеже 20-го века в Южной Африке. Помимо знакомства мира с концепцией концентрационных лагерей и позиционной войны, это была первая война, в которой использовался беспроводной телеграф, чтобы войска могли получать приказы по телеграфу прямо на фронте. Фронты войны - грязные места, особенно на рубеже двадцатого века, повсюду разбрызганы грязь и конский навоз. Обеспокоенный тем, что брызги грязи могут быть ошибочно приняты за запятую или точку, которые могут изменить цель приказа, британское военное министерство потребовало, чтобы все знаки препинания были записаны, например, ЗАПЯТАЯ. Для периода они выбрали короткое слово STOP, названное в честь «точки», что является более британским названием для «точки».
Стало практикой записывать телеграфный код на период как слово СТОП. И когда люди читают их вслух, они инстинктивно зачитывают слово СТОП, а не просто рассматривают его как точку в конце предложения.
При чем здесь реляционные базы данных? вы можете спросить. Команды для реляционной базы данных даются в виде реального читаемого текста. Этот текст написан на языке, который называется SQL (язык структурированных запросов). В SQL для разделения команд используются знаки препинания, так же как в телеграмме между предложениями используется слово STOP. По сути, база данных получает свои команды в виде потока текста, например телеграммы, с STOP между каждой командой [1].
Взгляните на этот пример:
ОБНОВЛЕНИЕ CUSTOMER_TABLE SET NAME = «John Smith» ГДЕ CUSTOM_NO = 2333 ОСТАНОВИТЬ ОБНОВЛЕНИЕ…
Это команда в SQL для обновления записи о клиенте 2333, присвоив имя Джону Смиту.
Теперь обратите внимание на текст между кавычками, то есть «Джон Смит». Откуда это пришло?
Ну, это было введено кем-то в браузере, заполнив форму. Человек, заполнивший форму, набрал «Джон Смит» и нажал кнопку «Отправить». Код веб-сайта помещает то, что было введено в кавычки, в оператор SQL и отправляет его в базу данных для выполнения.
Теперь предположим, что покупатель гнусный и вводит это вместо своего имени:
Джон »STOP УДАЛИТЬ CUSTOMER_TABLE STOP
Если веб-сайт просто поместит его в оператор SQL, он будет выглядеть так:
ОБНОВЛЕНИЕ CUSTOMER_TABLE SET NAME = «Джон» ОСТАНОВИТЬ УДАЛИТЬ CUSTOMER_TABLE STOP »ОСТАНОВИТЬ ОБНОВЛЕНИЕ…
И, возможно, вы увидите, на что это было изменено. Существует команда для установки имени в таблице клиентов для John, что будет выполнено, но затем она выполнит следующую команду, вставленную гнусным клиентом, которая является инструкцией по удалению всей таблицы данных. Помните, что эта запись в базу данных выполняется задачей, которая должна иметь достаточные права для обновления базы данных.
Это то, что называется «SQL-инъекцией».
SQL-инъекция была самым распространенным методом взлома веб-сайтов и вторжений компаний. Более 90% всех основных проникновений на веб-сайты происходило с помощью SQL-инъекций. Вам просто нужно погуглить и увидеть поток утечек данных, в результате которого взломаны сотни миллионов кредитных карт, опустошены банковские счета и раскрыта личная информация.
Обратите пристальное внимание на то, что здесь происходит. Команды базы данных представлены в текстовом виде, и данные, введенные пользователями Интернета из веб-форм, объединяются в этот текст, что позволяет людям, заполняющим форму, попытаться обманом заставить базу данных неправильно интерпретировать команду.
Если вам это кажется глупым, вы совершенно правы.
Это, вероятно, самое глупое технологическое решение, которое когда-либо широко использовалось таким количеством людей, и с такой высокой ценой.
Это программный эквивалент атомной электростанции, в которой диспетчерская сочетается с галереей для посетителей.
Нет смысла разделять две вещи: одну - команды, а другую - данные из форм, затем смешивать их, а затем вести техническую битву вперед и назад, пытаясь не обмануть себя, думая, что данные являются фактически часть команды.
Зачем вообще их смешивать?
Это просто ужасная архитектура, и она несет миллиардные убытки организациям по всему миру.
Но история с реляционными базами данных становится еще хуже.
Допустим, у вас есть расписание, которое вы внедрили в программное обеспечение. В расписании есть номер сотрудника. Теперь вы отображаете табель учета рабочего времени и хотите узнать имя сотрудника. Это находится в таблице Employee, поэтому вам нужно создать оператор SQL, например:
ВЫБЕРИТЕ СОТРУДНИКА, ГДЕ СОТРУДНИК.ЧИСЛО РАВНО TIMESHEET.EMPLOYEE_NUMBER
Это берет таблицу сотрудников и сопоставляет ее с таблицей расписания, а затем вы выбираете. На самом деле вы здесь определяете отношения между сотрудником и расписанием. Вы говорите, что они связаны по номеру сотрудника, который указан в табеле учета рабочего времени.
Помните, что форма расписания уже была описана программному обеспечению. Вы сказали, что поле в расписании - это номер сотрудника, так что, по сути, на этом этапе эта взаимосвязь уже была известна программному обеспечению. Но теперь вам нужно решить все проблемы, связанные с построением оператора SQL и его отправкой в базу данных для выполнения, а затем получить обратно набор строк таблицы, из которых вы выбираете нужную информацию. Это все совершенно не нужно! Информация о том, что расписание относится к сотруднику, уже была передана в программное обеспечение. Использование реляционной базы данных привело к необходимости игнорировать эту информацию и переопределить отношения на совершенно другом языке.
В информатике существует принцип DRY, что означает «не повторяйся». Его основная цель - не повторять код для одного и того же расчета. Вы должны написать код только один раз и вызывать его всякий раз, когда требуется расчет. Однако он также распространяется на все виды способов устранения избыточности. Это принцип уменьшения беспорядка / сложности. Программное обеспечение, использующее один и тот же код для одних и тех же вычислений, исключает возможность того, что эти две отдельные реализации выходят из строя.
Использование SQL для выражения «отношений» между данными, которые уже были выражены в другой форме, является полным нарушением принципа DRY. Информация ценится в программном обеспечении. Когда он будет захвачен, его следует сжать для всех возможных способов использования. Вам никогда не придется повторно вводить информацию. Вы никогда не должны вводить что-то, что могло быть получено из того, что вы ввели ранее. Для этого нужно создать возможность того, что две версии этой информации не совпадают.
С тех пор, как были предложены реляционные базы данных, я был озадачен, почему эта, казалось бы, странная архитектура сохранилась.
Это похоже на то, что ваш отдел документации говорит на иностранном языке, поэтому все инструкции должны быть написаны на этом языке.
Но это еще хуже. Когда вы сохраняете этот табель в реляционной базе данных, вы должны полностью разделить его, поместив информацию заголовка в одну таблицу и все подробные строки, которые назначают часы проектам в виде отдельных строк в другой таблице. Вам нужно разобрать форму и построить SQL, который берет эти биты и хранит их. О да, и убедитесь, что вы указали порядковые номера на всех строках с подробностями в расписании, если хотите, чтобы их можно было вернуть в том же порядке. Когда вы хотите вернуть форму, вам нужно написать инструкции SQL, чтобы объединить таблицы, а затем вы должны выбрать всю информацию о расписании из возвращенных результатов и собрать ее в виде формы.
Некоторые люди описывают это как то, что каждый вечер, когда вы приходите домой, приходится разбирать машину, вешать детали на стену гаража, а утром заново собирать машину, прежде чем ехать на работу.
Все это требует большого количества дополнительного кода для перевода между различными мирами реляционной базы данных и объектным миром программного обеспечения. Дополнительный код означает вероятность дополнительных ошибок.
Как будто этого было недостаточно, данные в реляционной базе данных хранятся способами, более соответствующими языку программирования 1980-х годов, чем современному объектно-ориентированному языку. Все данные в современных объектно-ориентированных языках программирования должны быть закодированы в эти примитивные типы данных.
Это иногда называют «объектно-реляционным несоответствием импеданса». Шутки в сторону? Несоответствие импеданса между усилителем и динамиком я могу понять, поскольку это относится к реальному физическому явлению. В этом контексте это просто технический треп, который следует заменить «последствиями действительно глупой архитектуры».
Если вы хотите знать, почему корпоративные системы так часто выходят из строя, это не вся причина, а одна из основных. Необходимость дублировать всю эту логику на разных языках и действительно разными способами представления данных добавляет огромное количество беспорядка / путаницы в ERP-систему.
Возьмите старую базу кода с множеством дополнений и изменений, внесенных разными людьми на протяжении многих лет, затем попробуйте адаптировать ее к новой ситуации и добавить всю эту дополнительную сложность реляционной базы данных, и вы подвергнете проект серьезному риску. .
Тем не менее, это правда, что реляционные базы данных распространены повсеместно. Настолько, что есть программисты, которые никогда не видели никаких других баз данных и верят, что все базы данных реляционные.
Реляционные базы данных были худшей технологией, которая когда-либо отравляла поле деятельности. Избыточный беспорядок в системах - основная причина того, что корпоративные системы так регулярно выходят из строя.
Эта статья была взята из моей книги Как избежать ИТ-катастроф:« Заблуждения относительно корпоративных систем и того, как вы можете подняться над ними (она раскрывает настоящие причины, по которым корпоративные системы терпят неудачу - те, о которых никто не хочет говорить).
✉️ Подпишитесь на рассылку еженедельно Email Blast 🐦 Подпишитесь на CodeBurst на Twitter , просмотрите 🗺️ Дорожная карта веб-разработчиков на 2018 год и 🕸️ Изучите веб-разработку с полным стеком .
