Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Dmitry A. Kazakov on 28 Jan 2007 11:23 On 28 Jan 2007 06:04:24 -0800, frebe73(a)gmail.com wrote: > Why don't you show the limitations with relations as data structures? Come on! It was shown on numerous occasions. I can repeat just one example: Nearest neighbour search ----------------------------------- Given: S, a metric space of dimension k>1; V={vi} a finite set of vectors from S. Objective: represent V in a way that it were possible to design the function f:S->V, such that forall i |x-f(x)|<=|x-vi|. Requirement: complexity of f must be better than O(n). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe73 on 28 Jan 2007 11:38 > > Why don't you show the limitations with relations as data structures? > Come on! It was shown on numerous occasions. I can repeat just one example: > > Nearest neighbour search > ----------------------------------- > > Given: S, a metric space of dimension k>1; V={vi} a finite set of vectors > from S. > > Objective: represent V in a way that it were possible to design the > function f:S->V, such that forall i |x-f(x)|<=|x-vi|. > > Requirement: complexity of f must be better than O(n). What data do you want me to model as relations? A point in space, a vector? Points in space may easily be modelled by a relation with k attributes. point(x, y, z) A vector may be modelled with a relation with one attribute for the position and one attribute for the value. myvector(1, A) myvector(2, B) ..... Fredrik Bertilsson http://mybase.sf.net
From: frebe73 on 28 Jan 2007 12:41 > >> If you are seriously (and without providing any supporting > >> argument, I note) asserting that database relations are the only > >> data structure that should ever be used, our views on software > >> development are too different to support constructive interaction. > > > Why don't you show the limitations with relations as data > > structures? > Why don't you defend your claim that relations are the only data > structure that should ever be used? The most common data structures used in current programming languages are lists and maps, so I think we can limit ourself to these structures. It is easy to show the benefits with relations to lists and maps. If you for example want to find all elements using a some critera (except from the map key), you need to traverse all elements. Another advantage with relations is joins. This is not possible with lists/map. I think I will bore the other readers with explaining for you why relations are more powerful and high-level than lists/maps, so I will stop here. But I can recommend you to google for "relational algrebra" and you might get better understanding. Because lists and map are more low-level they do also have performance benefits. In some scenarios (but not often in business applications), performance might force you to use them. Because most of the current mechanisms providing some sort of relational algrebra are running in a separate process from the rest of the application, there might be perfomance problems when making heavy use of relational algebra. The best solution for this problem is to use stored procedures to avoid the inter-process communication. Using low-level data structures on the application side is a bad idea for solving this problem. > Your claim is equivalent to > asserting that all of the experienced software developers using other > data structures to deliver real business value every day are ignorant > or foolish. It was possible to make working applications in the pre-relational era too. And it is still possible to don't use relations or use them in a limited way, and still make sucessfull applications. But obviously, there are no lack of ignorant software developers. > Do you really think that only you have seen the light? No, have a look at comp.databases.theory or look at the LAMP- architecture. > Isn't it just possible that other data structures exist for very good > reasons? They are needed to implement relational databases, and they are needed in other low-level software. > >> What are you doing on comp.object, anyway? > > > I entered this thread because Robert Martin was giving harmful > > advices about how to use a SQL database. > Actually, he was giving the benefit of his experience in > combining OO and relational models to deliver quality software. If you want to know how to combining OO and relational models, you should read something by Chris Date instead. > > Why are you guys givining advices on SQL development at comp.object, > > anyway? Why don't you just stick to OODBMS? > The only people here who limit themselves to a single approach > are the relational one trick ponies. The rest of us want as many > tools in our toolbox as possible. OO people claim that OO can be used for everything. So why don't you use a OODBMS? What are the benefits with SQL databases that makes you to use them instead? Relational people claim that relational algebra could be used for data management. Classes are useful for defining datatypes. Functions are useful for defining functionallity, etc, etc. Relational algebra is not a universal tool. Fredrik Bertilsson http://mybase.sf.net
From: Dmitry A. Kazakov on 28 Jan 2007 12:44 On 28 Jan 2007 08:38:23 -0800, frebe73(a)gmail.com wrote: >>> Why don't you show the limitations with relations as data structures? >> Come on! It was shown on numerous occasions. I can repeat just one example: >> >> Nearest neighbour search >> ----------------------------------- >> >> Given: S, a metric space of dimension k>1; V={vi} a finite set of vectors >> from S. >> >> Objective: represent V in a way that it were possible to design the >> function f:S->V, such that forall i |x-f(x)|<=|x-vi|. >> >> Requirement: complexity of f must be better than O(n). > > What data do you want me to model as relations? A point in space, a > vector? (they are same) > Points in space may easily be modelled by a relation with k > attributes. > point(x, y, z) Yes, this is what I want. Now show me f. You can take Euclidean distance d(r,t) = sqrt ((rx-tx)^2 + (ry-ty)^2 + (rz-tz)^2) Consider the following data set: x y z ------------- 1 2 10 10 3 20 3 3 5 0 0 0 9 2 99 For this set, f(0,0,90) shall yield (9,2,99). Remember the requirement - the complexity of f must be better than O(n), where n is the cardinality of the data set. In the example provided, n=5. [This problem has a huge application field, from gaming and machine vision to data mining.] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 28 Jan 2007 15:12
Dmitry A. Kazakov wrote: > On 28 Jan 2007 06:04:24 -0800, frebe73(a)gmail.com wrote: > > > Why don't you show the limitations with relations as data structures? > > Come on! It was shown on numerous occasions. I can repeat just one example: > > Nearest neighbour search > ----------------------------------- > > Given: S, a metric space of dimension k>1; V={vi} a finite set of vectors > from S. > > Objective: represent V in a way that it were possible to design the > function f:S->V, such that forall i |x-f(x)|<=|x-vi|. > > Requirement: complexity of f must be better than O(n). I debunked this already, at least from a theoretical point of view. In short, relational does NOT prevent domain-specific operations from being defined. SQL as implemented may not allow such, but you need to be careful about pointing out limits of relational versus limits of SQL. I will agree that SQL in existing RDBMS may limit such. But, SQL is not the pinnacle of relational. For further reading, see about 5/8ths down into: http://www.c2.com/cgi/wiki?DoesRelationalRequireTypes As far as claiming that "relational is the only structure one would ever need", I don't think relational fans do that any more than OO fans. Did Robert Martin put a limit on where OO is good and where it is not in his book? If he is not obgligated to declare the scope, why should we? Relational is pretty good for the vast majority of biz apps that I've encountered. I tend to limit my discussions to biz apps and thus don't discuss relational's abilities outside of that. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T- |