It has taken me a good part of last one year or so to come up with Cach� database models which attempt to mirror the real world structures. 1) Pure Object data structures have it disadvantges. Some sprinkling of relational concepts become necessary. 2) It has been primarily paper and pencil work. Then build such structures in Cach� and test them, without any modeling tools.. 3) The concerns were a) SQL access to data. b) Hierarchies play an important role in the real world. As a result, one of the concerns to eliminate recursive queries to get ancestors or descendents (no matter how high or deep the hierarchy).
Regards Sukesh Hoogan Ram�n Jim�nez <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Herman :) > > > Nothing can beat a whiteboard even if your using it on your own. > > Indeed. But I forgot to mention a specific case where tools are actually > quite valuable: reverse engineering of complex, existing code ;) > > >>I just feel that modern tools are not up to it yet > > > > > > Well, tools such as Rational's Rose or Borland's Together *are* but it takes > > a very long and steep learning curve to use them to full potential and that > > usually only pays off in very large and complex projects. > > I agree with you. Guess I should have said "up to it regarding > usability". I've been using Together recently and find it to be quite > sensible. Poseidon has a very good UI but some other quirks that make it > annoying. The thing is, each tool seems to be quite strong in some areas > and dismally weak in others; there is no consistency across the whole > set of features supported. > > > Also the developments on Model Driven Architectures (MDA) look very > > promising and if you want to go on that road you'll have to use UML tools. > > He, he... MDA. We could start a very interesting argument about this I > guess :) It indeed looks promising but there are still many issues to be > addressed. But you are right, comitting to MDA means committing to one > tool or another. But part of our argument could be whether you really > need UML for that :) > > >>... and jump to code straight ahead. Which > >>is not any good actually. > > > > There are degrees of jumping ;-) and a well prepared jump is something that > > the Agile movement is suggesting as long as you take into account *that* you > > are jumping and be prepared to revise your designs on a regular and > > controlled way. > > Thank you so much for clarifying this. In fact, I have become a big fan > of Agile, as long as it is *not* eXtreme Programming. I prefer the > approach outlined by Cockburn in "Agile Software Development". > > > Another one that might give you some handles is Agile Database Techniques by > > Scott Ambler specially if you come from a relational background. > > Ambler also publishes a monthly columnn in Software Development > (www.sdmagazine.com) where he touches on many Agile issues, from > development to management. In fact his last three articles have been a > series about agile database refactoring, I should also have mentioned > this yesterday. > > > One thing you have to take into account is that you have to be aware what > > you are modeling just data or a complete application. Because Cache is both > > a database *and* an application server mixing the two is a very common error > > that people make. At least in the beginning try to seperate your data and > > application designs. > > Indeed - this is common. If you put too much logic into entity classes, > they become bloated and the systems using them would be too coupled to > them as well. The other extreme is having very "thin" entity classes > which barely do anything (the real extreme in this sense is to have > classes only to query them via SQL!) A good division of responsibilities > between a set of core domain classes and families of > application-specific classes seems to be the best way to develop large > systems of systems. > > Matthew - you'll probably have noticed by now that Herman is one of > those persons I mentioned from which much can be learned :) > > Ram�n
