Question

I’m building a record store shop application and was wondering if I should go the NoSQL way or SQL way. I can technically use an off thyself cart. But I never really liked how carts behaved for music type stores…

The model is something to the likes of…

Release(Title, Price, EP, LP, Main Artist, Description)
Track(Title, Price, Main Artist, Remix Artist)

Very basic structure and I could add the rest of the fields but you get the point…

Answer 1

There are a large number of factors which could push the decision either way.

A few of the questions I would be asking myself about my data at the outset are:

How big is my data likely to grow? Should the database hold only what is in stock or all possible available titles on the market? I am assuming your database will have many more tables than the two you mention.

Possible answer: By choosing a NoSQL structure at the outset you may thank yourself for it later having provided the scope for good scalability.

How complex is my data? Is there potential for multivalued columns?

If for example you have an artists table, you may want this table to have a release column where the multivalued realease ID’s for that artist are stored for easy cross reference to your releases table. In this case a NoSQL type database such as the multivalue database may be interesting as you can avoid performance damaging joins. As your data grows the data retrieval speed could be better than going the SQL route.

Depending on which SQL database you would select, there is also the cost aspect to look at as well.

If you do go the NoSQL route, then the flexibility this route offers needs to be backed up with a good initial data design from the outset, so that the flexibility does not become your enemy later down the line.

Hope that helps.