2 ms·
And that's fine. If it's really big data I imagine I'd be in some kind of scalable no-SQL situation. If it's not so big, Postgres will comfortably handle my a
by mrkeen 2y ago
And that's fine.
If it's really big data I imagine I'd be in some kind of scalable no-SQL situation.
If it's not so big, Postgres will comfortably handle my access patterns even without joins.
If it's in the sweet spot where I need Postgres JOINS but I don't need no-SQL, well then, refactoring will be a breeze. I'll turn:
class TaxCalculator {
UserFetcher userFetcher;
PurchasesFetcher purchasesFetcher;
TaxResult calculate(UserId userId) {..}
}
into:
class TaxCalculator {
UserPurchasesFetcher userPurchasesFetcher;
TaxResult calculate(UserId userId) {..}
}
which is backed by JOINS inside. And I can do this refactoring in two mutually-independent steps. I can make my Postgres class implement UserPurchasesFetcher without thinking about TaxCalculator, and vice versa.
And if it's about the data integrity that JOINs could notionally provide, I no longer believe in doing things that way. The universe doesn't begin and end within my Postgres instance. I need to be transacting across boundaries, using event sourcing, idempotency, eventual consistency and so forth.