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

Ответ 1

Поскольку хранимые процедуры:

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

Таким образом, это обычная методология для приложений ASP.NET ASP.NET.

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

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

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

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

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

Ответ 2

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

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

Ответ 3

Я думаю, одна из причин - страх перед продавцом.

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

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

Ответ 4

"Почему функции базы данных игнорируются".

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

Ответ 5

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

Ответ 6

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

Ответ 7

MySQL.

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

Ответ 10

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

Они изучают минимальный SQL-запрос и не понимают все разные расширения, предлагаемые различными RDBMS.

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

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

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

Так вот почему я думаю.

Ответ 14

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

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

Ответ 15

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

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

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

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

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

Ответ 16

Чтобы перейти к Christian, о масштабируемости.

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

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

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

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

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

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

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

Ответ 17

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

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

Ответ 18

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

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

Когда дело доходит до большей части делегирования CRUD:

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

Если говорить, я не думаю, что любой дизайнер ORM расскажет вам, что качество операторов sql, передаваемых в СУБД, не имеет значения.

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

Ответ 19

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

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

Ответ 20

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

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

Ответ 21

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

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

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

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

Ответ 22

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

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

Ответ 23

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

Ответ 24

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

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

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