Зачем использовать базу данных SQL? [закрыто]

Да, мне неприятно писать операторы SQL для хранения и извлечения объектов.

Вот почему Microsoft добавила такие вещи, как LINQ (интегрированный языковой запрос) в C # и VB.NET, чтобы сделать возможным запрашивать базы данных с использованием объектов и методов вместо строк.

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

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

SQL был создан для предоставления интерфейса для выполнения специальных запросов к реляционной базе данных.

Как правило, большинство реляционных баз данных понимают некоторые формы SQL.

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

Реляционные базы данных также позволяют работать в «отключенном» состоянии. Получив запрошенную информацию, вы можете закрыть соединение с базой данных. С помощью объектно-ориентированной базы данных вам нужно либо вернуть все объекты, связанные с текущим (и те, с которыми они связаны ... и ... и т. Д.), Либо повторно открыть соединение, чтобы получить новые объекты в том виде, в котором они есть. доступ.

В дополнение к SQL у вас также есть ORM (объектно-реляционные сопоставления), которые отображают объекты на SQL и обратно. Их довольно много, включая LINQ (.NET), MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class :: DBI (Perl) и т. Д. .

Потому что часто вы не можете быть уверены, что (цитируя вас) «никто никогда не видел после развертывания» . Знание того, что существует простой интерфейс для отчетов и запросов на уровне набора данных, - хороший путь для развития вашего приложения.
Вы правы, есть и другие решения, которые могут быть применимы в некоторых ситуациях: XML, текстовые файлы, OODB ...
Но наличие набора общих интерфейсов (например, ODBC) - огромный плюс для жизни данных.

Существует множество нереляционных систем баз данных. Здесь только несколько: Memcached Tokyo Cabinet

На самом деле появилось несколько продуктов, отличных от баз данных SQL (например, Objectivity, Oracle Berkeley DB и т. Д.), Но ни один из них не преуспел. В будущем, если кто-то найдет интуитивно понятную альтернативу SQL, это ответит на ваш вопрос.

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

Во второй части вы, кажется, жалуетесь на то, что SQL - это текст (он использует строки вместо идентификаторов и т. Д.) ... SQL - это язык запросов . Любой язык (компьютерный или другой), предназначенный для чтения или записи людьми, в этом отношении ориентирован на текст. Сборка, C, PHP, что угодно. Почему? Потому что, ну ... это имеет смысл, не так ли?

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

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

Во-вторых, SQL становится все более полезным по мере усложнения запросов. Попробуйте использовать LINQ для задания 12-стороннего объединения с тремя условиями, основанными на экзистенциальных предикатах, и условием, основанным на агрегате, вычисленном в подзапросе. Подобные вещи достаточно понятны в SQL, но вряд ли возможны в ORM.

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

Однако ORM - это не все и вся в интерфейсе баз данных. В книге Фаулера "Patterns of Enterprise Application Architecture" есть неплохой раздел о других типах стратегии доступа к базе данных с некоторым обсуждением достоинств каждого из них.

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

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

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

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

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

1. Существует около 3-4 десятилетий использования серьезные исследования в этой области начиная с 1970 г., когда Кодд начал статья по реляционной алгебре.Реляционная алгебра образует математическая основа для SQL (и других QL), хотя SQL не полностью следовать реляционным модель.

2. "Текстовая" форма языка (помимо того, что легко понятны людям) также легко обрабатывается машинами (скажем, используя синтаксический анализатор грамматики, например lex) и легко конвертируется в любой «байт-код» с использованием любого количества оптимизаций.

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

Возникает интересный вопрос: «Каковы реальные преимущества выполнения SQL любым другим« нетекстовым »способом?» Будет гуглить это сейчас :)

Самая большая причина использования SQL - это специальные отчеты. Этот отчет хотят ваши бизнес-пользователи, но еще не знают, что он им нужен.

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

Все, кого я знаю, включая меня, используют ORM

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

Здесь есть несколько хороших ответов. Я попытаюсь добавить свои два цента.

