Почему функции базы данных игнорируются, а вместо этого изобретаются заново на среднем уровне?

Каковы основные причины ( помимо «независимости базы данных» ) того, что большинство ИТ-проектов сегодня, похоже, игнорируют множество функций, существующих в современных механизмах баз данных, таких как Oracle 11g и SQL Server 2008?

Или, позаимствовав из блога Хельсинкской декларации, об этом говорится так:

За последние двадцать лет мы наблюдаем, что функциональные возможности (возможности), доступные нам внутри СУБД, экспоненциально выросли. Эти функции позволили нам создавать приложения для баз данных. Это то, чем мы все начали заниматься в бурные девяностые.

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

Мы говорим о таких вещах, как

• Хранимые процедуры, используемые в качестве API данных (для безопасности и во избежание чрезмерного сетевого трафика)
• Материализованные представления
• Вместо триггеров
• Иерархические запросы (подключение по)
• География (типы пространственных данных)
• Аналитика (опережение, отставание, сведение, куб и т. Д.)
• Виртуальная частная база данных (VPD)
• Аудит на уровне базы данных
• Flashback-запросы
• Генерация XML и преобразование XSL в базе данных
• HTTP-вызовы из базы данных
• Планировщик фоновых заданий

Почему эти функции не используются? Почему большинство разработчиков Java, .NET и PHP придерживаются подхода «SELECT * FROM mytable»?

Потому что хранимые процедуры:

• добавить еще один язык разработки, увеличивая сложность и потенциально избыточный код (логика написана на обоих языках);
• обычно имеют худшие инструменты, возможности мониторинга и отладки, чем PHP, C #, Java, Python и т. д .;
• обычно менее развиты, чем большинство языков среднего уровня;
• имеют преимущество только при преобразовании больших объемов данных (где вы избегаете обратного обращения к серверу), которое обычно сводится к минимуму фактического использования.

При этом это распространенная методология для приложений C # ASP.NET.

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

Я часто использовал материализованные представления и иногда использовал CONNECT BY в Oracle, ни один из которых, как мне кажется, не существует в MySQL.

Я не склонен использовать XML / XSLT в базе данных, потому что это означает, что я использую XML и XSLT.

Что касается географических или пространственных структур данных, причина, вероятно, в том, что их трудно просто «уловить». Это довольно специализированная область. Я прочитал руководство MySQL по пространственным структурам данных, и я уверен, что это имеет смысл для кого-то с обширным опытом работы с ГИС, но для меня и моих ограниченных потребностей (которые, как правило, связаны с отметкой широты / долготы точки) это просто не так. Кажется, не стоит тратить время на то, чтобы понять это.

Другая проблема заключается в том, что если вы выйдете за рамки ANSI SQL (много), то вы просто несколько привязаны к конкретному поставщику базы данных и, возможно, к конкретной версии. По этой причине вы часто обнаружите, что разработчики приложений склонны рассматривать свои базы данных с наименьшим общим знаменателем, что означает обращение с ними как с свалкой для реляционных данных.

Потому что разработчики ничего не знают о SQL. Они полагаются на DDL и DML, созданные такими инструментами, как Hibernate, и конструкциями языкового уровня, такими как аннотации JPA. Разработчиков не волнует, являются ли они ужасно неэффективными, потому что они милостиво скрыты обычными уровнями журналов и потому, что администраторы баз данных не являются частью групп разработчиков.

Вот почему мне нравятся инструменты iBATIS . Они заставляют вас писать и понимать SQL, включая особенности СУБД.

Я предполагаю, что одна из причин - это боязнь привязки к продавцу.

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

Я приведу этот пример: можно найти «блокировку» SQL Server более приемлемой, если вы поймете все, что службы Analysis Services, Reporting Services и т. Д. Могут сделать для вашего приложения. Для основных коммерческих систем баз данных необходимо учитывать не «просто» механизм базы данных SQL.

«Почему игнорируются возможности базы данных».

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

Если ваше программное обеспечение работает на оборудовании вашего клиента, любое изменение в базе данных (новые хранимые процедуры, обновленные представления и т. Д.) Потребуют прав администратора БД. Это почти всегда проблема для клиентов. Вовлечение группы БД усложняет любые обновления, которые вам нужно сделать. Здесь представлено множество веских причин, но это единственная, которая мне нужна, чтобы не помещать код в базу данных, как чуму.

