3 ms·
We all did this from like 2008-2015. You wind up defining relationships in code instead, across dozens of API calls without a central spec and it's super easy
by woooooo 4y ago
We all did this from like 2008-2015.
You wind up defining relationships in code instead, across dozens of API calls without a central spec and it's super easy to get wrong. If it were as easy as you say we'd all be using MongoDB now.
- gibsonf1 4y agoThat would be a different approach than us as our entire schema consists of 4 doc types with 14 keys/functons which models the universe, and then we use specifications in the data to control inference and system operations etc. So it's becoming a no-code system powered by the specs captured in the data.
- woooooo 4y agoIf your business domain is document-centric without a lot of strong foreign key relationships between them, then you do you. Just saying other domains can run into "denormalization hell" and "super complicated API traversal".
- gibsonf1 4y agoWe do both documents, the internals of documents and a full model of space-time with our digital twin technology, but we've spent decades arriving at a extremely essentialized lower ontology schema with which we can model everything - thats really the secret to it.
- tracker1 4y agoI tend to think of a classifieds site as pretty much the ideal case for a typical nosql approach... especially Mongo being a great fit. Today, I might use PostgreSQL/Cockroach with some fixed and a JSON column for extra bits based on type of classified. Not everything fits into this mold, it's a matter of mix/match today, and there are no clear rules for how you get into scaling as needed...