Most active commenters
  • panzi(4)

←back to thread

570 points davidgu | 11 comments | | HN request time: 0.001s | source | bottom
Show context
osigurdson ◴[] No.44527817[source]
I like this article. Lots of comments are stating that they are "using it wrong" and I'm sure they are. However, it does help to contrast the much more common, "use Postgres for everything" type sentiment. It is pretty hard to use Postgres wrong for relational things in the sense that everyone knows about indexes and so on. But using something like L/N comes with a separate learning curve anyway - evidenced in this case by someone having to read comments in the Postgres source code itself. Then if it turns out that it cannot work for your situation it may be very hard to back away from as you may have tightly integrated it with your normal Postgres stuff.

I've landed on Postgres/ClickHouse/NATS since together they handle nearly any conceivable workload managing relational, columnar, messaging/streaming very well. It is also not painful at all to use as it is lightweight and fast/easy to spin up in a simple docker compose. Postgres is of course the core and you don't always need all three but compliment each other very well imo. This has been my "go to" for a while.

replies(12): >>44528211 #>>44528216 #>>44529511 #>>44529632 #>>44529640 #>>44529854 #>>44530773 #>>44531235 #>>44531722 #>>44532418 #>>44532993 #>>44534858 #
fathomdeez ◴[] No.44528216[source]
This kind of issue always comes up when people put business logic inside the database. Databases are for data. The data goes in and the data goes out, but the data does not get to decide what happens next based on itself. That's what application code is for.
replies(12): >>44528249 #>>44528293 #>>44528307 #>>44528582 #>>44528918 #>>44529077 #>>44529583 #>>44530054 #>>44530782 #>>44530978 #>>44532428 #>>44533144 #
1. panzi ◴[] No.44528293[source]
So what are your thoughts on constraints then? Foreign keys? Should that only be handled by the application, like Rails does (or did, haven't used in a long time).
replies(4): >>44528346 #>>44528702 #>>44529250 #>>44531409 #
2. fathomdeez ◴[] No.44528346[source]
I don't think of those as business logic, per se. They're just validity checks on what the data should look like before it's written to disk - they're not actionable in the way L/N is. That being said, constraints usually end up being duplicated outside the db anyway, but having them where the data rests (so you don't have to assume every client is using the correct constraint code) makes sense.
replies(1): >>44536541 #
3. Footkerchief ◴[] No.44528702[source]
You still use constraints even if you put all your business logic in stored procedures.
4. Lio ◴[] No.44529250[source]
Rails fully supports constraints and encourages you to use them.

You can either execute SQL in your migration or use add_check_constraint.

replies(1): >>44536496 #
5. parthdesai ◴[] No.44531409[source]
What happens to FKs when you've to partition/shard the db? At a certain scale, they actually hinder the inserts.
replies(2): >>44532672 #>>44533277 #
6. sgarland ◴[] No.44532672[source]
FK Constraints on partitioned tables has been a solved problem for years for Postgres. MySQL still doesn’t support them, unfortunately.

For sharding, Vitess kind of supports them; Citus fully supports them.

You’re correct that they do impact performance to an extent, but as a counter argument, if your data is incorrect, it doesn’t matter how quickly you wrote it.

7. cryptonector ◴[] No.44533277[source]
FKs are nothing special. It's just more INSERTs/UPDATEs/DELETEs. If you can't have a few more DMLs in your transactions in your sharded DB then you've already got scaling problems.

Really, FKs are typically implemented internally by RDBMSes as TRIGGERs that do what you expect FKs to do, which means they really are nothing more than syntactic sugar.

8. panzi ◴[] No.44536496[source]
Back when I used Rails the sentiment was: You don't need foreign keys, this is all handled by ActiveRecord.
replies(1): >>44548491 #
9. panzi ◴[] No.44536541[source]
I see. Further I have used triggers to automatically populate log tables or aggregate statistics on write. Why do I need fast statistics? For API limits. Customers have N free operations per months and such, so I have to query that on every operation. Do you consider these things as business logic that don't belong in the database?
10. Lio ◴[] No.44548491{3}[source]
I’m guessing that must have been the 00s then. I haven’t seen anyone downplay database constraints for a very long time.
replies(1): >>44561988 #
11. panzi ◴[] No.44561988{4}[source]
Sometime between 2005 and 2012 I think. It definitely was for a stretch of time where Rails people said that.