Это перевод, оригинал здесь:woohoo.prism A.IO/docs/under это...

Обзор

Этот пост объяснит нашу мотивацию для разработки Prisma и какие преимущества имеет Prisma по сравнению с другими инструментами баз данных, такими как ORM и конструкторы SQL.

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

Prisma предоставляет набор кратких API-интерфейсов, упрощающих работу с базой данных и понимание операторов запросов. API Prisma является типобезопасным, а возвращаемые данные представляют собой простые старые объекты JavaScript.

Проблемы с инструментами баз данных, такими как SQL и ORM

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

Рукописный SQL: сильный контроль, низкая производительность

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

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

SQL Constructor: сильный контроль, средняя производительность

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

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

ORM: Слабый контроль, хорошая производительность

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

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

Итак, каковы недостатки?

ORM похож на трясину, которая начинается ровно, но со временем становится все более сложной и вскоре заманивает своих пользователей в ловушку обязательств без четкой границы, без четких условий выигрыша и без четкой стратегии выхода — —The Vietnam of Computer Science

Разработчики понимают данные как набор объектов, но на самом деле данные представляют собой таблицу.

Это различие в восприятии может привести к «Несоответствие объектно-реляционного импеданса», из-за этого несоответствия многие разработчики не любят традиционные ORM.

Например, два процесса когнитивных объектных отношений различны:

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

Этот пример раскрывает одну из больших ловушек ORM: использование ORM может якобы использоваться для доступа к другому объекту через сопоставление точек, но в частном порядке оно будет создавать операторы SQL JOIN.Эти JOIN имеют недостатки производительности и, вероятно, замедлят ваше приложение.очень медленно , например знаменитыйп+1 проблема.

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

Разработчики должны заботиться о данных, а не о SQL

SQL, родившийся в 1970-х годах, — это испытанный язык, но по мере развития средств разработки мы не можем не задаться вопросом: действительно ли SQL — лучший способ абстрагировать данные?

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

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

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

Prisma делает разработчиков более продуктивными

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

• Думайте с точки зрения объектов, а не отображения реляционных баз данных в своем мозгу.
• Запросы не являются классами, чтобы избежать сложных моделей данных
• Единый источник достоверной информации, база данных и модель данных из одного места
• Здоровые ограничения для предотвращения распространенных ошибок и анти-шаблонов
• Как легко поступать правильно («Путь к успеху»)
• Безопасность типа результата запроса
• Используйте меньше шаблонов, чтобы разработчики могли сосредоточиться на бизнесе
• Автодополнение редактора

Возвращаясь снова к предыдущей картинке, положение Призмы на картинке такое

Мощность управления выше, чем у конструктора SQL, ниже, чем у рукописного SQL;

Но самый продуктивный!