-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Database use cases #12
Comments
On the case for column-oriented databases: "How often do we ever aggregate the entire population of a single column? Aside from management COUNT operations (which themselves can often be served purely through statistics), it is, in my experience, a very rare case. Instead we filter and group and join." "Column-oriented databases are very cool, and they have a role to play in data that is much larger than available RAM, or where naive aggregates or stream processing is paramount. They’re often found for specific purposes in the financial industry, and there are some absolutely fantastic products. It is less conclusively a fit if your write load is at all significant, or if the usage of the data is general if not arbitrary. Column-oriented databases need to be even more purposefully used than row-oriented if you hope to have efficient operations." https://dennisforbes.ca/index.php/2014/04/04/the-real-advantage-of-column-oriented-databases/ |
"One of the principle advocacy points used to pitch many NoSQL solutions is the flexibility of the schema...But the selling point has never convinced me... How do you write an application with no data structure? How, practically, is the lack of a formal database schema a real benefit in the life cycle of an actual product, after the honeymoon period of “boy did I save time not having to consider a schema!” has passed?... It generally isn’t a benefit. Instead the emergent schema gets tightly bound with the application layer...The problem in this back-loaded model is that the database is often the longest-living part of the application, with many modern applications sharing the database descendant of implementations done decades ago, while the GUI is often wholesale rewrite after rewrite in completely differing technology stacks. Yet you lose all of the benefits of strong typing — to use a general language term — constraints... It is, more often than not, a foolish assumption that a temporary gain will yield long term benefits, when the opposite is generally true... It isn’t that these solutions are bad in isolation — they are fantastic at the right time, place and situation (just as schema-free NoSQL databases most certainly have a place)... In any case, it has been very odd seeing all of the coming-to-senses in the NoSQL space over the past year [2012]." https://dennisforbes.ca/index.php/2012/12/28/but-what-does-that-practically-mean/ |
Given a database problem, what would it look like in different db/language contexts, e.g. SQL, ORM, key store, Redis...
What kinds of query are hard to do or expensive to compute in different use cases?
The text was updated successfully, but these errors were encountered: