Уніфікація запитів програмування та запитів до бази даних [закрито]

Розглянемо загальний підручник для об'єктно-орієнтованих мов програмування, таких як C ++ або Java: створити просту систему обробки замовлень з об’єктами, що представляють рахунки, замовлення, елементи тощо (або щось більш-менш еквівалентне). Створює ідеальний інтуїтивний сенс, але слон за обіднім столом полягає в тому, що це не реально, оскільки це об'єкти в пам'яті; в реальній системі рахунки, доручення тощо фактично не живуть в пам'яті, в першу чергу вони живуть в базі даних, в пам'яті є лише короткочасне дзеркало.

Ви можете написати багато коду, щоб прочитати та записати з бази даних, але це настільки виснажливо і схильне до помилок, що ніхто насправді цього не робить.

Всі в кінцевому підсумку використовують ORM, але вони самі настільки проблемні, що відомий документ називає їх "В'єтнамом нашої галузі".

Я не думаю, що це невідповідність об’єкта та реляції настільки, як невідповідність мови програмування та бази даних, що є окремими речами, які не знають один про одного . Концепція: рішення полягає в тому, щоб мати єдину мову, яка є і мовою запиту програмування, і базою даних, що, в свою чергу, вимагатиме, щоб час мовлення також був базою даних, а компілятор JIT також був оптимізатором запитів.

Отже, це підсумок проблем, які я бачу. Моє запитання: чи хтось ще,

1. Фактично побудована така єдина система

2. Спробував, але не зміг побудувати таку єдину систему

3. Напишіть щось істотне на тему, як би ви йшли про будівництво таких, або чому чи чому ні

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

Це моя думка. Поки я бачу, звідки ти родом, я просто не бачу, як це відбувається з точки зору дизайну.

Зберігання даних - надзвичайно складна тема. Так само і мови програмування. Об'єднання цих двох елементів призведе до складного вибуху. Потрібно було б багато зусиль, щоб насправді зробити обидва досить хорошими, щоб люди насправді хотіли ним користуватися. Я думаю, що вже згаданий MUMPS - хороший приклад. Або ви можете переглянути різні варіанти SQL, які мають повну мову, зафіксовану на них. Вони можуть бути корисними, але я не думаю, що люди охоче ними користуються.

Тож розділення їх - це зрозумілий спосіб вирішити цю складність. Крім того, не зв'язуючи їх разом, це дозволяє як змінюватися, так і розвиватися з часом. Наприклад, SQL старий і не сильно змінився з часу його створення. Але мови, які використовуються для запуску програм, різко змінилися за той самий період. А зараз відбувається навпаки. Мови залишаються здебільшого однаковими, коли бази даних змінюються та розвиваються.

Ще одна проблема розгортання під час виконання. Поєднання двох означатиме, що і база даних, і додаток, або веб-сервер повинні працювати в одному і тому ж процесі. Це надзвичайно обмежує, як з точки зору технічного обслуговування, так і від можливості керувати ними на окремих комп’ютерах або у взаємовідносинах багато в одному.

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

