Зачем использовать базу данных SQL?
Я не совсем уверен, что stackru - это место для такого общего вопроса, но давайте попробуем.
Будучи подверженным необходимости где-то хранить данные приложения, я всегда использовал MySQL или sqlite, просто потому, что это всегда делается так. Поскольку кажется, что весь мир использует эти базы данных (в основном программные продукты, фреймворки и т. Д.), Начинающему разработчику, вроде меня, довольно сложно задуматься о том, является ли это хорошим решением или нет.
Хорошо, скажем, у нас есть некоторая объектно-ориентированная логика в нашем приложении, и объекты как-то связаны друг с другом. Нам необходимо сопоставить эту логику с логикой хранения, поэтому также требуются отношения между объектами базы данных. Это приводит нас к использованию реляционной базы данных, и я согласен с этим - проще говоря, строки таблицы нашей базы данных иногда должны иметь ссылки на строки других таблиц. Но зачем использовать язык SQL для взаимодействия с такой базой данных?
SQL-запрос - это текстовое сообщение. Я понимаю, что это здорово для понимания того, что он делает, но не глупо ли использовать текстовые имена таблиц и столбцов для части приложения, которую никто не видел после развертывания? Если бы вам пришлось писать хранилище данных с нуля, вы бы никогда не использовали такого рода решение. Лично я бы использовал некоторый байт-код "скомпилированный запрос базы данных", который будет один раз собран внутри клиентского приложения и передан в базу данных. И он наверняка назвал бы таблицы и двоеточия по номерам id, а не по ascii-строкам. В случае изменений в структуре таблицы эти байтовые запросы могут быть перекомпилированы в соответствии с новой схемой БД, сохраненной в XML или чем-то в этом роде.
Каковы проблемы моей идеи? Есть ли причина для меня, чтобы не писать это сам и вместо этого использовать базу данных SQL?
РЕДАКТИРОВАТЬ Чтобы сделать мой вопрос более ясным. В большинстве ответов утверждается, что SQL, являясь текстовым запросом, помогает разработчикам лучше понять сам запрос и легче его отладить. Лично я некоторое время не видел людей, пишущих запросы SQL вручную. Все, кого я знаю, включая меня, используют ORM. Эта ситуация, в которой мы создаем новый уровень абстракции для сокрытия SQL, заставляет задуматься, нужен нам SQL или нет. Я был бы очень признателен, если бы вы могли привести несколько примеров, в которых SQL используется без ORM, и почему.
EDIT2 SQL - это интерфейс между человеком и базой данных. Вопрос в том, почему мы должны использовать его для взаимодействия приложений и баз данных? Я до сих пор прошу примеры написания / отладки SQL людьми.
25 ответов
Если все, что вам нужно сделать, это где-то хранить данные приложения, то СУБД общего назначения или даже SQLite могут быть излишними. Сериализация ваших объектов и запись их в файл может быть проще в некоторых случаях. Преимущество SQLite состоит в том, что если у вас много такого рода информации, все это содержится в одном файле. Недостатком является то, что его сложнее читать. Например, если вы сериализовали ваши данные в YAML, вы можете прочитать файл с помощью любого текстового редактора или оболочки.
Лично я бы использовал некоторый байт-код "скомпилированный запрос базы данных", который будет один раз собран внутри клиентского приложения и передан в базу данных.
Вот как работают некоторые API баз данных. Проверьте статический SQL и подготовленные операторы.
Есть ли причина для меня, чтобы не писать это сам и вместо этого использовать базу данных SQL?
Если вам нужно много функций, в какой-то момент будет проще использовать существующую RDMBS, чем писать собственную базу данных с нуля. Если вам не нужно много функций, более простое решение может быть разумнее.
Весь смысл продуктов баз данных состоит в том, чтобы избежать написания слоя базы данных для каждой новой программы. Да, современная RDMBS не всегда идеально подходит для каждого проекта. Это потому, что они были разработаны, чтобы быть очень общими, поэтому на практике вы всегда будете получать дополнительные функции, которые вам не нужны. Это не значит, что лучше иметь индивидуальное решение. Перчатка не всегда должна идеально подходить.
ОБНОВИТЬ:
Но зачем использовать язык SQL для взаимодействия с такой базой данных?
Хороший вопрос.
Ответ на этот вопрос может быть найден в оригинальной статье, описывающей реляционную модель Реляционная модель данных для больших общих банков данных, Э. Ф. Кодда, опубликованную IBM в 1970 году. В этом документе описываются проблемы с существующими технологиями баз данных того времени, и объясняет, почему реляционная модель лучше.
Причиной использования реляционной модели и, следовательно, логического языка запросов, такого как SQL, является независимость данных.
Независимость данных определяется в документе как:
"... независимость прикладных программ и операций терминала от роста типов данных и изменений в представлениях данных".
До реляционной модели доминирующая технология для баз данных называлась сетевой моделью. В этой модели программист должен был знать структуру данных на диске и вручную просматривать дерево или график. Реляционная модель позволяет написать запрос по концептуальной или логической схеме, которая не зависит от физического представления данных на диске. Это отделение логической схемы от физической схемы, поэтому мы используем реляционную модель. Для более подробной информации по этой проблеме, вот несколько слайдов из класса базы данных. В реляционной модели мы используем языки запросов на основе логики, такие как SQL, для извлечения данных. В статье Кодда более подробно рассказывается о преимуществах реляционной модели. Дайте ему прочитать.
SQL - это язык запросов, который легко вводить в компьютер, в отличие от языков запросов, обычно используемых в исследовательских работах. Исследовательские работы обычно используют алгебру отношений или реляционное исчисление для написания запросов.
Таким образом, мы используем SQL, потому что мы используем реляционную модель для наших баз данных.
Если вы понимаете реляционную модель, нетрудно понять, почему SQL такой, какой он есть. В общем, вам нужно более глубоко изучить модель отношений и внутреннюю базу данных, чтобы понять, почему мы используем SQL. В противном случае это может быть немного загадкой.
ОБНОВЛЕНИЕ 2:
SQL - это интерфейс между человеком и базой данных. Вопрос в том, почему мы должны использовать его для взаимодействия приложений и баз данных? Я до сих пор прошу примеры написания / отладки SQL людьми.
Поскольку база данных является реляционной базой данных, она понимает только языки реляционных запросов. Внутренне он использует реляционную алгебру, подобную языку, для определения запросов, которые он затем превращает в план запросов. Итак, мы пишем наш запрос в форме, которую мы можем понять (SQL), БД берет наш запрос SQL и превращает его в свой внутренний язык запросов. Затем он принимает запрос и пытается найти "план запроса" для выполнения запроса. Затем он выполняет план запроса и возвращает результат.
В какой-то момент мы должны закодировать наш запрос в формате, который понимает база данных. База данных знает только, как преобразовать SQL во внутреннее представление, поэтому в какой-то момент в цепочке всегда есть SQL. Этого нельзя избежать.
Когда вы используете ORM, вы просто добавляете слой поверх SQL. SQL все еще там, он просто скрыт. Если у вас есть высокоуровневый уровень для перевода вашего запроса в SQL, вам не нужно писать SQL напрямую, что полезно в некоторых случаях. Иногда у нас нет такого уровня, который мог бы выполнять те запросы, которые нам нужны, поэтому мы должны использовать SQL.
Все, кого я знаю, включая меня, используют ORM
Странный. Все, кого я знаю, включая меня, до сих пор пишут большую часть SQL вручную. Обычно вы получаете более жесткие и высокопроизводительные запросы, чем сгенерированное решение. И, в зависимости от вашей отрасли и сферы применения, эта скорость имеет значение. Иногда много. да, иногда я буду использовать LINQ для быстрого и грязного подхода, когда мне все равно, как выглядит результирующий SQL, но пока что ничего автоматизированного не превосходит вручную настроенный SQL, когда производительность большой базы данных в высоком нагрузка на окружающую среду действительно имеет значение.
Учитывая тот факт, что вы использовали MySQL и SQLite, я полностью понимаю вашу точку зрения. Большинство СУБД имеют функции, которые потребуют некоторого программирования с вашей стороны, в то время как вы получаете его из базы данных бесплатно:
Индексы - вы можете хранить большие объемы данных и при этом иметь возможность очень быстро фильтровать и выполнять поиск благодаря индексам. Конечно, вы можете реализовать свою собственную индексацию, но зачем изобретать велосипед?
целостность данных - использование таких функций базы данных, как каскадные внешние ключи, может обеспечить целостность данных в системе. Вам нужно только объявить отношения между данными, а система позаботится обо всем остальном. Конечно, еще раз, вы можете реализовать ограничения в коде, но это больше работы. Рассмотрим, например, удаление, когда вам придется написать код в деструкторе объекта, чтобы отслеживать все зависимые объекты и действовать соответственно
возможность иметь несколько приложений, написанных на разных языках программирования, работающих на разных операционных системах, некоторые даже распределенные по сети - все используют одни и те же данные, хранящиеся в общей базе данных
очень простая реализация шаблона наблюдателя с помощью триггеров. Есть много случаев, когда только некоторые данные зависят от некоторых других данных, и это не влияет на аспект пользовательского интерфейса приложения. Обеспечение согласованности может быть очень сложным или потребовать много программирования. Конечно, вы можете реализовать триггерное поведение с объектами, но это требует больше программирования, чем простое определение SQL
Здесь есть несколько хороших ответов. Я попытаюсь добавить свои два цента.
Мне нравится 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) до кластеров Oracle терабайтного размера. Учитывая его мощь, на самом деле это удивительно простой и небольшой набор команд.
- Это вездесущий стандарт. Практически у каждого языка программирования есть способ доступа к базам данных SQL. Попробуйте это с проприетарным двоичным протоколом.
- Все это знают. Вы можете легко найти экспертов, новые разработчики, как правило, понимают это в некоторой степени, не требуя обучения
- SQL очень тесно связан с реляционной моделью, которая была тщательно изучена в отношении оптимизации и масштабируемости. Но все же часто требуется ручная настройка (создание индекса, структура запроса и т. Д.), Что относительно просто из-за текстового интерфейса.
Но зачем использовать язык SQL для взаимодействия с такой базой данных?
Я думаю, что по той же причине вы используете читаемый (исходный код) язык для взаимодействия с компилятором.
Лично я бы использовал некоторый байт-код "скомпилированный запрос базы данных", который будет один раз собран внутри клиентского приложения и передан в базу данных.
Это существующая (необязательная) функция баз данных, называемая "хранимыми процедурами".
Редактировать:
Я был бы очень признателен, если бы вы могли привести несколько примеров, в которых SQL используется без ORM, и почему
Когда я реализовал свой собственный ORM, я реализовал инфраструктуру ORM, используя ADO.NET: и использование ADO.NET включает использование операторов SQL в его реализации.
После всех правок и комментариев основной вопрос вашего вопроса выглядит следующим образом: почему природа SQL ближе к интерфейсу человек / база данных, чем к интерфейсу приложения / базы данных?
И очень простой ответ на этот вопрос таков: потому что это именно то, что изначально и предполагалось.
Предшественники SQL (предположительно, наиболее важным является QUEL) были предназначены именно для языка QUERY, т. Е. Языка, в котором не было INSERT, UPDATE, DELETE.
Более того, он должен был быть языком запросов, который мог бы использовать любой пользователь, при условии, что пользователь знал о логической структуре базы данных и, очевидно, знал, как выразить эту логическую структуру в языке запросов, который он использовал.
Первоначальные идеи, лежащие в основе QUEL/SQL, заключались в том, что база данных была построена с использованием "любого возможного механизма", что "настоящая" база данных могла быть действительно чем угодно (например, одним единственным гигантским файлом XML - хотя "XML" не считался допустимым вариантом) в то время) и что был бы "некоторый механизм", который понимал, как преобразовать фактическую структуру этого "всего, что угодно" в логическую реляционную структуру, как это было воспринято пользователем SQL.
Тот факт, что для того, чтобы на самом деле этого добиться, базовые структуры должны "относиться к ним с точки зрения отношений", не был понят в те дни, как сейчас.
Да, раздражает необходимость писать операторы SQL для хранения и извлечения объектов.
Вот почему Microsoft добавила такие вещи, как LINQ (языковой интегрированный запрос) в C# и VB.NET, чтобы можно было запрашивать базы данных, используя объекты и методы вместо строк.
У большинства других языков есть что-то похожее с разным уровнем успеха в зависимости от возможностей этого языка.
С другой стороны, полезно знать, как работает SQL, и я считаю ошибкой полностью оградить себя от него. Если вы используете базу данных, не задумываясь, вы можете писать крайне неэффективные запросы и неправильно индексировать базу данных. Но как только вы поймете, как правильно использовать SQL и настроите свою базу данных, у вас появится очень мощный проверенный инструмент, позволяющий найти именно те данные, которые вам нужны, очень быстро.
Моя самая большая причина для SQL-это специальные отчеты. Этот отчет хотят ваши бизнес-пользователи, но пока не знают, что он им нужен.
SQL - это интерфейс между человеком и базой данных. Вопрос в том, почему мы должны использовать его для взаимодействия приложений и баз данных? Я до сих пор прошу примеры написания / отладки SQL людьми.
Я часто использую sqlite, начиная с самых простых задач (таких как запись журналов брандмауэра непосредственно в базу данных sqlite) и заканчивая более сложными аналитическими и отладочными задачами в моих повседневных исследованиях. Размещение моих данных в таблицах и написание SQL-запросов для их интересного анализа, кажется мне наиболее естественным в этих ситуациях.
С вашей точки зрения, почему он до сих пор используется в качестве интерфейса между приложением / базой данных, это мое простое рассуждение:
Существует около 3-4 десятилетий серьезных исследований в этой области, начиная с 1970 года, когда была опубликована основополагающая статья Кодда по реляционной алгебре. Реляционная алгебра формирует математическую основу для SQL (и других QL), хотя SQL не полностью следует реляционной модели.
"Текстовая" форма языка (помимо того, что она легко понятна людям) также легко разбирается на машинах (скажем, с использованием синтаксического анализатора грамматики, таких как lex) и легко конвертируется в любой "байт-код" с использованием любого количества оптимизаций.
Я не уверен, что выполнение этого каким-либо другим способом принесло бы убедительные преимущества в общих случаях. В противном случае он был бы, вероятно, обнаружен и принят за 3 десятилетия исследований. SQL, вероятно, обеспечивает лучшие компромиссы при преодолении разрыва между людьми / базами данных и приложениями / базами данных.
Тогда возникает интересный вопрос: "Каковы реальные преимущества использования SQL любым другим" нетекстовым "способом?" Буду гуглить за это сейчас:)
SQL - это общий интерфейс, используемый платформой СУБД - весь смысл интерфейса в том, что все операции с базой данных могут быть определены в SQL без необходимости дополнительных вызовов API. Это означает, что существует общий интерфейс для всех клиентов системы - прикладного программного обеспечения, отчетов и специальных инструментов запросов.
Во-вторых, SQL становится все более полезным, поскольку запросы становятся все более сложными. Попробуйте использовать LINQ, чтобы указать 12-стороннее объединение с тремя условиями, основанными на экзистенциальных предикатах, и условием, основанным на агрегате, вычисленном в подзапросе. Подобные вещи довольно понятны в SQL, но вряд ли возможны в ORM.
Во многих случаях ORM выполнит 95% того, что вы хотите - большинство запросов, выдаваемых приложениями, представляют собой простые операции CRUD, которые ORM или другой механизм интерфейса универсальной базы данных могут легко обрабатывать. Некоторые операции лучше всего выполнять с использованием пользовательского кода SQL.
Тем не менее, ORM не являются первичными и конечными для взаимодействия с базой данных. "Шаблоны корпоративной прикладной архитектуры" Фаулера содержат довольно хороший раздел, посвященный другим типам стратегии доступа к базам данных, с небольшим обсуждением достоинств каждого из них.
Часто есть веские причины не использовать ORM в качестве основного уровня интерфейса базы данных. Хорошим примером является то, что библиотеки баз данных платформы, такие как ADO.Net, часто выполняют достаточно хорошую работу и прекрасно интегрируются с остальной средой. Вы можете обнаружить, что выгода от использования какого-либо другого интерфейса на самом деле не перевешивает выгоды от интеграции.
Однако последняя причина, по которой вы не можете игнорировать SQL, заключается в том, что вы в конечном итоге работаете с базой данных, если вы работаете с приложением базы данных. Существует множество историй WTF о недоработках в коде коммерческих приложений, написанных людьми, которые не понимают базы данных должным образом. Плохо продуманный код базы данных может вызывать проблемы во многих отношениях, и безрассудная мысль о том, что вам не нужно понимать, как работает СУБД, является актом высокомерия, который обязательно придет и укусит вас однажды. Хуже того, он придет и укусит другого бедного чмо, который унаследует ваш код.
Хотя я понимаю вашу точку зрения, язык запросов SQL имеет место, особенно в больших приложениях с большим количеством данных. И, чтобы указать на очевидное, если языка не было, вы не могли бы назвать его SQL (язык структурированных запросов). Преимущество использования SQL по сравнению с описанным вами методом заключается в том, что SQL, как правило, очень удобочитаем, хотя некоторые действительно расширяют границы своих запросов.
Я искренне согласен с Марком Байерсом: не стоит защищать себя от SQL. Любой разработчик может написать SQL, но для того, чтобы ваше приложение работало хорошо с взаимодействием SQL, понимание языка является обязательным.
Если бы все было предварительно скомпилировано с помощью байт-кода, как вы описали, я бы не хотел, чтобы был тот, кто должен был отлаживать приложение после того, как первоначальный разработчик ушел (или даже после того, как не видел код в течение 6 месяцев).
Я думаю, что предпосылка вопроса неверна. То, что SQL может быть представлен как текст, несущественно. Большинство современных баз данных компилируют запросы только один раз и кэшируют их в любом случае, так что у вас уже есть "скомпилированный байт-код". И нет никаких причин, по которым это не могло бы произойти с точки зрения клиента, хотя я не уверен, что кто-то сделал это.
Вы сказали, что SQL - это текстовое сообщение, я думаю о нем как о мессенджере, и, как мы знаем, не стреляйте в мессенджера. Реальная проблема заключается в том, что отношения не являются достаточно хорошим способом организации данных реального мира. SQL это просто помада на свинье.
Да, текст немного неэффективен. Но на самом деле получение данных намного дороже, поэтому текстовый sql достаточно незначителен.
На самом деле, было выпущено несколько продуктов, не относящихся к базе данных SQL (например, Objectivity, Oracle Berkeley DB и т. Д.), Но ни один из них не удался. В будущем, если кто-то найдет интуитивно понятную альтернативу SQL, это ответит на ваш вопрос.
Один из принципов разработки Unix можно сказать так: "Написание программ для обработки текстовых потоков, потому что это универсальный интерфейс".
И именно поэтому, я полагаю, именно поэтому мы обычно используем SQL вместо некоторого "байтового SQL", который имеет только интерфейс компиляции. Даже если бы у нас был байт-SQL, кто-то написал бы "Текст SQL", и цикл был бы завершен.
Кроме того, MySQL и SQLite менее полнофункциональны, чем, скажем, MSSQL и Oracle SQL. Таким образом, вы все еще находитесь в нижней части пула SQL.
Я не думаю, что большинство людей получают ваш вопрос, хотя я думаю, что это очень ясно. К сожалению, у меня нет "правильного" ответа. Я думаю, это комбинация нескольких вещей:
- Полу произвольные решения, когда он был разработан, такие как простота использования, отсутствие необходимости в компиляторе SQL (или IDE), переносимость и т. Д.
- Это случилось хорошо (вероятно, по тем же причинам)
- И теперь по историческим причинам (совместимость, общеизвестность, проверенность и т. Д.) Продолжает использоваться.
- Я не думаю, что большинству компаний надоело другое решение, потому что оно работает хорошо, не является узким местом, это стандарт, бла, бла...
SQL был создан для предоставления интерфейса для выполнения специальных запросов к реляционной базе данных.
Как правило, большинство реляционных баз данных понимают некоторую форму SQL.
Объектно-ориентированные базы данных существуют, и (предположительно) используют объекты для выполнения их запросов... но, насколько я понимаю, базы данных OO имеют гораздо больше подслушивания, а реляционные базы данных работают просто отлично.
Реляционные базы данных также позволяют вам работать в "отключенном" состоянии. Получив запрошенную информацию, вы можете закрыть соединение с базой данных. В базе данных OO вам нужно либо вернуть все объекты, связанные с текущим (и те, с которыми они связаны... и... и т. Д.), Либо заново открыть соединение, чтобы получить новые объекты такими, какие они есть. доступ.
В дополнение к SQL у вас также есть ORM (объектно-реляционные отображения), которые отображают объекты в SQL и обратно. Их довольно много, в том числе LINQ (.NET), MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class::DBI (Perl) и т. Д.,
Язык базы данных полезен, потому что он предоставляет логическую модель для ваших данных независимо от любых приложений, которые его используют. Однако у SQL есть много недостатков, и немаловажным является то, что его интеграция с другими языками слаба, поддержка типов примерно на 30 лет отстает от остальной отрасли, и в любом случае он никогда не был действительно реляционным языком.
SQL выжил главным образом потому, что на рынке баз данных доминировали и остаются три мегапроизводителя, которые заинтересованы в защите своих инвестиций. Это меняется, и дни SQL, вероятно, сочтены, но модель, которая, наконец, заменит его, вероятно, еще не пришла - хотя в эти дни есть много соперников.
Если в первой части вы, кажется, ссылаетесь на то, что обычно называют объектным импедансом реляционного отображения. Уже есть много рамок для решения этой проблемы. Есть также торговые предложения. Некоторые вещи будут проще, другие станут более сложными, но в общем случае они работают хорошо, если вы можете позволить себе дополнительный слой.
Во второй части вы, кажется, жалуетесь на то, что SQL является текстом (он использует строки вместо идентификаторов и т. Д.)... SQL - это язык запросов. Любой язык (компьютерный или иной), предназначенный для чтения или написания людьми, ориентирован на текст. Сборка, C, PHP, вы называете это. Зачем? Потому что, ну... это имеет смысл, не так ли?
Если вы хотите предварительно скомпилированные запросы, у вас уже есть хранимые процедуры. Подготовленные заявления также составляются один раз на лету, IIRC. Большинство (если не все) драйверы БД в любом случае общаются с сервером базы данных, используя двоичный протокол.
Я думаю, что причиной могут быть алгоритмы поиска / поиска / захвата, с которыми связан sql laungage. Помните, что sql разрабатывался в течение 40 лет - и цель была и в предварительном, и в отношении пользователя.
Спросите себя, как лучше всего найти 2 атрибута. Теперь зачем исследовать каждый раз, когда вы захотите сделать что-то, что включает в себя каждый раз, когда вы разрабатываете свое приложение. Предполагая, что основной целью является разработка вашего приложения при разработке приложения.
Приложение имеет сходство с другими приложениями, база данных имеет сходство с другими базами данных. Таким образом, должен быть "лучший способ" взаимодействия логически.
Также спросите себя, как бы вы разработали лучшее консольное приложение, которое не использует sql laungage. Если вы не можете этого сделать, я думаю, вам нужно разработать новый тип графического интерфейса, который еще более прост в использовании, чем с консолью, - чтобы разрабатывать вещи из него. И это может быть на самом деле возможно. Но все же большая часть разработки приложений основана на консоли и наборе текста.
Тогда, когда дело доходит до запуска, я не думаю, что вы можете сделать намного более простой текстовый перевод, чем sql. И помните, что каждое слово чего-либо неразрывно связано с его значением - если вы удалите значение, которое слово не может использовать, - если вы удалите слово, вы не сможете передать значение. Тебе нечем описать это (и, может быть, ты даже не думаешь, что это потому, что он не будет связан с чем-то еще, о чем ты думал раньше...).
Таким образом, в принципе, наилучшие возможные алгоритмы для манипулирования базой данных назначаются словам - если вы удалите эти слова, вам придется назначить эти манипуляции чем-то другим - и что бы это было?
Есть много нереляционных систем баз данных. Вот только некоторые из них: Memcached Tokyo Cabinet
Потому что часто вы не можете быть уверены, что (ссылаясь на вас) "никто никогда не видел после развертывания". Знание того, что существует удобный интерфейс для создания отчетов и запросов на уровне набора данных, - это хороший путь для развития вашего приложения.
Вы правы, что есть другие решения, которые могут быть применимы в некоторых ситуациях: XML, текстовые файлы, OODB...
Но наличие набора общих интерфейсов (таких как ODBC) - огромный плюс для жизни данных.
Что касается поиска реляционной базы данных, которая не использует SQL в качестве основного интерфейса, я думаю, вы ее не найдете. Причина: SQL - отличный способ поговорить об отношениях. Я не могу понять, почему это важно для вас: если вам не нравится SQL, поместите над ним абстракцию (например, ORM), чтобы вам не пришлось об этом беспокоиться. Пусть абстракция беспокоится об этом. Он доставит вас в то же место.
Однако проблема, которую вы действительно упоминаете здесь, - это разъединение объектных отношений - проблема связана с самим отношением. Объекты и реляционные кортежи не всегда могут быть отношениями 1: 1, поэтому разработчик может разочароваться в базе данных. Решение этой проблемы заключается в использовании другого типа базы данных.
Я думаю, что вы можете использовать ORM
если и только если вы знаете основы sql.
иначе результат там не самый лучший