The SQL Server Management Studio became a standalone product that has a separate release cycle from the SQL Server itself. I think this is a good direction, as the SSMS can be developed now in much faster pace and meet the demand for features more timely.
The data usage patterns have changed dramatically in last ten years or so, and various organizations are interested in 'hidden' relationships between data - ones that were not initially recognized or planned for the database. This is when the graph databases may be used.
When you approach new project, you are often tasked with design of the data structures that will support the application. The data structures should allow for the required functionality and they should follow some principles of the data modeling, like normalization, proper data types etc. How do you approach such tasks? Thinking in categories of tables is not always the best approach. Tables look like business entities, but not always. How do you model relationships between tables? Thomas Frisendal wrote a very interesting article about data modeling. One of the less clear stages in data model design is the architecture of entity relationships. Database professionals tend to either bypass the relationship names, or name them after the end point table names....
The article focuses on these two database technologies, but in fact it can be extended to the whole realms of RDBMS and NoSQL databases. Certain aspects of both domains can be considered as advantages or disadvantages, depending on the point of view and particular business case. The flexibility of schema in MongoDB is appealing to teams who implement applications dealing with unstructured data. The strictness of schema definition required by relational databases can be beneficial when the application needs to ensure that the data quality meets certain requirements.