Hacker News Reader

I would like to rebuttal. If there exists any dynamic application, you need some type of data store to keep all of the records, whether it be a persistent database or simply an in-memory database. So, in my opinion, this is a truthy statement.

View on HN

Something you need isn't necessarily what defines you. We all need food and water but that's not what defines us -- at least not at the level of abstraction people care about. Google has a ton of databases, etc. but one would hardly call it a database company.

If you're architecting your application around a particular mechanism, be that a db or comms mechanism or whatever, then you're tightly coupled to it. This is a mistake.

Most applications need to store data, but most applications dont need to store data in a particular db.

Taking this attitude to your design is a great way to tank your performance before you've even started. I have seen too many projects suffer from overzealous architecture that treats the database as a persistence layer. Designs that start out trying to abstract away the persistence layer wind up building a complex caching layer.

I agree, I'm not arguing for complete abstractions here, just showing that the fact that you can abstract away the differences means that the db is not a "defining" part of the system.

Reply on news.ycombinator.com