Схоже, ви робите деякі основні припущення. Наприклад, ви припускаєте, що всі пишуть у реляційні бази даних. Це просто не так, є безліч прикладів баз даних інших ароматів (dbs об'єкта, dbs документа тощо), які використовують рідну мову програмування для написання всього коду та управління наполегливістю.

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

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

Варто також зазначити, що раніше насправді було багато підходів "все в одному". Мови основного кадру часто вбудовували власну логіку стійкості, і є такі мови, як Smalltalk, які взагалі не розрізняють код і дані. Знову ж таки, вони часто хороші для деяких випадків використання, але не для всіх.

1. Так (не я). Це називалося МУМПС .

2. Відповідно до цього колишнього питання SE.SE , або цієї статті , MUMP не були дуже розроблені. Але він справді застосовувався в галузі охорони здоров’я (і, мабуть, все ще існують системи, що використовують його), тож не є повним збоєм.

3. Ви обов'язково знайдете інформацію про нього, тепер знаєте, що шукати. Почніть із посилання Вікіпедія вище.

4. Шукайте об’єктно-орієнтовані бази даних, багато з яких залежать від мови. Вони намагалися вирішити невідповідність об'єктів більш простими способами, ніж ORM.

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

Малий розмова, мабуть, найближчий до того, що ви описуєте. Об'єкт в пам'яті зберігається у "зображенні", тому мовне середовище може використовуватись (об'єктна) база даних поза коробкою. І більшість сучасних мов мають якийсь вбудований механізм стійкості, який означає, що об’єкти в мовному середовищі можна зберігати та запитувати за допомогою самої мови.

Це дуже зручно для однокористувацьких додатків. Але підхід не буде масштабуватися для декількох користувачів, оскільки їм буде потрібно спільний обсяг пам’яті, що очевидно ставить обмеження на кількість користувачів. Масштабоване рішення вимагає окремого сервера баз даних, який управляє паралельністю. Вже тоді існує безліч баз даних NoSql, яка інтегрується в конкретне мовне середовище і дозволяє зберігати та запитувати об'єкти в самій мові.

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

У цих випадках дійсно дуже елегантно і зручно інтегрувати базу даних з мовою програмування і уникати "невідповідності імпедансу". То чому люди все ще використовують реляційні бази даних відокремлені від програмного середовища та намагаються з'єднати деякі ORM-хижі?

Виявляється, є ряд переваг у тому, що дані та запити є окремими від будь-якої конкретної мови програмування та середовища.

• Незалежність даних. У більшості організацій дані фактично доступні за допомогою декількох додатків. У магазині може бути база даних, що використовується веб-інтерфейсом, інструментом підтримки клієнтів, механізмом звітності тощо. Самі дані часто є довготривалими, тоді як програми надходять та йдуть. З'єднання даних з одним конкретним середовищем програмування буде блокуватися до конкретного середовища програмування. Але мови програмування приходять і відходять, тоді як дані живуть назавжди.
• Спеціальний запит. Надзвичайно зручно мати можливість відкрити підказку бази даних та написати запит. Якби запит був щільно пов'язаний із середовищем програмування, це було б завданням програмування, і тільки розробники змогли б це зробити.
• Уникайте блокування. Оскільки SQL є стандартом, кілька постачальників можуть надавати системи управління базами даних, які є більш-менш взаємозамінними. Це дозволяє уникнути блокування постачальника та полегшує порівняння продуктів.
• Вільна муфта. Маючи чітко визначений інтерфейс між прикладним шаром та базою даних, можна налаштувати та оптимізувати базу даних незалежно від логіки програми.
• Спільний інтерфейс. Оскільки інтерфейс бази даних не залежить від логіки додатків, позапрофільні інструменти можуть використовуватися для профілювання, реплікації, аналізу тощо.

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

На практиці такі контролери не повинні піддаватися громадськості з міркувань безпеки, оскільки недолік у конфігурації бази даних або помилка призведе до оприлюднення ваших цінних даних громадськості.

На мою особисту думку, це хороший підхід, і враховуючи, чи база даних підтримує якусь функцію «карта / зменшення», яка в режимі реального часу буде оновлювати агреговані дані / текстові індекси та інші часто запитувані дані, додаючи між собою тонкий рівень захисту (назвіть це завантаження balancer) зробить функціональний додаток, що працює в розподіленій базі даних.

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класом - persistable упорядкованих колекцій об'єктів з унікальними / неунікальні ключами.

Набір функцій схожий з MongoDB або іншими базами даних NoSQL, але ідентифікатор не вимагає окремого ORM - доступ до db робиться суто сценаріями.

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

Єдина система, яка підходить до вашої ідеї, про яку я знаю, - це аквамета (рядок тегів: "веб-стек розробників, вбудований у 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/