Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Polyglot Persistence: The 'Boring' Relational Option

DZone's Guide to

Polyglot Persistence: The 'Boring' Relational Option

· Database Zone
Free Resource

Whether you work in SQL Server Management Studio or Visual Studio, Redgate tools integrate with your existing infrastructure, enabling you to align DevOps for your applications with DevOps for your SQL Server databases. Discover true Database DevOps, brought to you in partnership with Redgate.

I was chatting with Brian Blignaut last week after the Equal Experts NoSQL event and he made an interesting observation that in this age of Polyglot Persistence we often rule out the relational database.

I think it’s definitely better that we now have many different options for where we store our data – be it as key/value pairs, documents or as a network/graph.

Having these options forces us to think more about how we’re going to read/write data in our application whereas previously our effort was focused around which tables we were going to pull out.

Having said that, I realised I’d fallen into the trap that Brian was referring to when thinking through how we could model the energy plans that users were selecting from a results table.

We wanted to run aggregate queries over the data to work out the most popular plans and suppliers on different days and then across different customer segments.

We represented each user selection as an event, stored as a document in MongoDB which worked fine to start with but queries started to become much slower as the number of documents approached 500,000 or so.

I started thinking about whether we’d be better off storing the data in a different store which was better optimised for the types of queries that we wanted to run.

My initial thought was to use one of the flashier ‘NoSQL’ databases but Ashok pointed out that the use case – slicing/dicing data at a scale (< 1 m rows) where everything would fit on disc - was perfect for something likePostgreSQL.

I realised that he was absolutely right and I think it’s important to remember that in future – when we talk about choosing the appropriate data store for our problem that doesn’t mean we have to rule out the relational database even though it’s probably more fun to use another store.

It’s easier than you think to extend DevOps practices to SQL Server with Redgate tools. Discover how to introduce true Database DevOps, brought to you in partnership with Redgate

Topics:

Published at DZone with permission of Mark Needham, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}