Hybrid Relational Development Mixing Relational Development with Java or c# In addition to pure relational applications the Relational Framework supports hybrid relational and OO development using a hybrid model that affords both faster development and better convenience than contemporary attempts to link SQL directly into an OO language such as Microsoft's LINQ (Language Integrated Query) for .net. The advantages in faster development are illustrated with the following excerpt from a large Pilot study of a hybrid Relational and .net (c#/VB) Enterprise application wherein the Relational Framework was used to rapidly render a relational "user control" to the .net environment that replaced multiple server side .net controls that could not provide the desired design functionality (they broke due to unexposed code being controlled by wizards): "We had a large enterprise app with a deadline to meet and the Relational Framework delivered. Many pieces and pages of the application were built completely in SQL and the Hybrid mode with .net was literally amazing, particularly when compared to LINQ." "We needed to develop the custom widget control shown on the right, but no combination of binding the repeater to checkboxlist and checkbox controls could do it because the controls were not equally granular and since we needed to drill into the [TD] tag on the generated HTML to make the widget meet the design spec this was a problem. The solution was to write a Relational user control that provided the widget functionality we needed and exposed itself to the .net environment for interoperability as shown. This stands out as something we could never do with Microsoft's LINQ - you can query a language intrinsic such as an array, but It doesn't let you expand or replace the existing .net user controls and server controls. That's heads and shoulders more useful - the Relational Framework turbo-charges development cycles like nothing else." - Enterprise Pilot, Project Manager Compared to Microsoft's LINQ implementation: True hybrid development should extend functionality in both directions; from the perspective of rapidly extending or replacing server side user controls and classes with relational classes as illustrated in the previous example, hybrid development via Microsoft LINQ model falls short; where LINQ shines is it's ability to directly query OO constructs but it's defects are numerous and most notably entail unnecessary learning curves and awkward English: LINQ requires that developers learn a new non-standard and awkward dialect of SQL. It then engages a set of engines to translate this new dialect back into real SQL so that SQL Server can understand it! Let's take a closer look at the new "SQL-like" (as Microsoft phrases it) dialect being introduced with LINQ: It essentially appears to be a Reverse Polish Notation style SQL; RPN is a mathematical notation wherein the operators follow the operands; "5 + ((1 + 2) * 4) - 3" becomes "5 1 2 + 4 * + 3 -" . Similarly, "Select Category, Name from Orders where quantity = 3" becomes something like "From Orders where quantity == 3 select Category, Name" in the SQL-like dialect of LINQ. The basic problem most apparent here is that SQL is close to English - SQL actually stands for Structured English Query Language thus while Microsoft's LINQ "SQL-Like" or "RPN like" may be accurate, in practice and usage it appears effectively like broken English which can only have a limiting effect on optimal SQL Development. Developers don't need to struggle writing awkward broken English SQL that is then translated back into proper syntax when they view the trace output; the discontinuity from this mismatch alone adds considerable development time to any complex application. LINQ's requirement that this "broken-English SQL" implementation be learned has been widely criticized as tying to the development environment, proponents point to bells and whistles such as the ability to select the field names using "auto-text" as a virtue and reason for the broken syntax; because the table and relation names appear first the .net development environment can provide drop-down auto-text lists that allow the field names to be selected supposedly saving time. In practice this notion is easily disproven. Take a closer look at the illustrations depicting the Schema Spider Development Environment; a developer is writing SQL (real SQL, not broken English SQL) and with a single click they are more easily dragging and dropping chunks of fieldnames from the source tables into their code than they could with "auto-text". Note that this functionality is not specific to the development environment shown; a similar design could allow this just as easily in Visual Studio without the need to tie in an awkward and proprietary "SQL like" dialect; breaking the SQL language to support "auto-text" for field selection is not required.