Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Can Oracle save a tree?

Re: Can Oracle save a tree?

From: Jim Kennedy <>
Date: Thu, 29 Apr 2004 03:40:18 GMT
Message-ID: <BO_jc.10340$Rd4.847614@attbi_s51>

"Noons" <> wrote in message
> (Ramon F Herrera) wrote in message
> Tough? You ain't seen nothing yet...
> Mind you this is advice, although it may sound like criticism.
> > Well, in this particular application (and in general) one could argue
> > that if you design the interfaces properly, it doesn't matter the
> > order or simultaneity between the 2 aspects above.
> No, one could NEVER argue that. You simply CANNOT design and code
> an application that manipulates data without first analysing the
> relationships of that same data. The simple fact that you needed
> to ask a question about how to store the data in Oracle proves that
> you don't have the foggiest idea how to store that data in a database.
> Because you spent no time at all designing the data model. Which means
> you have not spent anytime figuring out how to store your data out of
> main memory. A typical situation in modern so-called "design".
> > This protocol is simple and standard enough. When you need to fill
> > the tree/forest at the GU level, the Oracle/web server will send you
> > something like this:
> Excuse me: "the Oracle/web server"???? Are you sure we're all talking
> about one and the same thing?
> > Midwest 3 1
> > Illinois 3 1 2
> > Chicago 3 1 2 1
> > Sears_Tower_Store 3 1 2 1 7
> > New_England 4 1
> > Vermont 4 1 3
> > That's the _only_ agreement necessary between the client and the server
> > and therefore it doesn't matter whether I resort to a traditional
> > (i.e., relational) storage or the more flexible objects.
> Really? Explain two things:
> 1- How are objects more flexible, given that you have no idea
> how to store them? And please do NOT say "serialize", say "store":
> that is the proper name. Renaming something obvious to make it obscure
> achieves nothing.
> 2- Since when is there such a thing as an "agreement" between a
> client application and a database server? What you need is a
> definition of what data you have in the client, what you data have in
> the server, and how one maps to another. There is no such thing as
> an "agreement": this is not politics, this is IT and data engineering.
> > Two programmers incomunicado from each other could do the project,
> > an Oracle DBA and a GUI type of guy.
> And end up like you with no idea how to store the data offline...
> In IT this problem was solved 40 years ago. Apparently it's back.
> Your reply to Nial on how some companies might not have a state
> and district "hardwired into a table name" is typical of this state
> of affairs. Nowhere did Nial imply that the name of the table
> had ANYTHING to do with the data. It doesn't, it never did.
> You store AVAILABLE districts and AVAILABLE states in tables,
> THEN you link them to the appropriate company using foreign keys.
> Drag and drop all you may care, the above is what you MUST do.
> If you want to change a bunch of companies to another one, you
> drag and drop the companies to wherever you want them (GU stuff) AND
> you link them to the appropriate owner. This happens WITH or
> WITHOUT objects and is ALWAYS done. Assuming of course you're
> talking about the state and district. If you're talking about
> ownership of the company, then the situation is completely
> different, the state/district stuff is totally irrelevant
> and I don't even understand why it was called into here.
> On a general note:
> Don't try to tell me that objects can somehow "magically" be dragged
> around and they know who belongs to what: there is no such thing.
> Objects are as EXACTLY as dumb as you make their methods. They do nothing
> unless there is a method to tell them what to do, inherited or not
> is immaterial.
> You MUST have a method associated to the object class to get the object
> instance to do anything. That method also must change the data
> relationships if you plan to store all that jazz in a database. Otherwise
> you have no way whatsoever of knowing later on when you load the data back
> to memory, what was where and how.
> Assuming of course that you believe data must be stored offline.
> If you are of the belief that data should always live in memory and
> all else are "implementation details", then quite frankly we're done.
> Cheers
> Nuno Souto

I agree. I think part of the problem is getting all caught up in what it should look like on the screen and not what the relationships are. Sometimes we need to step back and say what is the data model? How do these things relate to one another? Data modeling is about creating a model of the real situation. Sometimes that is not an easy thing to do, but one must press on.
Jim Received on Wed Apr 28 2004 - 22:40:18 CDT

Original text of this message