8 ms·

An interesting article. I'm glad to see someone giving an equal treatment of SQL and NoSQL databases for a change. I appreciate the analogy of SQL being an opti

by Zeimyth 10y ago

An interesting article. I'm glad to see someone giving an equal treatment of SQL and NoSQL databases for a change. I appreciate the analogy of SQL being an optimized and general-purpose high-level language and NoSQL being a more powerful but specialized low-level or assembly language. However, I feel like the article fundamentally fails to address the core question of "When should I pick NoSQL over SQL?" If SQL is indeed the choice 99 times out of 100, how can you know when you are faced with that 1-in-100 time when NoSQL is actually the right option?

PeCaN 10y ago
> If SQL is indeed the choice 99 times out of 100, how can you know when you are faced with that 1-in-100 time when NoSQL is actually the right option? If you have to ask yourself “Should I use SQL or NoSQL?” then you should use SQL. If you have to use NoSQL, you won't have to ask yourself. Usually it's pretty obvious when you will not use joins at all.
devuo 10y ago
It's really "not" that complicated. Start by assuming by default that you will use an RDBMS, then: 1) Attempt to model a database schema that fully and completely supports said data. This will force you to get a sufficiently deep understanding of the domain problem and how it's different parts relate to one another. 2) Is there a part of the domain problem whose dynamic or unstructured nature cannot be properly represented on a fixed database schema and/or this unstructured piece of data must be performantly queried? Add a "companion" Document DB to your architecture. 3) Are there performance issues/requirements on a given part of your system and you need to hold volatile data such as a cache of processed data, or you need to efficiently handle user sessions across multiple machines, or even a queuing system for processing tremendous amounts of data coming in? The add a "companion" Key-Value DB to your architecture. ... And many, many other examples of other specialized NoSQL DBs could be added here, but you get the idea. Summing up: Understand the data > Attempt to model an RDBMS schema that supports said data > Use proper "companion" DBs for whatever data that does not fit in a RDBMS.
maxxxxx 10y ago
From my experience it will be pretty obvious at that point.

by Zeimyth 10y ago

PeCaN 10y ago

> If SQL is indeed the choice 99 times out of 100, how can you know when you are faced with that 1-in-100 time when NoSQL is actually the right option? If you have to ask yourself “Should I use SQL or NoSQL?” then you should use SQL. If you have to use NoSQL, you won't have to ask yourself. Usually it's pretty obvious when you will not use joins at all.

devuo 10y ago

It's really "not" that complicated. Start by assuming by default that you will use an RDBMS, then: 1) Attempt to model a database schema that fully and completely supports said data. This will force you to get a sufficiently deep understanding of the domain problem and how it's different parts relate to one another. 2) Is there a part of the domain problem whose dynamic or unstructured nature cannot be properly represented on a fixed database schema and/or this unstructured piece of data must be performantly queried? Add a "companion" Document DB to your architecture. 3) Are there performance issues/requirements on a given part of your system and you need to hold volatile data such as a cache of processed data, or you need to efficiently handle user sessions across multiple machines, or even a queuing system for processing tremendous amounts of data coming in? The add a "companion" Key-Value DB to your architecture. ... And many, many other examples of other specialized NoSQL DBs could be added here, but you get the idea. Summing up: Understand the data > Attempt to model an RDBMS schema that supports said data > Use proper "companion" DBs for whatever data that does not fit in a RDBMS.

maxxxxx 10y ago

From my experience it will be pretty obvious at that point.