[sfn42]

Yeah, that's essentially what I mean when I say crud app. It's basically a web api written in something like C# or whatever you prefer, which receives HTTP requests and translates them into DB operations. CRUD and views basically.

For this type of development you want the DB to handle basically all the heavy lifting, the trick is to design the DB schema well and have the web API send the right SQL to get exactly the data you need for any given request and then your app will generally be nice and snappy. 90-99% of the logic is just SQL.

For the C# example you'd typically use Entity Framework so the entirety of the DB schema and the DB interaction etc is defined within the C# code.

[bawolff]

I was actually going for the opposite point - databases generally meet the definition of CRUD app. You create rows, read them, update them and delete them (literally SQL verbs INSERT, SELECT, UPDATE, DELETE). But they are highly complex pieces of software. People who program them are generally hard core.

[ben_w]

I think databases are more of the development environment for such apps, rather than the apps themselves. C.f. how Electron apps are "just web pages shipped with their own browser", and yet a browser (and its JavaScript runtime) are significantly more complex than almost any app built in the manner of an Electron app.

[tracker1]

I prefer to just use Dapper for most DB interactions with C#... EF (and ORM tooling in general) can come with a lot of gotchas that simply understanding the SQL you are generating can go a long way to avoid.

[sfn42]

Dapper is nice, but what you don't get as far as I know is migrations. With EF the app just spins up the whole DB from scratch which is great for onboarding or when you just needed a new laptop etc. Also EF is fine as long as you know what you're doing, or at least pay attention to what you're doing.

[tracker1]

I use grate for migrations. I prefer a more manual, hands on approach to that as well.

[chihuahua]

I think you're missing the point of the comment you've replied to. That comment is talking about implementing the DB. When you're implementing a DB, you can't just forward reads and writes to another DB. Someone has to actually implement that DB on top of a filesystem, raw disk, or similar storage.

[aliher1911]

With the post's logic if you work on DB you likely have an SQL engine that is a CRUD on top of storage engine. And storage engine is a CRUD on top of some disk storage, which is CRUD over syscalls on files. Think Mysql using MyRocks using RocksDB. And keep applying until there's no sense left.

[sfn42]

If you are referring to my post, it's about web applications. I'm not in any way claiming that postgres is a crud app. I'm describing how to design a good web application that mostly revolves around a database. Which is what people mean when they say crud app. It's just any app that's mostly crud. Where the majority of the logic can be handled by the database like I described.

A lot of apps are just about putting data into a DB and then providing access to that data. Maybe using the data to draw some nice graphs and stuff. That's a crud app.