SQL, NoSQL and LINQ
.Net's LINQ lets developers create applications that can be 100% data source/target agnostic. Let's look at how that can work with SQL and NoSQL databases.
One solution is to put the SQL statements in the application codes themselves. Granted there are actually vendor specific flavors of SQL (like T-SQL, PL/SQL, etc.), doing so also binds the application to a specific database vendor.
.Net has a built-in solution called LINQ. Relational database vendors provide support in their clients/drivers for translating LINQ expressions to SQL behind the scenes. If you are using Entity Framework, for example, using LINQ in your application code can help make the application 100% data source/target agnostic. Switching between different database vendors would not necessarily require changes to compiled codes.
As of this writing, there is no standard NoSQL language. Each NoSQL database vendor provides its own "language" that can be used directly in application codes. MongoDB has clients/drivers per platform. Redis, likewise, has several as well.
This is no different than the multi-SQL flavor problem. Using the NoSQL vendor's "language" directly in your application codes also binds the application to a specific NoSQL vendor.
.Net LINQ can save the day! NoSQL database providers usually add support for LINQ to express NoSQL queries. With LINQ, there is a uniform query language in the application. Regardless what NoSQL database vendor is used, the domain codes can remain intact with the same LINQ expressions. Thus, the application can be 100% data source/target agnostic. The application can easily switch between different NoSQL database vendors without necessarily requiring changes to compiled codes.
In fact, a 100% data source/target agnostic application can switch between SQL and NoSQL databases with no problem at all! Everything the application needs is within its domain. The types of data sources/targets don't matter.
Wouldn't it be great if you can create applications that are truly 100% data source/target agnostic? Imagine an application that can be easily deployed to the customer's backend preference. Powered by LINQ, your application will just work without re-compiling. Just configure it to recognize the data sources/targets and you're good to go.
SQL
RDMS databases use SQL to express data storage and retrieval operations. In many ways, using database stored views, functions and procedures that can contain domain logic/rules means that the application is bound to its data sources/targets.One solution is to put the SQL statements in the application codes themselves. Granted there are actually vendor specific flavors of SQL (like T-SQL, PL/SQL, etc.), doing so also binds the application to a specific database vendor.
.Net has a built-in solution called LINQ. Relational database vendors provide support in their clients/drivers for translating LINQ expressions to SQL behind the scenes. If you are using Entity Framework, for example, using LINQ in your application code can help make the application 100% data source/target agnostic. Switching between different database vendors would not necessarily require changes to compiled codes.
NoSQL
NoSQL is a general moniker used to refer to databases that apply technologies other than those used by relational databases. For programmers, this basically means NOT using SQL. Truth of the matter is, NoSQL actually introduces its own "language" to perform storage and retrieval operations.As of this writing, there is no standard NoSQL language. Each NoSQL database vendor provides its own "language" that can be used directly in application codes. MongoDB has clients/drivers per platform. Redis, likewise, has several as well.
This is no different than the multi-SQL flavor problem. Using the NoSQL vendor's "language" directly in your application codes also binds the application to a specific NoSQL vendor.
.Net LINQ can save the day! NoSQL database providers usually add support for LINQ to express NoSQL queries. With LINQ, there is a uniform query language in the application. Regardless what NoSQL database vendor is used, the domain codes can remain intact with the same LINQ expressions. Thus, the application can be 100% data source/target agnostic. The application can easily switch between different NoSQL database vendors without necessarily requiring changes to compiled codes.
In fact, a 100% data source/target agnostic application can switch between SQL and NoSQL databases with no problem at all! Everything the application needs is within its domain. The types of data sources/targets don't matter.
Wouldn't it be great if you can create applications that are truly 100% data source/target agnostic? Imagine an application that can be easily deployed to the customer's backend preference. Powered by LINQ, your application will just work without re-compiling. Just configure it to recognize the data sources/targets and you're good to go.
Comments
Post a Comment