The Java Index

My biggest problem with #NoSQL. Check out this argument against relational datastores. This is the primary argument for #NoSQL "...and this is really why we’re looking at #NoSQL today" . The argument for nosql is simply this. That it's computationally expensive to denormalize your data model for the view, and he argues that the only reason to normalize data is storage space optimization. Here's the problem with this argument. You shouldn't be denormalizing your data model for the view in the first place. If used correctly, normalized, relational data stores are not only easy on your storage, but they are easy on your network i/o, and they are easy on the eyes.  This is because, if used correctly, the view is only requesting the data that it actually needs to draw the view, and the view is only drawing the data that a user is actually reviewing or mutating at a given point in time. #sql #coding #architecture #dynamodb

One item I'd love to hear called out in this video is the difference between domain specific libraries, and generic, structural support or "framework" libraries (e.g. #Spring , #Hibernate  ..etc )  Often these framework libraries have large dependency trees and require extensive configuration and numerous component or bean definitions within an application container.  Very Frequently, domain specific modules built on top of these #frameworks will require slightly different or even extremely different configuration stacks. This is utterly impossible to support in a " #Megalith ". The number of configurations and beans that you'd need to duplicate, re-configure and namespace isolate from other conflicting configs would be too immense and would change dramatically with each library version update.  This I think is one of the greatest benefits of a #microservice  #architecture. #coding #microservices #soa #java #martinfowler