>There are two different ways to access data: 'Record oriented' and 'set oriented'. The first databases were record oriented, often called hierarchical databases, meaning that the database is optimized to handle individual records. Its implementation is often depended on the physical storage of records. The set oriented technique is younger and developped by EF codd in the 70's. It is much more concerned about retrieving sets of data from the database and its exposed scheme should be detached from its physical implementation as much as possible,
>

The NoSQL crowd would definately argue with the 2 different ways. I think to [re]define Key-Value storage as 2 col record is wrong.

>This makes me think of all the discussions up here about strict type (.Net) and dynamic typing (VFP). Lets look at SQL again. Though you indeed must specify the types of variables in functions and procedures, there actually is nothing that checks the type other than at runtime, there is nothing preventing you to change the type of a column if there are stored procedures and UDF stored in the database. All conflicts will be detected at runtime, much like in VFP. I wonder how strict typing would benefit software development in SQL, can it be beneficial or is it going to be a PITA.

Vfp and most SQL implementations have strict/conformant types of columns. SQLite claims you can live without even that.

>How simular with using COM objects. Take for example MS office. Though one can use early binding, it binds your program to a specific instance of MS office since the object model and therefor type library of each new version is different in each version. Lets be realistic here, if you develop software that needs to automate MS word, you cannot enforce your client to use a specific version of office. My clients might use office version as old as 10 years and my applications will just work fine. In such situations there is no place for early binding. Late binding is the only alternative in this case. Unfortunately in strict type languages you then will have to workarround the issue that the compiler insist to know the types when accessing anything in the COM object.

proving it is not the only way, only the way using less code (in my book still the better one)