Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We migrated to SQL. Our biggest learning? Don't use Prisma

codedamn.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#71

Post by DanielHB »

l5870uoo9y wrote: post #44

One thing that keeps coming up is that SQL equals low productivity. I don't think this is true. I think the culprit is that most developers are using to heavily abstracting SQL using ORMs like Prisma that hides the database and SQL logic. Since building a SQL generator ( https://aihelperbot.com ) as a side project, I have become much more proficient in SQL and even though I am also locked into Prisma, I use the `quer…

I dunno, 90% of my queries are super simple and prisma does the job pretty well. In my relatively small prisma project I have a grand total of 2 raw queries.

Also prisma raw query builder and migrations are really good.

I don't see all the hate, you can mix and match both approaches just fine.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#72

Post by zaphirplane »

mijoharas wrote: post #13

> Weird pricing: PlanetScale prices you on row-reads and row-writes per month. What is weird is that row-reads is something that nobody controls. It is the SQL query planner which determines the query plan, which results in how many rows you’re reading internally. Remember that row-reads are not row returns. You can write a wrong query that returns 0 rows but can still do a full table scan of 1M rows and PlanetScale…

What about indexes, should ppl add a ton of indexes to optimize the query cost

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#73

Post by lpapez »

CharlieDigital wrote: post #52
jeswin wrote: post #49

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language. EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. T…

.NET and EF Core is the platform that most teams probably want but .NET and C# can't quite shake it's pre-Core image. It always strikes me as odd that teams can embrace GitHub, TypeScript, and VS Code and then react negatively to C# and .NET being Microsoft platforms. EF Core is perhaps the most powerful, most mature ORM at this point. .NET Web APIs are incredibly productive and performant with really good DX. C# isn…

For me that's not the primary reason. I was discouraged from learning C# because of the sheer number of keywords and concepts in the language.

Contrasting this with Go where I landed a gig after two weeks of learning by myself and felt productive right away.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#74

Post by ivanb »

l5870uoo9y wrote: post #44

One thing that keeps coming up is that SQL equals low productivity. I don't think this is true. I think the culprit is that most developers are using to heavily abstracting SQL using ORMs like Prisma that hides the database and SQL logic. Since building a SQL generator ( https://aihelperbot.com ) as a side project, I have become much more proficient in SQL and even though I am also locked into Prisma, I use the `quer…

Indeed. A query builder is only really useful for dynamic queries and in practice they are few. I would argue that for performance and complexity reasons dynamic queries in real-world applications should be avoided.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#76

Post by dncornholio »

francislavoie wrote: post #3

IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.

This is what I said when I just started coding.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#78

Post by dncornholio »

francislavoie wrote: post #10
leononame wrote: post #6

Earlier quoted context omitted.

That is a strange take tbh. For me, ensuring data integrity at the database level gives me a lot of peace of mind. Migrations are actually safer and easier because the database will complain if something's wrong, and at the application level I can do an opportunistic insert and if the FK is not valid, I'll get an error, which is really nice if I don't need the related record at all so I don't need to fetch it first.

With foreign keys, I can't use https://github.com/github/gh-ost for zero downtime migrations. Instant deal breaker, because schema changes are inevitable given business evolution.

Then don't use it. A migration tool that has no foreign key support is not a good migration tool. And it's even a worse reason to tell other people FK's are bad.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#79

Post by fabian2k »

ivanb wrote: post #74
l5870uoo9y wrote: post #44

One thing that keeps coming up is that SQL equals low productivity. I don't think this is true. I think the culprit is that most developers are using to heavily abstracting SQL using ORMs like Prisma that hides the database and SQL logic. Since building a SQL generator ( https://aihelperbot.com ) as a side project, I have become much more proficient in SQL and even though I am also locked into Prisma, I use the `quer…

Indeed. A query builder is only really useful for dynamic queries and in practice they are few. I would argue that for performance and complexity reasons dynamic queries in real-world applications should be avoided.

I'm always surprised when I see this opinion. I think I might be writing fundamentally different kinds of applications because I need dynamic queries all the time. I often need several different kinds of filters for an endpoint that can be combined arbitrarily. Any UI that allows users to filter stuff by various criteria needs some kind of dynamic query building in the end.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#80

Post by CharlieDigital »

lpapez wrote: post #73
CharlieDigital wrote: post #52

Earlier quoted context omitted.

.NET and EF Core is the platform that most teams probably want but .NET and C# can't quite shake it's pre-Core image. It always strikes me as odd that teams can embrace GitHub, TypeScript, and VS Code and then react negatively to C# and .NET being Microsoft platforms. EF Core is perhaps the most powerful, most mature ORM at this point. .NET Web APIs are incredibly productive and performant with really good DX. C# isn…

For me that's not the primary reason. I was discouraged from learning C# because of the sheer number of keywords and concepts in the language. Contrasting this with Go where I landed a gig after two weeks of learning by myself and felt productive right away.

The thing is, if you're comfortable with TypeScript, it's really more or less just a small step to C#; the Venn diagram of the most commonly used keywords between TS and C# has a high degree of overlap.

A small repo here: https://github.com/CharlieDigital/js-ts-csharp

And a practical example of a Playwright web scraper in C# and TypeScript: https://github.com/CharlieDigital/playwright-scrape-api

"Too many keywords" is the weirdest objection to a programming language versus actually using the language to build something practical.

Edit: I'm actually curious as to which keywords you personally found the most challenging to grok or what tipped the scales of "this is too complicated".

Post reply on HN