Объединение программирования и запросов к базе данных [закрыто]

Рассмотрим общий учебник для объектно-ориентированных языков программирования, таких как C ++ или Java: создайте простую систему обработки заказов с объектами, представляющими счета, заказы, предметы и т. Д. (Или что-то более или менее эквивалентное). Создает совершенное интуитивное чувство, но слон за обеденным столом - то, что это не реально, потому что это объекты в памяти; в реальной системе счета, заказы и т. д. фактически не живут в памяти, во-первых, они живут в базе данных, а представление в памяти является лишь кратковременным зеркалом.

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

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

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

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

1. Собственно построена такая единая система

2. Пробовал, но не смог построить такую ​​единую систему

3. Написано что-нибудь существенное на тему того, как бы вы пошли о создании такого, или почему, или почему бы и нет

4. Придумать альтернативный способ решения проблемы?

Это мое мнение. Хотя я вижу, откуда ты, я просто не вижу, как это происходит с точки зрения дизайна.

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

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

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

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

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

Например, Db4O совместим с Java и C #, ObjectDB на Java, VelocityDB на разных языках. Все драйверы MongoDB в конечном итоге заставляют вас писать что-то на вашем родном языке программирования (бонус, если вы делаете JavaScript, поскольку это означает, что оболочка также использует тот же синтаксис), и так далее.

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

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

1. Да (не я) Это называлось MUMPS .

2. Согласно этому бывшему вопросу SE.SE или этой статье , MUMP были не очень хорошо разработаны. Но он действительно использовался в индустрии здравоохранения (и я думаю, что все еще существуют системы, использующие его), так что это не полный провал.

3. Вы обязательно найдете информацию об этом, теперь вы знаете, что искать. Начните со ссылки в Википедии выше.

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

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

Smalltalk, вероятно, ближе всего к тому, что вы описываете. Объект в памяти сохраняется в «образе», поэтому языковая среда может использоваться в виде (объектной) базы данных из коробки. И в большинстве современных языков есть какой-то встроенный механизм персистентности, который означает, что объекты в языковой среде могут сохраняться и запрашиваться с использованием самого языка.

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

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

В этих случаях действительно очень элегантно и удобно интегрировать базу данных с языком программирования и избежать "несоответствия импеданса". Так почему же люди до сих пор используют реляционные базы данных отдельно от среды программирования и пытаются соединиться с каким-нибудь ORM-kludge?

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

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

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

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

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

1. Собственно построена такая единая система

Да, я сделал это в Скитере .

Скрипт Sciter представляет собой « JavaScript ++ » со встроенным постоянством:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Где ndb.rootнормальный объект с точки зрения JS. Все его свойства и подобъекты, доступные из него, являются постоянными - сохраняются и выбираются в БД при необходимости - прозрачно для кода:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Данные хранятся в БД либо в цикле GC, когда не хватает памяти, либо при явном ndb.commit()вызове.

Storageкласс сопровождается Indexклассом - персистентными упорядоченными коллекциями объектов с уникальными / неуникальными ключами.

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

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

Единственная система, подходящая к вашей идее, о которой я знаю, называется aquameta (строка тега: «стек веб-разработчика, встроенный в PostgreSQL»; см. Https://github.com/aquametalabs/aquameta , http://aquameta.org ). Есть несколько вступительных видео, которые не менее сумасшедшие, чем сама идея (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), и когда я говорю «сумасшедший», я имею в виду, что они внедрили свой собственный редактор и собственную систему контроля версий в Postgres.

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

Хорошая отправная точка для linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/