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

Если процесс становится безразличным, можно вызвать, уничтожают его от терминала с

pkill-9f имя процесса

, Например,

pkill-9f filezilla

83
задан cletus 3 September 2009 в 00:14
поделиться

23 ответа

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

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

1
ответ дан 24 November 2019 в 08:46
поделиться

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

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

ни то, ни другое, как мне кажется, не существует в MySQL.

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

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

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

55
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

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

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

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

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

3
ответ дан 24 November 2019 в 08:46
поделиться

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

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

2
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

3
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

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

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

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

Но даже тогда,

4
ответ дан 24 November 2019 в 08:46
поделиться

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

Другой способ сказать это "почему убежище?"

4
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

5
ответ дан 24 November 2019 в 08:46
поделиться

MySQL.

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

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

8
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

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

5
ответ дан 24 November 2019 в 08:46
поделиться

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

10
ответ дан 24 November 2019 в 08:46
поделиться

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

12
ответ дан 24 November 2019 в 08:46
поделиться

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

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

7
ответ дан 24 November 2019 в 08:46
поделиться

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

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

В одном проекте мне бы хотелось иметь материализованные представления ... но я использую Postgres. Я бы хотел использовать пространственные типы данных для другого проекта, но мне придется взломать или изменить базы данных, чтобы справиться с требованиями mySQL, чтобы они не были нулевыми. Я' Я знал некоторых администраторов баз данных Oracle, которые не могли запрограммировать выход из мокрого мешка; Я прошел все курсы за 8i дней, но отказался проходить тесты, так как не хотел, чтобы меня причисляли к этой группе)

6
ответ дан 24 November 2019 в 08:46
поделиться

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

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

17
ответ дан 24 November 2019 в 08:46
поделиться

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

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

36
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

21
ответ дан 24 November 2019 в 08:46
поделиться

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

5
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

7
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

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

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

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

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

4
ответ дан 24 November 2019 в 08:46
поделиться

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

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

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

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

0
ответ дан 24 November 2019 в 08:46
поделиться

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

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

0
ответ дан 24 November 2019 в 08:46
поделиться

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

0
ответ дан 24 November 2019 в 08:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: