I will concede that ACID transactions have started making their way into a variety of NoSQL implementations more recently. Transactions, transactions! My kingdom for transactions! Which brings me to the main feature of relational databases, which I only give up when I have to: ACID transactions. They do so without an appreciation for just how those supposed improvements in performance and scalability are achieved,Īnd inevitably attempt to engineer poorer versions of some features of relational databases on top of NoSQL stores. Somehow magically make you more performant and scalable. Relational database can give you, citing them as being too slow or cumbersome, in favour of a data store that will What I have seen over the last decade, however, is a tendency by developers to easily discount everything that a But come on, how hard is that to implement really? You can do all that yourself in theĪpplication layer with some hooks on your entities.Īll sarcasm aside, there are some genuine use cases for which NoSQL databases are a better fit, and times whenĭe-normalizing your data has very real benefits. Yes, you might need to duplicate some data and lose some of the niceties like foreign key constraints,Ĭascading deletes and, so on. You could even embed the related entities entirely. When you think about it, it’s just some embedded foreign keys pointing to some entries elsewhere.Īny key/value store is capable of that. NoSQL databases, in their various incarnations, are perfectly capable of modelling data in a Maybe a Profile, one or more Payment Methods, and so on.Īll this fits quite naturally into a relational model, thereby reducing duplication of data and benefiting quite nicelyįrom things like foreign key constraints ensuring referential integrity and cascaded deletes when a User is removed, It is quite natural to think of a User as having one or more Roles, one or more Access Tokens, Take, for example, the first thing that is typically added to a new system: Authentication and Authorization. It has been my experience that for the majority of use cases a relational model is usually a good fit.
We like certain technologies or frameworks that we have used and continue to use at ☄1North.
#Postgresql like series
This post will cover why that is and is the first in our new ‘Why we like: …’ series in which we will explain why
Seeing how far I can get before I need to change to, or more likely add, a more specialised data store to cover whatever In recent years though, I have developed a preference for starting with PostgreSQL and Throughout my career, I have played around with at least one of each of these and used many of them in production Suffice to say we are spoiled for choice. You have relational databases, graphĭatabases, document databases, in-memory databases, embedded databases, and some others I haven’t mentioned. When it comes to storing data, there is a stupid amount of choice nowadays.
0 kommentar(er)
