5 ms·
If that comparison table is right about "no foreign keys," that's a showstopper for me. :( Back to looking at Couchbase, Yugabase, or Citus for my distributed
by SomeCallMeTim 4y ago
If that comparison table is right about "no foreign keys," that's a showstopper for me. :(
Back to looking at Couchbase, Yugabase, or Citus for my distributed SQL.
- keredson 4y agothat's very common in distributed databases. even traditional databases, it's very common to not have FKs on large tables, and just handle it in software. indexing billions or more of rows is non-trivial.
- MichaelMoser123 4y agodidn't notice that. Wow that's pretty basic...
- reactor 4y agoI guess its depends, for many use cases, it can be managed at application level. I've parted ways with FK for a long time since it created more hassles than it solved esp when it comes to sharding and replications.
- SomeCallMeTim 4y agoYou can always handle it at the application level. The trick is that it's better to have the extra guard rails. And all of Couchbase, Yugabase, and Citus support foreign keys even with sharding and replication, so that's not an issue when the DB supports it.
- SomeCallMeTim 4y agoI said Couchbase above but meant CockroachDB. Brain fart, but can't edit the message now. :|
- ranguna 4y agoTry looking at cockroachDB, the only thing holding me back on that is the absence of triggers.
- SomeCallMeTim 4y agoIt was a brain fart: Meant to say CockroachDB instead of CouchBase. Oops. So yeah, it's on my short list. :) I've used triggers in one project recently, but that was literally the first time in five years so it's not as much of a must-have for me.
- fomichev3000 4y agoForeign keys come at a cost, especially in distributed database. It's just a fact. If you can avoid them, it's great.