-1

I am building a User Service. User would be able to register with emailId or phone no. Upon successful registration, they can choose a username (which should be unique)

It is easy to do on SQL datastores where I will create a unique index on emailID and userName.

But because of scale reasons let's say I am not able to choose SQL datastore, How can this use case be modelled on nosql datastores?

Improve this question
1
  • "NoSQL" is as enormous family of things, the is no answer which is true for all of them. How many users do you actually have?
    – Philip Kendall
    Commented Apr 22 at 6:45

1 Answer 1

Reset to default
3

tl;dr summary: The way to model unique composite indices in NoSQL is with … unique composite indices.

How can this use case be modelled on nosql datastores?

It doesn't make sense to talk about "NoSQL data stores". There is no such thing as a "NoSQL data store".

NoSQL stands for Not Only SQL. NoSQL is not a technology. It is an approach how to choose a data storage technology.

The historical background behind NoSQL is that, for a very long time, nobody ever considered how to store their data. If you had to store data, you used a SQL RDBMS. Period. You didn't even stop to think about whether using a SQL RDBMS was the right solution, or even just a good solution. It simply was the only way. You didn't even really choose an RDBMS. If you were a Microsoft shop, you used SQL Server. If you were an IBM shop, you used DB2. Otherwise, you used Oracle. If you were a communist hippie, you used MySQL. Only weirdos even knew how to spell PostgresSQL.

Need to store data? Use a SQL RDBMS.

The idea behind NoSQL was to change that. Instead of blindly reaching for a SQL RDBMS, you first model your data, then choose which data storage technology best fits your data model. Note: that may very well be a SQL RDBMS. NoSQL does not mean "Do not use SQL." NoSQL means "choose the data storage technology which best fits your data model."

Even more importantly: NoSQL does not mean non-relational, as there are relational databases that don't use SQL as their query language. In fact, the term NoSQL was invented in 1998 specifically to describe the Strozzi NoSQL database, a database which is fully relational but uses a query language other than SQL. There are databases which are even more relational than SQL RDBMSs. These databases, too, are "NoSQL"!

In NoSQL, you choose the data storage technology that best fits your data model. Does your data look like a document? Use a document database. Is it a graph? Use a graph database. Is it a collection of values, naturally indexed by keys? Use a key-value database. Are you tracking a series of values over time? Use a time-series database? Does your data have lots of relations (in the mathematical sense of the word)? Then, by all means, an RDBMS is exactly the right choice.

There are two other aspects that are not really a part of NoSQL, but go hand-in-hand:

  • Polyglot databases. This essentially just means using multiple different database technologies in the same system. Have some data that looks like documents and some data that looks like time series? Use a document database and a time series database, and "join" the two at the application layer.

  • Application databases. In the past, the way databases were used, was that there was one database for the entire organization. All data was in that one database. All systems and all applications operated on that one database. This means that databases are incredibly long-lived, they can easily outlive the systems, applications, operating systems, hardware platforms, and programming languages they were originally designed for. That's why proper data modeling, Normal Forms, etc. are so important. That's also why schemas, transactions, etc. are so important: you need to protect the multiple applications and systems from each other. The idea of the application database is the opposite of that: each application has its own database. "Joining" the systems is done using web services. This has another consequence:

    • Migrations. If each application has its own database, then it is easy to upgrade / downgrade the database schema in lockstep with the application. You don't need to design your database schema perfectly the first time because it will live for 40 years. The schema can evolve together with the application. Many applications fully automatically upgrade the schema when you upgrade the application. This would never be possible if the database was shared: you'd break the other application's data model.

These things together mean that it is much easier to choose the right database for the data model, because you can have different databases for different data models.

So, what does that mean for you? It means, look at your data, look at what shape it is, and choose the data storage technology that best fits the shape of the data.

In your case, your data needs a unique composite index, so you choose a data storage technology which has unique composite indices. SQL does have them, so you could choose SQL. But, for example, MongoDB has them, too, so you could choose MongoDB as well.

If your data requires a unique composite index, but your database doesn't have them, that's not NoSQL. That's just doing it wrong.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.