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

Question

Я не совсем уверен, что stackoverflow - это место для такого общего вопроса, но давайте попробуем.

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

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

SQL-запрос - это текстовое сообщение. Я могу понять, что это здорово для понимания того, что он делает, но не глупо использовать текстовую таблицу и имена столбцов для части приложения, которую никто не видел после развертывания? Если вам пришлось писать хранилище данных с нуля, вы бы никогда не использовали этот вид решения. Лично я бы использовал некоторый байт-код «скомпилированного db-запроса», который будет собран один раз внутри клиентского приложения и передан в базу данных. И он наверняка назвал бы таблицы и двоеточия номерами id, а не ascii-строками. В случае изменений в структуре таблицы эти байтовые запросы могут быть перекомпилированы в соответствии с новой схемой db, хранящейся в XML или что-то в этом роде.

В чем проблема моей идеи? Есть ли какая-то причина для того, чтобы я сам не писал и не использовал SQL-базу данных?

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

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

Answer 1

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

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

Вот как работают некоторые API баз данных. Проверьте статические SQL и подготовленные операторы.

Есть ли причина для меня не написать его самостоятельно и использовать SQL базы данных вместо этого?

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

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

UPDATE:

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

Хороший вопрос.

Ответ на это можно найти в оригинальной статье, описывающей реляционную модель A Relational Model of Data for Large Shared Data Banks, EF Codd, опубликованную IBM в 1970 году. В настоящем документе описываются проблемы с существующими технологиями баз данных того времени и объясняется, почему реляционная модель превосходит.

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

независимость данных определяется в работе как:

«... независимость прикладных программ и терминальные деятельности с ростом типов данных и изменения в представлениях данных.»

Перед реляционной моделью доминирующая технология для баз данных была названа сетевой моделью. В этой модели программист должен был знать структуру данных на диске и вручную перемещаться по дереву или графику. Реляционная модель позволяет написать запрос к концептуальной или логической схеме, которая не зависит от физического представления данных на диске. Это разделение логической схемы от физической схемы - вот почему мы используем реляционную модель. Для получения дополнительной информации по этой проблеме here - некоторые слайды из класса базы данных. В реляционной модели мы используем логические логические языки запросов, такие как SQL, для извлечения данных. Codd's paper более подробно описывает преимущества реляционной модели. Дайте ему прочитать.

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

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

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

UPDATE 2:

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

Поскольку база данных является реляционной базой данных, она понимает только языки реляционных запросов. Внутри он использует реляционную алгебру, такую ​​как язык, для указания запросов, которые затем превращаются в план запросов. Таким образом, мы пишем наш запрос в форме, которую мы можем понять (SQL), DB берет наш SQL-запрос и превращает его в свой внутренний язык запросов. Затем он берет запрос и пытается найти «план запроса» для выполнения запроса. Затем он выполняет план запроса и возвращает результат.

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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

Answer 11

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

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

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

Answer 12

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

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

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

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

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

Answer 13

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

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

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

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

---

Edit:

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

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

Answer 14

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

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

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

Answer 15

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

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

Answer 16

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

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

Answer 17

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

Answer 18

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

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

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

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

Предположим, вы запустили запрос типа «SELECT x FROM table WHERE id = 3», а затем выполните его снова с 4, затем 5, снова и снова. В этом случае могут существовать служебные данные синтаксического анализа. Вот почему вы подготовили заявления (как указывали другие). Сервер анализирует запрос один раз и может поменять местами 3 и 4 и 5, не переписывая все.

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

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

Answer 19

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

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

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

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

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

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

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

Answer 20

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

Answer 21

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

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

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

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

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

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

Answer 22

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

Answer 23

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

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

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

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

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

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

Answer 24

я думаю, что вы можете использовать ORM

тогда и только тогда, когда вы знаете основные из SQL.

еще результат есть не лучший

Answer 25

Я думаю, что причина может быть поиск/найти/грейфер алгоритмы SQL-laungage связано сделать. Помните, что sql был разработан в течение 40 лет - и цель была и предварительной, и мудрой, и пользовательской.

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

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

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

Тогда, когда дело доходит до laungage, я не думаю, что вы можете сделать гораздо более принципиально легкий текст, чем sql. И помните, что каждое слово чего-либо неразрывно связано с его значением - если вы удалите значение, слово не может быть использовано, - если вы удалите слово, вы не сможете передать значение. Тебе нечего описать (И, может быть, ты даже не можешь думать, что это просто не связано с чем-либо еще, о чем ты думал раньше ...).

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