On 3/29/07, Jochen Theodorou <blackdrag / uni.de> wrote: > Austin Ziegler schrieb: > [...] > > Please, please, *please* read more about relational theory before you > > make statements like this, because it's technical nonsense. There *is* > > no "object model." > of course there is none as you define it. Who said I am using the same > definition? Is your definition a common definition for "model" in > general? If so please point me to a reference. I don't know all the > correct UK/US terms used for this. Like I said, "model" is a vague word. When you say "relational model", the *meaning* is the "Relational Model of Data" (e.g., the theory). At this point, there's nothing related for an "Object Model of Data". When one says "object model", one usually means "the hierarchy or graph of objects that I am using to represent the data and operations in my implementation." In relational terms, that is a schema. So, "relational model" and "object model" are two *totally* different things as they are typically understood as one deals with a concept and the other deals with a single implementation. > > That's an important point, too: > > object orientation is about *programming*. It is not about data and > > the storage of data. > I agree partially. It is a data structure, it is not more about > programming as a binary tree is. So it is about structuring your data to > fit your needs of computation... but that fits so much that is a useless > statement The classic definition of an object is data and the operations that apply to that data encapsulated in one. I am sure that there are definitions of OO out there where encapsulation isn't part of it, but I consider encapsulation probably the defining feature of OO (even more than inheritance, because there are strong arguments for composition instead). That's a whole different argument, though, and most OO systems these days accept encapsulation, inheritance, polymorphism, and (often) access control (information hiding). > > 2. When *implementing* something, you will model the data. This can be > > your data model that can be extended into an object model for > > programming purposes. These "models" are better considered "schema"; > > they describe the layout of the data. > What you want to say is, that a schema is no model? Or at last not all > schemata are models. I think.. I am not sure yet ;) Just the opposite. An object model is closely related to a data model (or a database schema, if you prefer). There's no overarching theory of object modelling (at least not yet, as Ed pointed out), whereas there *is* an overarching theory of data and relations. > > Just because one *can* create something that works without a > > mathematical theory behind it does not mean that one *should* do so. > or should not do so. Fair enough, but if one chooses to step away from something that has theoretical underpinnings, one should at least be prepared to make a coherent explanation as to why it's better. Otherwise, you're not doing much better than selling snake oil. I'm sure you've seen programs by vendors that claim to have better-than-AES encryption available that absolutely no one in the security industry has reviewed. Why do we as technical people scoff at them yet swallow the claims of other vendors (like the OODB or "Post-Relational" folks) without even thinking? > > One > > certainly shouldn't claim that the thing without a mathematical theory > > behind it is superior to the thing with -- because that's something you > > should be able to demonstrate with, well, another theory. Performance > > metrics are not evidence of superiority of concept; just of > > implementation. > I have never done that. So I guess you don't mean me, because I am well > aware of the problems of OODBs I wasn't referring to you specifically; I was more referring to the OODB vendors, who have no excuse for their specious claims. > >> And of course you can apply the theories of that area for that part of > >> the implementation. > >> Why not consider OODB mathematics as part of graph theory and others? > > There are no OODB mathematics, and that's part of the point that I've > > been trying to make. > ah, yes, ok. > > If you can point to OODB mathematics papers and > > theories, I'll retract or clarify that statement, but I have a > > reasonably high level of confidence that object orientation isn't > > expressed in terms of mathematics or theory the way that the relational > > model is. > ok, see "A Query Algebra for Object-Oriented Databases (1989)" on > citeseer http://citeseer.ist.psu.edu/shaw89query.html I skimmed through this; reading it, it's an attempt to *return* some level of relational algebra to object databases ... all the way back in 1989. Sadly, the authors still think that first normal form is an unnecessary restriction on the logical formation of the data -- and they have to synthesize first normal form tuples to obtain relational algebra capabilities in object databases. I haven't looked further, but it's not quite a positive refutation of my statement. > > Sure, an object store can be set up to allow for smart loading and such, > > but that *doesn't* mean that it's a good idea. It might be the "right > > now" idea, but it is something you'll have to pay the piper for using at > > some point in the future. > depends on my goals, or not? I've said as much. Right now solutions usually meet one's immediate goals, but rarely meet long-term goals and often result in increased costs in the long-term. -austin -- Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/ * austin / halostatue.ca * http://www.halostatue.ca/feed/ * austin / zieglers.ca