Я предполагаю, что одна из причин - это боязнь привязки к продавцу. Эти функции СУБД не стандартизированы - например, хранимые процедуры очень специфичны для БД, и если вы реализовали что-то с использованием хранимых процедур (вместо, скажем, веб-служб, предоставляемых через средний уровень), то вы навсегда застряли в первой выбранной СУБД. , (то есть, если вы не готовы потратить время / деньги на повторную реализацию его в другой СУБД, если вы хотите изменить СУБД).

MySQL.

Когда в конце 1990-х - начале 2000-х годов произошел взрыв веб-приложений, MySQL была версии 3.3 или 4.0 и не поддерживала ничего, кроме простых SELECTs. Однако он был бесплатным и устанавливался в большинстве дистрибутивов Linux. В результате поколение программистов не узнало о базах данных и не знало, как их использовать.

Даже сейчас, когда MySQL находится на уровне 5.1 и поддерживает большинство функций коммерческой системы, те же самые грубые старые блоги и статьи используются в качестве шаблонов при запуске нового проекта LAMP, а MySQL развертывается с таблицами MyISAM и функциональностью эпохи 3.3. .

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

Простые смертные терпят поражение даже в самом простом языке. Возможно, 1 из 10 человек действительно умеет использовать простой язык, такой как C #. Но из этих 10% только 1 из 10 или 1% всех людей могут эффективно использовать такие языки, как SQL или Haskell.

Итак, SQL как язык неполный в том смысле, что очень мало вещей, которые можно сделать с помощью только SQL. Вам всегда понадобится другой язык. Какую роль это оставляет SQL? Разработчики поймут преимущества ACID перед хранилищем плоских файлов, но, кроме того, базам данных действительно нечего им предложить.

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

Средний уровень проще исправить / развернуть, чем СУБД.

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

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

Они изучают самый минимум SQL и не осознают всех различных расширений, которые предлагают разные СУБД.

В одном проекте мне бы хотелось иметь материализованные представления ... но я использую Postgres. Я бы хотел использовать пространственные типы данных для другого проекта, но мне придется взломать или изменить базы данных, чтобы справиться с настойчивыми требованиями mySQL, чтобы они не были нулевыми. Мне даже пришлось выяснить, как отключить согласованность транзакций Oracle, чтобы обрабатывать долго выполняющиеся запросы в OLTP, что не было бы проблемой в mySQL.

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

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

(и не воспринимайте это как поддержку для получения сертификата DBA ... Я знал некоторых администраторов баз данных Oracle, которые не могли запрограммировать свой выход из мокрого мешка; я прошел все курсы за 8i дней, но отказался проходить тесты, потому что не хотел, чтобы меня причисляли к этой группе)

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

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

Но во многих случаях (не во всех, конечно; все ситуации индивидуальны) эта модель развития не очень хорошо работает в долгосрочной перспективе. По мере того, как данные, генерируемые приложением, накапливаются и становятся все более важными для бизнеса, у разных людей появляются интересные идеи о том, как их использовать. Когда это произойдет, если у вас нет системы управления реляционной базой данных, вы столкнетесь с большой проблемой.

Масштабируемость. Чем больше работы вы отдаете серверу базы данных, тем более узким местом он становится. Более масштабируемо иметь целую ферму серверов приложений с балансировкой нагрузки, обрабатывающих данные, и просто использовать базу данных как постоянное хранилище.

