Представьте себе хаос: вы создаете бесплатную базу данных в NeonDB с 0,5 ГБ хранилища и думаете: «Отлично, я воспользуюсь бесплатным уровнем для тестирования» . Затем, несколько часов спустя, приходит фатальное электронное письмо: «Ваше хранилище занято!» . Вау, что ты имеешь в виду? Не было даже времени прогреть кресло! Ответ? Я использовал великолепную Prisma ORM и для улучшения провел несколько миграций в течение дня, просто моделируя схему.

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

Сначала вам нужно контекстуализировать себя. Я записывал CrazyStack class 124 (мой учебный курс по Node и React). И можно использовать postgres или mongodb без ORM. Однако студент попросил меня в WhatsApp включить Prisma в проект. Привет, я решил провести эксперимент.

Prisma ORM: просто, но дорого

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

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

Prisma очень хороша, но когда дело доходит до хранения, ей нравится выкладываться на все сто:

1. Круговые миграции: каждый раз, когда я запускал миграцию, Prisma создавала и сохраняла новые миграции. Каждый из них имеет свой небольшой пакет метаданных, журналов и таблиц.

2. Журналы, которые умножаются: Чтобы гарантировать, что все пойдет не так (или облегчить вам жизнь, если это произойдет), Prisma записывает подробные журналы. Но эти журналы накапливаются, и, поскольку я не пользуюсь «безлимитным» банком, они вскоре становятся проблемой.

3. Перегрузка вспомогательными таблицами: Помимо миграций, Prisma также создает дополнительные таблицы для отслеживания различных вещей, особенно в реляционных базах данных, таких как Postgres.

В конце концов, то, что казалось волшебным инструментом для упрощения жизни, съело мою бесплатную NeonDB.

SQL «Na Nail»: почему меньше значит больше

И здесь на помощь приходит старый добрый подход SQL. Да, Prisma — это здорово и экономит время, но иногда это просто усложняет ситуацию. Поговорим о преимуществах отказа от ORM и написания запросов вручную:

1. Абсолютный контроль: Никаких сюрпризов в законопроекте нет. Вы точно знаете, что делает каждая строка кода, и не обнаружите, что журналы или скрытые таблицы занимают ваше пространство.

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

3. Большая производительность: если Direct SQL выполнен правильно, он потребляет гораздо меньше места и ресурсов. Он идеально подходит для небольших банков, таких как NeonDB и для таких фриганистов, как я.

4. Никаких скрытых дел: никаких таблиц, созданных с нуля, или журналов транзакций, которые накапливаются. Контроль принадлежит вам и только вам.

Мораль этой истории:

Если вы, как и я, любите тестировать инструменты и проводить быстрые эксперименты, подумайте дважды, прежде чем добавлять Prisma ORM в свою базу данных с небольшим пространством. Является ли Призма чудом? И. Но в таком ограниченном банке, как NeonDB, это все равно что устроить вечеринку и обнаружить, что купленного пива не хватит на всех.

Иногда SQL «на лету» является самым безопасным способом, предоставляющим вам точный контроль над тем, что поступает в базу данных. И урок таков: в следующий раз я лучше подумаю, прежде чем запускать одну миграцию за другой для банка объемом 0,5 ГБ.