Path: text.usenetserver.com!out03b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!i12g2000prf.googlegroups.com!not-for-mail From: topmind Newsgroups: comp.databases.theory,comp.object Subject: Re: Object-relational impedence Date: Mon, 3 Mar 2008 10:31:12 -0800 (PST) Organization: http://groups.google.com Lines: 136 Message-ID: References: <0cd61579-0f26-422c-9aec-908ffdea59ff@i7g2000prf.googlegroups.com> NNTP-Posting-Host: 66.120.226.1 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1204569072 22759 127.0.0.1 (3 Mar 2008 18:31:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 3 Mar 2008 18:31:12 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i12g2000prf.googlegroups.com; posting-host=66.120.226.1; posting-account=i7APvAkAAABVeLm9m7bOpSoPm4pgZM6r User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: usenetserver.com comp.databases.theory:170238 comp.object:264405 X-Received-Date: Mon, 03 Mar 2008 13:31:13 EST (text.usenetserver.com) JOG wrote: > On Mar 3, 2:07 pm, Thomas Gagne wrote: > > All attempts by applications to access a DB's tables and columns > > directly violates design principles that guard against close-coupling. > > This is a basic design tenet for OO. Violating it when jumping from OO > > to RDB is, I think, the source of problem that are collectively and > > popularly referred to as the object-relational impedance mismatch. > > I wondered if we might be able to come up with some agreement on what > object-relational impedence mismatch actually means. I always thought > the mismatch was centred on the issue that a single object != single > tuple, but it appears there may be more to it than that. > > I was hoping perhaps people might be able to offer perspectives on the > issues that they have encountered. One thing I would like to avoid > (outside of almost flames of course), is the notion that database > technology is merely a persistence layer (do people still actually > think that?) - I wonder if the 'mismatch' stems from such a > perspective. This came up in a nearby message. I borrowed the following text from wikipedia: Key philosophical differences between the OO and relational models can be summarized as follows: Declarative vs. imperative interfaces -- Relational thinking tends to use data as interfaces, not behavior as interfaces. It thus has a declarative tilt in design philosophy in contrast to OO's behavioral tilt. (Some relational proponents propose using triggers, etc. to provide complex behavior, but this is not a common viewpoint.) Schema bound -- Objects do not have to follow a "parent schema" for which attributes or accessors an object has, while table rows must follow the entity's schema. A given row must belong to one and only one entity. The closest thing in OO is inheritance, but it is generally tree-shaped and optional. A dynamic reformulation of relational theory may solve this, but it is not practical yet. Access rules -- In relational databases, attributes are accessed and altered through predefined relational operators, while OO allows each class to create its own state alteration interface and practices. The "self-handling noun" viewpoint of OO gives independence to each object that the relational model does not permit. This is a "standards versus local freedom" debate. OO tends to argue that relational standards limit expressiveness, while relational proponents suggest the rule adherence allows more abstract math-like reasoning, integrity, and design consistency. Relationship between nouns and actions -- OO encourages a tight association between operations (actions) and the nouns (entities) that the operations operate on. The resulting tightly-bound entity containing both nouns and the operations is usually called a class, or in OO analysis, a concept. Relational designs generally do not assume there is anything natural or logical about such tight associations (outside of relational operators). Uniqueness observation -- Row identities (keys) generally have a text- representable form, but objects do not require an externally-viewable unique identifier. Object identity -- Objects (other than immutable ones) are generally considered to have a unique identity; two objects which happen to have the same state at a given point in time are not considered to be identical. Relations, on the other hand has no inherent concept of this kind of identity. That said, it is a common practice to fabricate "identity" for records in a database through use of globally-unique candidate keys; though many consider this a poor practice for any database record which does not have a one-to-one correspondence with a real world entity. (Relational, like objects, can use domain keys if they exist in the external world for identification purposes). Relational systems strive for "permanent" and inspect-able identification techniques, where-as object identification techniques tend to be transient or situational. Normalization -- Relational normalization practices are often ignored by OO designs. However, this may just be a bad habit instead of a native feature of OO. An alternate view is that a collection of objects, interlinked via pointers of some sort, is equivalent to a network database; which in turn can be viewed as an extremely- denormalized relational database. Schema inheritance -- Most relational databases do not support schema inheritance. Although such a feature could be added in theory to reduce the conflict with OOP, relational proponents are less likely to believe in the utility of hierarchical taxonomies and sub-typing because they tend to view set-based taxonomies or classification systems as more powerful and flexible than trees. OO advocates point out that inheritance/subtyping models need not be limited to trees (though this is a limitation in many popular OO languages such as Java), but non-tree OO solutions are seen as more difficult to formulate than set-based variation-on-a-theme management techniques preferred by relational. At the least, they differ from techniques commonly used in relational algebra. Structure vs. behaviour -- OO primarily focuses on ensuring that the structure of the program is reasonable (maintainable, understandable, extensible, reusable, safe), whereas relational systems focus on what kind of behaviour the resulting run-time system has (efficiency, adaptability, fault-tolerance, liveness, logical integrity, etc.). Object-oriented methods generally assume that the primary user of the object-oriented code and its interfaces are the application developers. In relational systems, the end-users' view of the behaviour of the system is sometimes considered to be more important. However, relational queries and "views" are common techniques to re- represent information in application- or task-specific configurations. Further, relational does not prohibit local or application-specific structures or tables from being created, although many common development tools do not directly provide such a feature, assuming objects will be used instead. This makes it difficult to know whether the stated non-developer perspective of relational is inherent to relational, or merely a product of current practice and tool implementation assumptions. As a result of the object-relational impedance mismatch, it is often argued by partisans on both sides of the debate that the other technology ought to be abandoned or reduced in scope. Some database advocates view traditional "procedural" languages as more compatible with a RDBMS than many OO languages; and/or suggest that a less OO- style ought to be used. (In particular, it is argued that long-lived domain objects in application code ought not to exist; any such objects that do exist should be created when a query is made and disposed of when a transaction or task is complete). On the other hand, many OO advocates argue that more OO-friendly persistence mechanisms, such as OODBMS, ought to be developed and used, and that relational technology ought to be phased out. Of course, it should be pointed out that many (if not most) programmers and DBAs do not hold either of these viewpoints; and view the object-relational impedance mismatch as a mere fact of life that Information Technology has to deal with. (end quote) -T-