Rich Shepard wrote: > On Mon, 27 Jul 2009, Darren Duncan wrote: >> Object orientation has nothing to do with all this per se, though objects >> can easily be mapped to tuples. > > A related issue is that object orientation is almost always used in the > context of procedural languages (e.g., C++, Python, Ruby) while SQL is _not_ > a procedural language. SQL is a language for working with sets (tables, or > relations).
I think I realized after I said it that I should have stated that last point better. What I meant to say is that ... Object orientation is just syntactic sugar for working with values, types, routines/functions, etc, and OO issues are orthogonal to the relational model of data; you can talk about relations/etc without talking about OO. Also, given that in typical OO languages, an object can represent either an (immutable) value or a (mutable) variable, all of the concepts in the relational model or in SQL can be cleanly represented by objects. Relations (rowsets) and tuples (rows) are *values*, and are fundamentally immutable, same as numbers/etc; they are like having array or hash-map values of a typical programming language. You can give them as arguments to functions, return them from functions, assign them to variables, etc. So SQL tables are essentially variables that hold relation values; when you make a change to a table, you are substituting its previous relation value for a new one, conceptually the same thing as when you change a numeric variable. The relational types and operators can all be implemented in general purpose languages if one wanted to and integrated into a normal program. For example, see http://search.cpan.org/dist/Set-Relation/ where I did just that; note that this is more of a demonstration, and I'm sure any SQL DBMS has it beat for performance. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
