Structured Query Language
Or SQL for short is how many enterprises throughout the world communicate with and derive insights from their databases.
SQL provides a format where data is stored in tables and can be queried from using specific actions inherent to the language.
Structured databases are often called “Relational” databases as analysts are able to combine and query tables and form insights from the relationships between datasets.
For example, to simply find some data, you could use the “SELECT” command in conjunction with other commands to find what you are looking for within the dataset. There are many more commands and together you form queries that can find, edit, remove and create new data. These queries can then be taken and added to applications for BI tools (business intelligence) or even manually used to drill into specifics. Example of the most basic SQL query in the world:
SELECT * FROM TableName WHERE date = ‘today’
What’s useful, is how this structured language can or cannot benefit the organization. Databases are often categorized by type, and while there are many more types of noSQL than SQL, we’ll go over the primary and most popular types of databases utilized.
As time progresses and newer forms of data types and workflows emerged, the necessity for another database emerged.
Ones that weren't so stringent.
Less structured.
Enter noSQL — “Not only SQL!”
While noSQL databases bear the name “no” they actually do support SQL. A better way to think of them is “not only SQL” whenever you read “noSQL.”
One of the newer ways of storing data happens in what are called “Key-Value” pairs eliminating the need to connect tables saving significant memory.
So we call them non-relational. Unstructured.
You can think of the key-values as tags that are associated with the data utilizing keywords and values to correspond to those keywords.
But as always, there are more options.
We also have graph databases, document databases, wide-column and in-memory store. As stated earlier, we’re simply looking for the best database for the situation at hand. I’ll go ahead and make up a situation:
Let’s say we need to create a social map of dependencies between our customers and the products they spend their money on, along with the amount of time spent on our website. I think this is a fine job for a graph database.
As objectives and directives change, so does the type of database required for the job. For a large social network needing to store millions and millions of user profiles, a document type database may be a better option.
How about a few noSQL use cases directly from IBM:
Managing data relationships: Managing the complex aggregation of data and the relationships between these points is typically handled with a graph-based NoSQL database. This includes recommendation engines, knowledge graphs, fraud detection applications, and social networks, where connections are made between people using various data types.
Scaling and large data volumes: E-commerce requires the ability to manage huge spikes in usage, whether it’s for a one-day sale or the holiday shopping season. Key-value databases are frequently used in e-commerce applications because its simple structure is easily scaled up during times of heavy traffic. This agility is valuable to gaming, adtech, and Internet of Things (IoT) applications.
Example from the market leader IBM1
Web applications require significant amounts of memory, so an in-memory type database could be the way to go here.
Ultimately, the organization has to decide which puzzle piece fits where, so I’ll revert to the most common saying in information technology:
It depends!
https://www.ibm.com/topics/nosql-databases