Any Relational database Management System requires a query language, according with Dr. Codd's 5th rule; however Codd did not explicitly state that SQL should be the query tool, he just said that there should be a tool. The first database products to emerge on the market had their own tools ( Oracle had UFI, Ingres had QUEL and DB1 had a language called sequel ). Even when the vendors eventually all started offering SQL the flavors were all radically different and contained different or at least varying syntax. This situation was somewhat resolved in the late 80\'s when ANSI brought out their first definition of the SQL syntax. This brings us to the standard.
Same as with databases or database models, there is an unanimous view about what SQL is and what its role and future is; the shortest definition to the best of our knowledge sounds like this : "SQL is a standardized query language for requesting information from a database ", adapted from Kauffman .
The first company to release a product based on a relational model was Relational Software and they named their product Oracle. In the same time IBM, where Dr. Codd and Chris Date were employees at that time, was preparing their System R product which was released couple of years after Relational Software's Oracle. What is important to note is that Date's  version of the relational model is the simplest and closest to the "usual file model" of data. He is a strong and declared opponent of the ANSI/ISO SQL standardization efforts, arguing with the loss of purity as a result of the process.
In , Dr. Codd's opinion is even more drastic, his conclusion being that no existing DBMS product , to the best of his knowledge, can claim to be fully relational. The proposed standard does not fully comply with the relational model, because it is based heavily on that nucleus of SQL that is supported in common by numerous vendors.
SQL has became a standard due to the ANSI-SQL group's work. ANSI is The American National Standards Institute which is an organization that coordinates and acts as a mediator and supervisor of the work of task groups like ANSI-SQL. The standardization process is important in the context of our subject for the portability of SQL code and applications.
Three releases of the "pure" ANSI-SQL standard exist :
o SQL89 (SQL1)
o SQL92 (SQL2)
o SQL99 (SQL3)
Each new release has came up due to the advanced features that appeared in the field, but nevertheless the basic operations and the core of the language remained the same. The debates in the programmers and software vendors community start here after. The reason is very simple : every DBMS vendor wants to add some new, extra features that most of them are not comprised by the standard. It results that when porting applications from one system to another, incompatibilities appear that need a lot of extra maintenance work, sometimes more than if it were to start from scratch. A solution to this problem is proposed by Hugh Darwen in , and is very simple: to use "only and nothing more" than the set of feature of a relational database management software that complies with the ANSI-SQL standard. Without getting into details, we give a short and suggestive example : some vendors, in order to differentiate their product have added features like auto-incremented fields, even though this is not contained in the pure standard.
For the purpose of our project we will use a Microsoft solution, namely Microsoft SQL Server 2005 as the DBMS. Argumentation in favor of this choice is presented in the subsequent subchapters and is based on the integration of this product with another Microsoft product, Visual Studio 2005. Returning to the issue of standardization, we'll adopt the a strategy of using mostly only those parts of Microsoft SQL Server's that are common with the standard.