Мне нравится SQL, я могу довольно легко в нем думать. Запросы, создаваемые слоями поверх БД (например, фреймворками ORM), обычно ужасны. Они выберут тонны лишнего, присоединятся к тому, что вам не нужно, и т. Д .; все потому, что они не знают, что вам нужна только небольшая часть объекта в этом коде. Когда вам нужна высокая производительность, вы часто будете заходить и использовать по крайней мере несколько пользовательских SQL-запросов в системе ORM, чтобы ускорить несколько узких мест.

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

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

Допустим, вы выполняете запрос типа «ВЫБЕРИТЕ x ИЗ таблицы WHERE id = 3», а затем делаете это снова с 4, затем с 5, снова и снова. В этом случае могут существовать накладные расходы на синтаксический анализ. Вот почему вы подготовили заявления (как уже упоминали другие). Сервер анализирует запрос один раз и может поменять местами 3, 4 и 5 без необходимости повторного анализа всего.

Но это тривиальный случай.В реальной жизни ваша система может объединить 6 таблиц и получить сотни тысяч записей (если не больше). Это может быть запрос, который вы позволяете запускать в кластере базы данных в течение нескольких часов, потому что это лучший способ сделать что-то в вашем случае. Даже с запросом, выполнение которого занимает всего одну или две минуты, время на анализ запроса практически бесплатное по сравнению с извлечением записей с диска и выполнением сортировки / агрегации и т. Д. Накладные расходы на отправку ext «LEFT OUTER JOIN ON» составляют всего несколько байтов по сравнению с отправкой специального закодированного байта 0x3F. Но когда ваш результирующий набор составляет 30 МБ (не говоря уже о гигабайтах +), эти несколько дополнительных байтов бесполезны по сравнению с отсутствием необходимости возиться с каким-то специальным объектом компилятора запросов.

Многие люди используют SQL в небольших базах данных. Самый большой, с которым я общаюсь, - это всего несколько десятков концертов. SQL используется во всем: от крошечных файлов (например, небольшие базы данных SQLite) до кластеров Oracle терабайтного размера. Учитывая его мощность, на самом деле это удивительно простой и небольшой набор команд.

После всех правок и комментариев основной смысл вашего вопроса, похоже, таков: почему природа SQL ближе к интерфейсу человека / базы данных, чем к интерфейсу приложения / базы данных?

И очень простой ответ на этот вопрос: потому что это именно то, чем он был изначально задуман.

Предшественники SQL (предположительно, наиболее важный из них - QUEL) должны были быть именно таким: языком QUERY, то есть таким, в котором не было ни INSERT, UPDATE, ни DELETE.

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

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

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

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

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

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

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

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

1. Полу-арбитражные решения при разработке, такие как простота использования, отсутствие необходимости в компиляторе SQL (или IDE), переносимость, и т.д.
2. Он хорошо прижился (возможно, по тем же причинам)
3. И сейчас в силу исторических причин (совместимость, известность, проверенность и т.д.) продолжает использоваться.
4. Я не думаю, что большинство компаний пытались найти другое решение, потому что оно хорошо работает, не является узким местом, это стандарт, бла-бла-бла...

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

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

Да, текст немного неэффективен. Но на самом деле получение данных намного дороже, поэтому текстовый sql достаточно незначителен.

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

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

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

Но зачем использовать язык SQL для взаимодействия с такой базой данных?

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

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

Это существующая (необязательная) функция баз данных, называемая «хранимыми процедурами».

Изменить:

Я был бы очень признателен, если бы вы могли привести несколько примеров, в которых SQL преднамеренно используется без ORM, и почему

Когда я реализовал свою собственную ORM, я реализовал структуру ORM с использованием ADO.NET: а использование ADO.NET включает в себя использование операторов SQL в своей реализации.

Учитывая тот факт, что вы использовали MySQL и SQLite, я полностью понимаю вашу точку зрения. Большинство СУБД имеют функции, которые потребуют некоторого программирования с вашей стороны, в то время как вы получаете их из базы данных бесплатно:

• Индексы - вы можете хранить большие объемы данных и при этом иметь возможность очень быстро фильтровать и искать, потому что индексов. Конечно, вы можете реализовать собственное индексирование, но зачем изобретать колесо

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

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

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

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

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

Кроме того, MySQL и SQLite менее полнофункциональны, чем, скажем, MSSQL и Oracle SQL. Так что вы все еще находитесь в нижней части пула SQL.