Я был в слишком большом количестве ситуаций, когда корпоративная политика («нам не разрешен доступ к SQL Server, поэтому давайте установим менее мощную СУБД, такую ​​как Access, чтобы обрабатывать миллионы строк и объединить их с миллионами строк в другой таблице, а также автоматизировать этот импорт. .. ") или даже техническая политика, которая может произойти (" Я знаю, что Access может обрабатывать такой объем данных, и даже если это не так, мы можем разделить MDB на несколько MDB и ссылаться на них ... ")

УГХ. Корпоративная политика и техническая политика или даже незнание не позволяют мне использовать многие функции.

Другой пример - я не вижу причин , чтобы не использовать хранимые процедуры в 100% Microsoft магазин , где SQL Server является то СУБД выбора. Но поскольку ИТ-специалист, который в конечном итоге собирался владеть решением, был «легок» в отношении поставщиков услуг, мне пришлось прибегнуть к другим мерам. Я имею в виду, что есть прекрасный пример того, почему некоторые из этих «функций» игнорировались ими в их магазине.

Я знаю другой магазин, который все еще использует DOS Foxpro 2, потому что их единственный ИТ-специалист написал существующую систему таким образом, и именно так будут разрабатываться все новые вещи. Почему? Не можем ли мы идти в ногу со временем? Многие маркетологи открывают сразу несколько приглашений DOS, в которых выполняются «задания» Foxpro для создания самых ужасных отчетов, которые я когда-либо видел. Но это работает - я им это дам. Это работает - у них есть 12 миллионов строк в их основной таблице и более 50 других таблиц, которые они «присоединяют» к этой основной таблице (очевидно, не ко всем 50 сразу), но, черт возьми, 1991 год уже прошел! Они даже не хотят обсуждать ни один пункт из того маркированного списка, который вы указали в своем вопросе.

Думаю, именно поэтому такие вещи.

Я бы сказал, что главная причина в том, что большинство людей о них не знают. Когда кто-то нашел решение проблемы, оно становится решением по умолчанию для аналогичных. Таблица SELECT * FROM уже давно работает для многих людей, поэтому они не утруждают себя поиском новых подходов к старым проблемам.

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

Хороший вопрос и хорошее обсуждение.

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

Действительно странно, что мы скрываем и дублируем функциональность БД в ActiveRecord, Hibernate и других промежуточных программах. Но вот что происходит с парадигмами в момент разрушения («объектно-реляционное несоответствие импеданса»). Перейдем ли мы когда-нибудь на технологии баз данных, аналогичные нашим объектно-ориентированным приложениям (например, объектные БД)?

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

Другой вопрос: «Зачем мне делать это в БД, если это может делать средний уровень?» Средний уровень знаком и постоянно набирает обороты по скорости и функциональности. Опять же, мы используем средний уровень, чтобы избежать несоответствия OO-RDMS.

Чтобы продолжить то, что сказал Кристиан о масштабируемости.

Просто RDBM используются больше как чистые хранилища данных, в то время как логика переносится на серверы приложений. Дополнительный уровень AS дает разработчикам больше гибкости, чем использование RDBMS в качестве сервера приложений.

Раньше, в классические времена Fat Apps и Client Server, DB и Application Server были в основном одним и тем же. У вас была логика приложения, встроенная в ваш толстый клиентский код, или вы вернули ее обратно в СУБД. Но тогда основной формой связи был SQL напрямую с базой данных.

В настоящее время более распространены другие протоколы приложений (CORBA, DCOM, Remote EJB и все более распространенные сегодня протоколы в стиле XML / JSON / HTTP-RPC поверх HTTP). Большинство баз данных не отвечает на эти протоколы напрямую, поэтому уровень приложения прерывается для перехвата этих вызовов, и этот уровень вызывает базу данных.

Но, как мы узнали, теперь мы получаем гораздо больше гибкости, добавляя логику на этот уровень. Более широкий выбор инструментов, большая гибкость в отношении кэширования, аварийного переключения или даже технологии баз данных (RDMBS, OODBMS, хранилища документов, такие как CouchDB). Этот «новый», 3-й уровень, несмотря на дополнительную сложность, добавляет больше гибкости и мощности, чем вводимая им сложность.

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

Даже сегодня использование базы данных и всех ее функций является действенной стратегией приложения. SQL Server, Oracle и т. Д. - очень мощные программы.

Однако даже в этом случае третий уровень чрезвычайно помогает в добавлении гибкости современной системе.

Для меня причина не только в том, что мои приложения не зависят от базы данных, но и в том, что база данных лучше всего выполняет основные функции CRUD. Да, базы данных сильно оптимизированы и могут выполнять HTTP-вызовы, но зачем вам это делать? Веб-сервис / веб-приложение оптимизировано для HTTP-вызовов, а не для базы данных. Точно так же, как приложение не предназначено для прямого подключения к файлу данных и получения данных. Это можно сделать? Да, но почему? Это не то, в чем ваше приложение ОТЛИЧНО.

Я лично считаю, что все, что вы упомянули, помимо хранимых процедур, принадлежит приложению. Если вы знаете, что ваша архитектура - X, тогда воспользуйтесь преимуществами функций X, при необходимости переместите загрузку на сервер БД и т. Д. Если это может быть X или Y (или Z), то ваше приложение должно быть агностическим, если только вы не пытаясь обеспечить безопасность рабочих мест, гарантируя, что вам, возможно, придется реорганизовать приложение :). Я думаю, что немного лени в сочетании с комфортом может иметь какое-то отношение к этому. Я знаю, что лучше буду делать это на C #, чем на SQL, если смогу. . . мои навыки C # просто лучше.

Во-первых: любой разработчик, использующий ORM, наивен, если считает, что использование ORM отрицает необходимость владения SQL. Большинство ORM, генерирующих SQL, изменяют генерируемый SQL в зависимости от того, как построены объектные запросы. Разработчику необходимо будет проанализировать SQL, чтобы увидеть, следует ли изменить какие-либо объектные запросы.

Краткий ответ: многие из этих функций не подходят для объектно-ориентированной разработки. Я знаю, что администраторы баз данных не любят это слышать, но это правда. Эти функции хороши для крайних случаев, и большинство хороших ORM, таких как N / Hibernate, позволяют вам предоставлять SQL для этих крайних случаев.

Когда дело доходит до делегирования CRUD в основном:

Длинный ответ: я думаю, что мир РСУБД переживает болезни роста зрелости и находит свое место в мире. Правда: ООП старше СУБД. ООП только-только выходит из своих болезней роста и взросления. Я считаю, что SQL как язык очень зрелый, но идея того, что должна обрабатывать СУБД, только уходит. РСУБД была держателем бизнес-логики для большинства веб-приложений, пока не появились Java и C #. Думаю, сейчас мы только начинаем ощущать эту коррекцию.

При этом я не думаю, что какой-либо разработчик ORM скажет вам, что качество SQL-операторов, передаваемых в СУБД, не имеет значения.

Что касается не-CRUD, у меня здесь нет ответа. Большинство известных мне магазинов все еще используют БД для ETL и т. Д.

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

Еще один момент заключается в том, что вы обычно собираете глубокие знания только об одной системе баз данных, а не обо всех. Таким образом, у вас могут быть эксперты по SQL Server или Oracle, но не оба вместе. Это приводит (в некоторой степени) к узким областям применения, где важна высокая специализация. Тогда рынок таких приложений невелик, даже если он есть.

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

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

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

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

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

Я не возражаю против кода уровня базы данных, чтобы минимизировать объем сетевого трафика (записей), передаваемого между веб-сервером и сервером базы данных. Я выступаю против других функций, например. обширная обработка бизнес-логики на уровне базы данных.

В нескольких сообщениях отмечается, что на уровне приложения дешевле масштабировать, чем на уровне db.

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

Потому что написание объектно-ориентированного программного обеспечения на главном языке с собственными объектами основного языка лучше, чем написание процедурного программного обеспечения.

Я всегда работал над системами, которые продаются многим клиентам и работают на клиентском оборудовании. Это ведет к:

• Вы не знаете, какую версию программного обеспечения базы данных будет использовать клиент.
• Клиенты могут не захотеть обновлять программное обеспечение базы данных, когда вы захотите, из-за стоимости лицензии или ИТ-политики.
• Даже базовые функции, такие как материализованные представления, есть только в некоторых «редакциях» программного обеспечения базы данных, более мелкие клиенты часто не хотят платить за высокопроизводительную версию базы данных.
• Рано или поздно один из ваших продавцов согласится на использование вашего программного обеспечения с РСУБД другого поставщика.
• Выбор между написанием логики один раз на среднем уровне или, по крайней мере, PL-SQL и TSQL в базе данных - простой выбор!
• Любые изменения в базе данных (новые хранимые процедуры, обновленные представления и т. Д.) Потребуют прав администратора БД; На сайтах некоторых клиентов это может быть намного сложнее, чем просто обновить программное обеспечение.
• Написать скрипт для обновления базы данных всегда сложнее, чем установить новую версию dll приложения. (Большинство систем сборки в наши дни выводят файлы MSI как часть каждой сборки)
• Код для модульного тестирования в базе данных сложнее, чем на среднем уровне.
• Отладить хранимые процессы сложнее, чем C #.
• Тот факт, что он работает с вашей базой данных, не означает, что он будет работать с базой данных клиента. У РСУБД слишком много переключателей, которые меняют способ их работы - клиенты всегда склонны устанавливать их по-разному.

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