SQL
in [OOP]
|
From: Dmitry A. Kazakov on 3 Feb 2006 05:02 On 2 Feb 2006 17:13:49 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> That's up to you, but there is no any viable alternative. The point is that >> the relational model is a particular case of more general typed model. Then >> you aren't sincere. In SQL you are using types like integers, strings and >> some others. If you didn't believe in them, then you should have replaced >> them all with relations. Note that mathematically it is quite possible. Now >> the question, why didn't you? > > Related discussion: > > http://c2.com/cgi/wiki?DoesRelationalRequireTypes > > The "expression engine" can be logically seperated from a relational > engine it appears to me. As long as the expression engine supports > equality comparisons (less than, equal, etc.), This is a definition of a class: the set of types, each of them has "<", "=". Further one might wish "<" to be order relation and "=" be equality relation. You can argue that all objects should be of this type, but this is mathematically unsound. For example, tables themselves, as objects, aren't ordered. Complex numbers aren't ordered, etc. There also might be incomparable objects. > then relational can > operate on it. (And possibly only just equal or not equal are needed. > Need more pondering on this.) You need order for sorting, otherwise everything will become O(n). > Thus, if somebody wanted to include imaginary numbers in a relational > query language, in theory they could without busting relational. It > demands very little of the underlying expression model. Thank you for explaining why ADT is so great! (:-)) You are right, with ADT one just need to implement the interface of a thing-that-can-be-in-a-relational-table and here it is, the engine works! >>> If I was forced to be an OO'er, I would probably take Smalltalk >>> or Python over Java or Eiffle. >> >> They all are typed, as well as SQL. It is impossible to have a truly >> untyped language. You might reduce it to a very narrow or singleton set of >> types, but not further. There could only be well and poorly typed >> languages. > > Well, this gets into a sticky issue of a definiton of types. Let me > just put it this way: "a reduction of a reliance on types to model the > domain". In other words, the language may have a few native "types" > (functions, arrays, variables) to serve as the building blocks. > However, one does not add new "types" to model the domain in such > languages, rather using other approaches instead (schemas, functions, > etc.). How else, you can extend the DB for dealing with something new without changing the engine? You probably meant not new types, but new classes, new interfaces additional to a thing-that-can-be-in-a-relational-table. But I don't see why this should be any advantage. Note that even for things you can put in a table, it makes a lot of sense to refine interfaces to have: integer-number-in-a-table with specific operations to sum a column, and string-in-a-table, and so on. >> Between what an what? Again, with one table type you have >> >> X."Attribute" or (X."A1" and X."A2" and X."A3" ...) >> >> >> instead of >> >> X.Attribute or (X.A1 and X.A2 and X,A3 ...) >> >> See what is different? > > Indirection? The only difference is "A1" (a run-time object of the type String) vs. A1 (statically known name, not an object, not a type, nothing). The first can be trivially typed as SQL does. There are two types: String and Table. The second requires sets of types to be handled in a generic way. To bring it back to the language. OO offers you both. SQL can only the first. When you criticize OO, you refer to the second, which in the most of languages does not allow any kind of generic programming, because A1 is just a name. But OO does not force you to do so. Moreover OOA/D requires you to carefully consider whether it is really just A1, the singleton, or there is a set of values A1, A2, ..., you have to factor out. If somebody ignores good advises, then it isn't a problem with OO. >> It is up to you to map things to types or to objects. There is no best >> choice. In each concrete case the software designer shall reconsider it >> anew. > > Well, if everything you are considering is an attribute, then you will > have a kind of database anyhow, just a navigational one in your case. > But that is not usually what is done, so it is only a speculative > situation. Relational model is just a view. It might be formally correct, but inappropriate for technical reasons, or because it just appears unnatural for humans (like relational representation of graphs.) OO model offers a choice which IMO by no means excludes relational model. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 3 Feb 2006 05:06 On 2 Feb 2006 08:20:39 -0800, Daniel Parker wrote: > Dmitry A. Kazakov wrote: >> On 31 Jan 2006 19:36:38 -0800, topmind wrote: >> >> The difference is between one type and multiple types. Relational model >> deals with *one* class: table. > > Note that Chris Date and Hugh Darwin have written about this subject at > length, and show that the types of attributes ("columns") may be ADT's > with specializations without breaking the relational calculus in any > way. Yes of course. I didn't say "type", but "class" for this very reason. >> OO tries to handle more than one class. >> Consider tables of types instead of tables of objects, and we'll see if >> that will be any simpler. > > Keep in mind the goal of relational theory, and more generally, the > theory of monoids, which is to define algrebras that are closed over > types, e.g., an operation over a set of values of type T always returns > a value of type T. In your table of typed objects, how would you > define an algebra? Over what would it be closed? Over a set of types. More detailed it could be as follows: 1. There is a countable set of base types 2. There is a countable set of types derived from them 3. For each T of above there is a class rooted in it. That is the set of all types derived from including the root type itself. The closure of this class is again a type, denoted as T'Class. Its values are polymorphic objects. Now, we take union of Ti U Ti'Class and define all operations on Cartesian product: f : T1 x T2 x ... x T1'Class x T2'Class x ... -> T1 x T2 x ... x T1'Class x T2'Class x ... This algebra is obviously closed. [You might want to multiply each Ti and Ti'Class to have dyadic, ternary etc operations as well.] ----------------------- A more interesting question is how to make classes types. The above is closed because the algebra of types is closed (here not objects as in your question, but types themselves.) So the operations producing types are: 1. Subtyping (inheritance, references, views [constraints, immutability etc]) 2. Aggregation (records, arrays) 3. Class-closure (polymorphism) But the class as a set of derived types is not there. Only its closure is. I don't know if one could make it a proper type. It seems that many dynamically typed languages are trying to do something like this, but I have doubts about their consistency. ----------------------- I fully agree that there is no any firm foundations of typed systems, we find modern programming languages. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Mark Nicholls on 3 Feb 2006 06:01 > I fully agree that there is no any firm foundations of typed systems, we > find modern programming languages. > really none? or not just one?
From: Dmitry A. Kazakov on 3 Feb 2006 07:44 On 3 Feb 2006 03:01:25 -0800, Mark Nicholls wrote: >> I fully agree that there is no any firm foundations of typed systems, we >> find modern programming languages. >> > > really > > none? or not just one? If the basis of your house is broken in two, I would say it has none... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Mark Nicholls on 3 Feb 2006 08:32
Dmitry A. Kazakov wrote: > On 3 Feb 2006 03:01:25 -0800, Mark Nicholls wrote: > > >> I fully agree that there is no any firm foundations of typed systems, we > >> find modern programming languages. > >> > > > > really > > > > none? or not just one? > > If the basis of your house is broken in two, I would say it has none... > (:-)) > if the two are consistent then we have at least one. if the two are inconsistent then we have a schism. if one is informal and the other is formal....I choose formality. |