Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: topmind on 2 Jan 2007 16:34 Neo wrote: > > > > ... OO would still basically > > > > be a navigational database not much different than the contraptions > > > > that motivated Dr. Codd to "clean up the town". > > > > Below is a solution based on a network/OO-ish metholdolgy. Could you > > > show how Codd's solution would be cleaner / less navigational > > > especially as new data requirements are added later? > > > We've been over these kinds of things already. I'll let somebody else > > try this time. I remember at least 2 cases where the relational > > equivalent was about the same as your nav version (although we had to > > use vendor-specific SQL in one case, but SQL is not on trial, > > relational is). > > The underlying data structure in the prior examples could be managed > systematically in RM. The "Sibling of Opposite Build" cannot. IIRC, I showed how to represent opposites in schemas about 2 weeks ago. The relational model can represent any graph. Perhaps you are arguing that it is "uglier" in RM? Again, you failed to prove your point on 2 prior query-size challenges. Why should I take you up on a 3rd one? Navigational queries are kind of off-topic anyhow. Plus, you seem to keep focusing on the size issue instead of the consistency issue. Try again in six months, maybe I'll feel like joining another query-size battle then :-) -T-
From: Neo on 2 Jan 2007 17:49 > > The underlying data structure in the prior examples could be managed > > systematically in RM. The "Sibling of Opposite Build" cannot. > > IIRC, I showed how to represent opposites in schemas about 2 weeks ago. Neither of the two relational schemas offered were systematic or resilient solutions; no data was entered and no queries were shown. Quote "I will leave the query work to somebody else". > The relational model can represent any graph. True. The data structure underlying the "Sibling of Opposite Build" example isn't a graph. Its a network. The difference should become clearer when one try to formulate the last query.
From: topmind on 2 Jan 2007 18:36 Neo wrote: > > > The underlying data structure in the prior examples could be managed > > > systematically in RM. The "Sibling of Opposite Build" cannot. > > > > IIRC, I showed how to represent opposites in schemas about 2 weeks ago. > > Neither of the two relational schemas offered were systematic or > resilient solutions; no data was entered and no queries were shown. > Quote "I will leave the query work to somebody else". I am not referring to that one. One is the one that would have been shortened via "natural joins" if the vendor's SQL supported it. (You supplied the original SQL, I would note.) In other words, SQL tends to have bloated JOIN's, but that is technically solvable. I don't remember you challenging that when I brought it up. I would note that you got to make up your own query language so are not bound by existing implementations. That is fine by me as long as *both sides* are allowed such. (I have proposed a new relational language called SMEQL, by the way. It would be easier for a DBA or programmer to extend than SQL because it has simpler "atoms".) And the 2nd example one was the "kitchen and fridge" one from roughly a year ago IIRC. I don't remember the details, but the relational query was reworked and comparable in size to your navigational query. > > > The relational model can represent any graph. > > True. The data structure underlying the "Sibling of Opposite Build" > example isn't a graph. Its a network. The difference should become > clearer when one try to formulate the last query. Well, maybe, but not today. 2 is enough for now. From my perspective, your quota for calling Wolf is spent for a while. -T-
From: Neo on 2 Jan 2007 20:14 > > Neither of the two relational schemas offered were systematic or > > resilient solutions; no data was entered and no queries were shown. > > Quote "I will leave the query work to somebody else". > > I am not referring to that one. One is the one that would have been > shortened via "natural joins" if the vendor's SQL supported it. (You > supplied the original SQL, I would note.) In other words, SQL tends to > have bloated JOIN's, but that is technically solvable. I don't remember > you challenging that when I brought it up There was no reason to challenge there because RM can systematically manage the "Find Siblings" example. The "original SQL" was provided by a cdt member in response to that example. Below are the approx equivalent queries based on approx equivalent underlying data structures. (!= (and (get person instance *) (get (get * child john) child *)) john) SELECT P2.* FROM ((person INNER JOIN link ON person.ID = link.childID) INNER JOIN link AS link2 ON link.parentID = link2.parentID) INNER JOIN person AS P2 ON link2.childID = P2.ID WHERE (((P2.name)<>"John") AND ((person.name)="John") The above comparision was provided in response to your comment "Navigational query languages were proposed. They were ugly because navigational is ugly." > And the 2nd example one was the "kitchen and fridge" one from roughly a > year ago IIRC. I don't remember the details, but the relational query > was reworked and comparable in size to your navigational query. Below is a link to that thread starting near message 291. http://groups.google.com/group/comp.object/browse_frm/thread/4bd174aa28832f6c/78e7ae20bcfb4288?lnk=gst&q=Neo+Topmind+fridge&rnum=1#78e7ae20bcfb4288 While that example can also be handled systematically in RM and the two queries appear similar, the queries are based on substantially different underlying structures. In the network/OO-ish implementation, not only can items in the house form an infinite depth hierarchy (ie house\floor\kitchen\fridge\2ndShelf\eggCarton\egg\yolk etc), each item can contain things of various types and each item can 0 to many classifications, attributes and values; where as the RM solution is based on a simpler and fixed hierarchy (ie T_House, T_Room and T_Funiture) where each level can only contain things of one type. By specifying additional data, I can show that the original OO/Network-ish solution/query is more general and resilient compared to the RM solution/query. (& (get single-family instance *) (get * has (& (get bedroom instance *) (get * has (& (get carpet instance *) (get * color purple))))) (get * has (& (get kitchen instance *) (get * has (& (get fridge instance *) (get * mfg sears)))))) SELECT * FROM houses WHERE houseType="single family" AND houseID in (SELECT houseID FROM rooms WHERE carpetColor="purple") AND houseID in (SELECT houseID FROM furniture WHERE furnitureType="fridge" AND brand="Sears") Would you be willing expand on this example? Lets start with something simple. For example, if we add a room with carpet of multiple colors, the original OO/Network-ish query is unaffected. How can one handle this situation in the RM solution?
From: topmind on 3 Jan 2007 11:55
Neo wrote: > > > Neither of the two relational schemas offered were systematic or > > > resilient solutions; no data was entered and no queries were shown. > > > Quote "I will leave the query work to somebody else". > > > > I am not referring to that one. One is the one that would have been > > shortened via "natural joins" if the vendor's SQL supported it. (You > > supplied the original SQL, I would note.) In other words, SQL tends to > > have bloated JOIN's, but that is technically solvable. I don't remember > > you challenging that when I brought it up > > There was no reason to challenge there because RM can systematically > manage the "Find Siblings" example. The "original SQL" was provided by > a cdt member in response to that example. Below are the approx > equivalent queries based on approx equivalent underlying data > structures. > > (!= (and (get person instance *) > (get (get * child john) child *)) > john) > > SELECT P2.* > FROM ((person INNER JOIN link ON person.ID = link.childID) > INNER JOIN link AS link2 ON link.parentID = link2.parentID) > INNER JOIN person AS P2 ON link2.childID = P2.ID > WHERE (((P2.name)<>"John") > AND ((person.name)="John") > > The above comparision was provided in response to your comment > "Navigational query languages were proposed. They were ugly because > navigational is ugly." I made some subsequent comments about "natural joins" and similar techniques to simplify the joining code (default joins don't have to be explicitly stated), key-words versus symbols when counting "size", and excess parenthesis. My comments still stand. -T- |