too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: frebe on 6 Jan 2008 10:01 > > Who proved that the model is inherently ineffeicient in the given > > scenario? > > Proof: Let S be an unordered set. q.e.d. Sure... > >> If you believe that RA is the > >> best model for everything, then try to use it for integer arithmetic. > > > select 1+1 from dual > > I don't see how this implements "+". A relational implementation of a+1 > could be: > > table Sequence_Relation is (Predecessor : unique; Successor); > select Successor from Sequence_Relation where Predecessor = a; Relations are relations between values. A value belongs to a domain. Operators and functions operating on different domains, can be used in relational calculus. What is the problem? > Now do a+b, a*b, a!... I am sure you can figure those out too. > Or maybe you want to try you luck with: > table Natural is (First_Digit; Second_Digit; Third_Digit; ...); Your approach is valid, but you also need a domain for the values, and there doesn't need to exist a relation with rows for every valid value in a domain. //frebe
From: Dmitry A. Kazakov on 6 Jan 2008 11:21 On Sun, 6 Jan 2008 07:01:39 -0800 (PST), frebe wrote: >> I don't see how this implements "+". A relational implementation of a+1 >> could be: >> >> table Sequence_Relation is (Predecessor : unique; Successor); >> select Successor from Sequence_Relation where Predecessor = a; > > Relations are relations between values. A value belongs to a domain. > Operators and functions operating on different domains, can be used in > relational calculus. What is the problem? > >> Now do a+b, a*b, a!... > > I am sure you can figure those out too. Nope, you need a power set operation to handle that, and even then algorithmic complexity will be just catastrophic. This is why no ALU ever used relational approach in its design. The point stands, even for ordered sets, relational may turn bad. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 6 Jan 2008 11:20 On Sun, 6 Jan 2008 06:48:07 -0800 (PST), frebe wrote: >> On Sun, 6 Jan 2008 05:19:04 -0800 (PST), frebe wrote: >>> What makes you think that the relational model can't model hierachies? >> >> Because it has disastrous O(m x log n) for path navigation. Hierarchies >> are more complex than flat relations. > > Now you are making assumptions about the physical layer that are not > necessarly true. A SQL database implementation may very well using > pointers between records. How can I know it? What part of my 100% relational program ensures existence of these mythical pointers? Once you add an ability to spell their existence in the program, that will immediately make the language non-relational. This makes the whole point of insufficiency of RA. Yes, you can flight a car to the Moon, just put it in a spaceship... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 6 Jan 2008 12:49 > >> I don't see how this implements "+". A relational implementation of a+1 > >> could be: > > >> table Sequence_Relation is (Predecessor : unique; Successor); > >> select Successor from Sequence_Relation where Predecessor = a; > > > Relations are relations between values. A value belongs to a domain. > > Operators and functions operating on different domains, can be used in > > relational calculus. What is the problem? > > >> Now do a+b, a*b, a!... > > > I am sure you can figure those out too. > > Nope, you need a power set operation to handle that, and even then > algorithmic complexity will be just catastrophic. This is why no ALU ever > used relational approach in its design. > > The point stands, even for ordered sets, relational may turn bad. And as said before, relational calculus can use any operator on any domain (type). I am not sure what you are trying to claim here. That an expression like a*b can't be used in relational calculus? //frebe
From: frebe on 6 Jan 2008 13:00
> >>> What makes you think that the relational model can't model hierachies? > > >> Because it has disastrous O(m x log n) for path navigation. Hierarchies > >> are more complex than flat relations. > > > Now you are making assumptions about the physical layer that are not > > necessarly true. A SQL database implementation may very well using > > pointers between records. > > How can I know it? What part of my 100% relational program ensures > existence of these mythical pointers? Once you add an ability to spell > their existence in the program, that will immediately make the language > non-relational. This makes the whole point of insufficiency of RA. How can I know that select * from customer where city='Berlin' will perform in O(n) or O(log n). The answer is: You can't without also knowing about the indexes. Not having to hard-wire the execution plan in your application source code is a major benefit with relational databases. This is called "Physical data independence". But your point seem to be that since you can't tell the complexity from the source code, the model is flawed? //frebe |