XPost: comp.databases.rdb, comp.databases.revelation, comp.databases.object   
   From: corey@spectrumsoftware.net   
      
   "Alfredo Novoa"  wrote in message   
   news:e4330f45.0312110856.4c0551ac@posting.google.com...   
   > "Corey Brown"  wrote in message   
   news:...   
   >   
   > > > >     Alfredo, why don't you explain to us why you think this answer   
   is   
   > > > > nonsense.   
   > > >   
   > > > Because it is evident for anybody with a grasp on data management.   
   > >   
   > >     This is exactly the type of answer that I would expect from somebody   
   > >     like Bob B. Why must you guys always answer direct questions with   
   > >     inappropriate remarks like this.   
   >   
   > You didn't asked why it is nonsense, you asked why I don't explain   
   > that. I answered appropiately to your direct question.   
      
       Sorry Alfredo, I thought we were both focused on the broader   
       question instead of the getting bogged down in the details.   
      
   >   
   > > If you have the knowledge and the   
   > >     ability to express that knowledge to others, why don't you take a   
   > >     few minutes out to lay down some cold hard facts, instead of just   
   > >     telling us to go educate ourselves?   
   >   
   > Among other things because a few minutes are not enough if you don't   
   > have a clue, but I gave very good bibliography.   
      
       Ok, I can agree on the bibliography part, but let's calm down   
       on the "clueless" part for a little bit. You don't know me from   
       Adam, so please stop making snap judgements about me and   
       the others who post on this forum.   
      
   >   
   > > Why can't you step up to the   
   > >     role of teacher and start explaining why you "think" one technology   
   > >     is better than another?   
   >   
   > I can, but I don't want. To know that is the duty of any professional.   
   > BTW we are talking about models, not about technology.   
      
       Actually, the original poster may NOT have been talking about models but   
       about physical implementations. No one is confusing the two except for   
   you.   
      
   >   
   > >   
   > > >   
   > > > > I am also pretty sure   
   > > > > that ODBM   
   > > > >     systems do use direct pointers to relate objects together.   
   > > >   
   > > > And I am pretty sure that SQL DBMSes use pointers internally.   
   > >   
   > >     So your point about network databases being obsolete and discredited   
   > >     doesn't count here? If using internal pointers is so foul, why   
   doesn't   
   > > it   
   > >     apply to your last statement? I know, I know go educate yourself.   
   >   
   > You don't know the difference between the logical and the physical   
   > levels, you are more ignorant than I thought.   
      
       Yes I do Alfredo, but to date we have not been talking about the   
   differences   
       between physical and logical. We have been talking about physical   
   differences   
       between ODBMS and RDBMS implementations, at least I have, you seem   
       to be reading from a different hymnal.   
      
   >   
   > > > So they are based in a primitive obsolete and discredited approach.   
   > > > That's all.   
   > >   
   > >     So what! There are many many examples of technologies that have   
   > >     been eclipsed by better designs. It doesn't mean that the   
   > >     early designs are not practical or useful anymore.   
   >   
   > If the new approach is better in all situations then the old approach   
   > is not useful anymore.   
      
       I completely disagree. Have you given up the land line in your house   
       just because cell phones are considered better technology? Have you   
       switched from antenna and or cable to satellite because HDTV is   
       available. Will those technologies eventually eclipse older ones, you   
       bet, but not over night.   
      
   >   
   > > > Perhaps in very special circumstances when the flaws of the current   
   > > > SQL DBMSes are more important than the network model inherent flaws,   
   > > > and the flaws of the concrete OODBMS implementations.   
   > >   
   > >     I don't think the circumstances are all that special.   
   >   
   > Because you ignore the fundamentals of the data management field.   
      
       Sorry Alfredo, I don't ignore the fundamentals anymore than you do.   
       But I am fairly grounded in reality though and will continue to choose   
       the right tool to do the job based on the ENTIRE scope of the work.   
      
   >   
   > > And I certainly   
   > > hope   
   > >     that application architects are looking at more than just the flaws   
   > > associated   
   > >     with specific db technologies   
   >   
   > There are many application architects that ignore the funtamentals of   
   > data management.   
      
       See my statement above, but yes I do agree with you on this point.   
       A lot of this boils down to religious beliefs and unfortunately you   
   cannot   
       dispose religion with technological fact.   
      
   >   
   > The implementation flaws are the only reason that could make more   
   > appropiate a tool based on an inferior approach.   
      
       Excellent, now were grounding out. There are implementation flaws   
       in ALL technologies. Those that can see and understand those flaws   
       are not doomed to make the same mistakes over and over again.   
      
   >   
   > The very first implementations of superior technologies are often   
   > worse at practice than the older products.   
      
       Agreed.   
      
   >   
   > > > Me too, but I try to base my decisions on accurate information.   
   > >   
   > >     Ok, but certainly you're not basing your decisions purely on the   
   > > theoretical   
   > >     disadvantages of an ODBMS over an RDBMS.   
   >   
   > This thread is about a theoretical question: the differences between   
   > the relational and the OO approaches, but it seems you don't   
   > distinguish very well between model and implementation.   
      
       There you go again. We weren't talking about models to begin with.   
       Ok, maybe you were but I was not. So cut me some slack here ok?   
      
   >   
   > > The whole picture of   
   > >     how the application will be used, how much data will be stored, how   
   it   
   > >     will be retrieved, the complexity of the data relationships and the   
   > > environment that   
   > >     the application must work in must also be taken into account.   
   >   
   > The complexity plays against the network approach.   
      
       I believe that the circumstances surrounding the requirements play a   
       major factor in this argument. As an example, several years ago I   
       was responsible for the design and implementation of a modified   
       Dijkstra's algorithm to be used in automatic network restorations   
       of core transport facilities at a large telecom company. The requirement   
       was for us to be able to complelely restore service for the first 100   
       failed T3 lines within 5 seconds of the actual failure. The network   
       was comprised of thousands of nodes with hundreds of thousands   
       of interconnections between them (mesh network). The only way   
       we could meet the requirement, while using a relational database   
       as the underlying data store, was to build out a network representation   
       of the network in memory first. There was just no way to execute   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)