Object-relational impedence
JOG
> 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.
Thomas Gagne
> 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.
>
composed of graphs of data and RDBs are two-dimensional.
What defines an account in an RDB may be composed of multiple tables.
An RDB might express multiple account types through multiple tables
where OO may reflect it as multiple classes. Attempts to make RDBs
function as graphs through mapping tools results in disappointing
performance and, in my experience, too much mapping, too much
infrastructure, and too much language/paradigm-specific layers. In
short, way more code, way more maintenance, and way more job-security
for consultants, pundits, and tool providers.
--
Visit <http://blogs.instreamco.com/anything.php> to read
my rants on technology and the finance industry. Visit
<http://tggagne.blogspot.com/> for politics, society and culture.
Roy Hann
news:7vqdnf21dLOnrVHa...@wideopenwest.com...
> JOG wrote:
>> 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.
>>
> The issue as I've discovered it has to do with the fact OO systems are
> composed of graphs of data and RDBs are two-dimensional.
RDBs are not two-dimensional, they are n-dimensional. You are confusing the
picture of the thing with the thing. I have a three dimensional kitchen
table. I have an RDB table with three columns (dimensions) called length,
width and height that describes it.
> What defines an account in an RDB may be composed of multiple tables.
> An RDB might express multiple account types through multiple tables
> where OO may reflect it as multiple classes. Attempts to make RDBs
> function as graphs through mapping tools results in disappointing
> performance and, in my experience, too much mapping, too much
> infrastructure, and too much language/paradigm-specific layers. In
> short, way more code, way more maintenance, and way more job-security
> for consultants, pundits, and tool providers.
I completely, 100% agree with that. Code is evil.
Roy
Roy Hann
news:0cd61579-0f26-422c...@i7g2000prf.googlegroups.com...
Are you kidding?!! You will grow old and die before you find someone not on
c.d.t. who DOESN'T think that. In the real world you will be thought some
kind of simpleton/troll/nutcase if you suggest it isn't just a persistence
layer.
Roy
David Cressey
"Roy Hann" <spec...@processed.almost.meat> wrote in message
news:zpSdnSj5fPTYqVHa...@pipex.net...
> "Thomas Gagne" <tga...@wide-open-west.com> wrote in message
> news:7vqdnf21dLOnrVHa...@wideopenwest.com...
> > JOG wrote:
> >> 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.
> >>
> > The issue as I've discovered it has to do with the fact OO systems are
> > composed of graphs of data and RDBs are two-dimensional.
>
> RDBs are not two-dimensional, they are n-dimensional. You are confusing
the
> picture of the thing with the thing. I have a three dimensional kitchen
> table. I have an RDB table with three columns (dimensions) called length,
> width and height that describes it.
Stop! You're both right!
There is a certain level of abstraction where and RDB is definitely
n-dimensional. This is the level of abstraction where I spend most of my
time thinking. So I tend to agree with you, Roy.
There is, however, a different level of abstraction where an RDB is
two-dimensional. So Tom is not "wrong" all the way. And it may be at that
level of abstraction where the OO RM impedance match comes about.
> I completely, 100% agree with that. Code is evil.
>
It appears, from reading c.o., that OO people regard data structures as
evil.
It sounds like Stalinists versus Trotskyites to me!
Bob Badour
It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.
S Perryman
> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> 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.
Apart from issues such as "joins" etc, there actually isn't a mismatch
between OO and Relational at the fundamental level IMHO.
> I was hoping perhaps people might be able to offer perspectives on the
> issues that they have encountered.
Given some entity E = (p1,p2, ... pn) , where p1 etc are the properties of
E, OO allows the following :
1. the properties of E could be realised as data values or a computational
process
2. in any system, there may be multiple existing implementations for E
(each instance of E created using any one of those implementations)
An RDB that requires all properties are data values will not satisfy 1.
An RDB that allows 1, but forces one universal implementation for E will
not satisfy 2.
For OO, the big problem is the prog langs themselves.
Syntax, semantics, implementation.
Assuming there is an RDB that can do 1 and 2 above, how can a specific
OO prog lang 'align' its representation of objects to the 'tuple' form that
will allow an underlying Relational engine to work its wonders (execution,
optimisation etc) ??
Regards,
Steven Perryman
Roy Hann
news:SGWyj.2671$4D2.1906@trndny06...
> There is, however, a different level of abstraction where an RDB is
> two-dimensional.
There is? Are you thinking of report writers and GUI painters?
> So Tom is not "wrong" all the way. And it may be at that
> level of abstraction where the OO RM impedance match comes about.
>> I completely, 100% agree with that. Code is evil.
>>
> It appears, from reading c.o., that OO people regard data structures as
> evil.
>
> It sounds like Stalinists versus Trotskyites to me!
Until I know their reasons for their views on data structures I couldn't
say. However I notice that I am surrounded by programmers who consume most
the development budget writing code, and when a change request comes along I
can accommodate it in the database in minutes and they spend months spewing
out more code (sometimes after doing an extensive and expensive impact
assessment). Code may not be evil, but it sure has a case to answer.
Roy
Thomas Gagne
>
>
> Until I know their reasons for their views on data structures I couldn't
> say. However I notice that I am surrounded by programmers who consume most
> the development budget writing code, and when a change request comes along I
> can accommodate it in the database in minutes and they spend months spewing
> out more code (sometimes after doing an extensive and expensive impact
> assessment). Code may not be evil, but it sure has a case to answer.
>
(loosely-coupled) between applications and databases.
TroyK
>
> - Show quoted text -
Very well put. I'm filing this away in my brain for future reference.
TroyK
wrote:
> "David Cressey" <cresse...@verizon.net> wrote in message
My experience is somewhere between 2 and 3 orders of magnitude
difference between implementing a business rules change in the db vs.
the programming team doing it in OO code.
topmind
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-
Bob Badour
> "Roy Hann" <spec...@processed.almost.meat> wrote in message
> news:zpSdnSj5fPTYqVHa...@pipex.net...
>
>>"Thomas Gagne" <tga...@wide-open-west.com> wrote in message
>>news:7vqdnf21dLOnrVHa...@wideopenwest.com...
>>
>>>JOG wrote:
>>>
>>>>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.
>>>>
>>>
>>>The issue as I've discovered it has to do with the fact OO systems are
>>>composed of graphs of data and RDBs are two-dimensional.
>>
>>RDBs are not two-dimensional, they are n-dimensional. You are confusing
>
> the
>
>>picture of the thing with the thing. I have a three dimensional kitchen
>>table. I have an RDB table with three columns (dimensions) called length,
>>width and height that describes it.
>
> Stop! You're both right!
>
> There is a certain level of abstraction where and RDB is definitely
> n-dimensional. This is the level of abstraction where I spend most of my
> time thinking. So I tend to agree with you, Roy.
>
> There is, however, a different level of abstraction where an RDB is
> two-dimensional. So Tom is not "wrong" all the way. And it may be at that
> level of abstraction where the OO RM impedance match comes about.
David, the flaw in your logic is: At the level of abstraction where an
RDB is two-dimensional, OO is uni-dimensional.
topmind
As the girls say, "It depends on how you use it".
It depends on how you use the DB. In Robert Martin's version of the
payroll application, the DB is almost reduced to a dumb filing system
("persistence layer") because the app code does all the work. However,
in my version:
http://www.geocities.com/tablizer/payroll2.htm
I *leveraged* the DB so that much if not most of the work is done by
the database and queries *instead* of the app code. There's more
attribute setup work, but noticeably less app code than Martin's. One
"programs" largely by putting attributes in tables instead of writing
app code.
One can choose to use the features available from RDBMS, or they can
choose to manually program it in app code. Your perspective on what
DB's are "for" largely depends on which route you take.
-T-
Dmitry A. Kazakov
> "Roy Hann" <spec...@processed.almost.meat> wrote in message
> news:zpSdnSj5fPTYqVHa...@pipex.net...
>> I completely, 100% agree with that. Code is evil.
>
> It appears, from reading c.o., that OO people regard data structures as
> evil.
Right, the structure of data would be too low-level to be able to capture
behavior. As in mathematics, in OO the internal structure of objects is
irrelevant and when considered, then only as an implementation detail to be
abstracted away. OO deals with the structures of sets of objects exposing
same behavior and relations between such sets.
> It sounds like Stalinists versus Trotskyites to me!
Huh, both regarded themselves as true Leninists. No, by this analogy c.d.t.
wanted to impose Leninism on us, others who consider Leninism just a silly
amateur philosophy, though very wicked when tried in practice. You know the
examples, the Gulag, SQL... (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Bob Badour
> JOG wrote:
>
>>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> 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:
The text had too many blatant errors to start enumerating them all. The
problem with wikipedia is any ignorant fool can just start typing
nonsense. Even when one follows the requirements for references to
primary sources, the quality of the end product can vary over many
orders of magnitude.
JOG
wrote:
> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
> >news:zpSdnSj5fPTYqVHa...@pipex.net...
> >> I completely, 100% agree with that. Code is evil.
>
> > It appears, from reading c.o., that OO people regard data structures as
> > evil.
>
> Right, the structure of data would be too low-level to be able to capture
> behavior. As in mathematics, in OO the internal structure of objects is
> irrelevant and when considered, then only as an implementation detail to be
> abstracted away. OO deals with the structures of sets of objects exposing
> same behavior and relations between such sets.
>
> > It sounds like Stalinists versus Trotskyites to me!
>
> Huh, both regarded themselves as true Leninists. No, by this analogy c.d.t.
> wanted to impose Leninism on us, others who consider Leninism just a silly
> amateur philosophy, though very wicked when tried in practice. You know the
> examples, the Gulag, SQL... (:-))
If you'd please, I was hoping for reasonable discussion, not
flamebait.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
JOG
And yet wikipedia entries are often remarkably half-decent. However
not in this case - the entry is a convloluted mess, and actually
instigated my question.(I often wonder if it would not be better if
opposing views on wikipedia could be treated as separate articles
rather than the standard mish mash).
Dmitry A. Kazakov
> JOG wrote:
>> 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.
>>
> The issue as I've discovered it has to do with the fact OO systems are
> composed of graphs of data and RDBs are two-dimensional.
> What defines an account in an RDB may be composed of multiple tables.
> An RDB might express multiple account types through multiple tables
> where OO may reflect it as multiple classes. Attempts to make RDBs
> function as graphs through mapping tools results in disappointing
> performance and, in my experience, too much mapping, too much
> infrastructure, and too much language/paradigm-specific layers. In
> short, way more code, way more maintenance, and way more job-security
> for consultants, pundits, and tool providers.
Certainly RDBs are n-dimensional.
The difference is not there. If you wanted to consider the space [of
objects], then the difference would be in its the structure and the
distance defined there.
RA assumes existence of such space and tries to *abstract* any distance
away. Clearly any implementation would introduce a distance and that will
have a huge impact on the performance of the DB. This includes also the
mental pictures of the DB "performing" in the heads of people programming
it. Negative/positive impacts do not necessarily correlate, which does not
make things any better.
OO clusters the space into isolated multidimensional planes and *publishes*
the distances and orders there. This allows a far better modeling of the
problems which space differ from one described by RA. This also includes
larger problems which can be described by RA but cannot be modeled by it
due to hardware limitations (finiteness etc).
Disclaimer: "a real FORTRAN program" can be written in any language under
any paradigm etc.
topmind
Dmitry A. Kazakov wrote:
> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
>
> > "Roy Hann" <spec...@processed.almost.meat> wrote in message
> > news:zpSdnSj5fPTYqVHa...@pipex.net...
>
> >> I completely, 100% agree with that. Code is evil.
> >
> > It appears, from reading c.o., that OO people regard data structures as
> > evil.
>
> Right, the structure of data would be too low-level to be able to capture
> behavior. As in mathematics, in OO the internal structure of objects is
> irrelevant and when considered, then only as an implementation detail to be
> abstracted away. OO deals with the structures of sets of objects exposing
> same behavior and relations between such sets.
This is misleading. An association between object A and object B does
NOT go away just because it is managed via accessors. OOP not only
doesn't get one away from dealing with things as "structures", but
uses structures that were discredited in late 60's.
Hiding behind accessors is merely a shell game. setMess and getMess is
*still* a mess.
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
Phlip
It's an "impedance mismatch".
And it's not. OO and declarative, relational, etc. are just "orthogonal". That's
a Good Thing.
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
>>
>>> "Roy Hann" <spec...@processed.almost.meat> wrote in message
>>> news:zpSdnSj5fPTYqVHa...@pipex.net...
>>
>>>> I completely, 100% agree with that. Code is evil.
>>>
>>> It appears, from reading c.o., that OO people regard data structures as
>>> evil.
>>
>> Right, the structure of data would be too low-level to be able to capture
>> behavior. As in mathematics, in OO the internal structure of objects is
>> irrelevant and when considered, then only as an implementation detail to be
>> abstracted away. OO deals with the structures of sets of objects exposing
>> same behavior and relations between such sets.
>
> This is misleading. An association between object A and object B does
> NOT go away just because it is managed via accessors.
Associations are not managed via links. There are no strings tying the
numbers 1 (object A) and 2 (object B).
But I guess you probably meant a data structure called "linked list".
Please note: _data structure_. Watch out, you fall into heresy, dear
topmind!
> OOP not only
> doesn't get one away from dealing with things as "structures", but
> uses structures that were discredited in late 60's.
How can anybody discredit a data structure? Recently I was taught by our
c.d.t. colleges that data are recorded facts. You didn't object them. So,
may I humble ask you, who and how could discredit facts? (outside Usenet
discussion forums, I mean... (:-))
--
Robert Martin
> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> 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.
There is indeed more to it than that. OO and RDB are both strategies
for partitioning data. However, the motivation behind the partitioning
is completely different. OO partitions data based on the way a
particular application will process that data. RDBs partition data
based on how many different applications will need to access that data.
This really isn't an impedance mismatch. It's a mismatch of intent.
When designers use each strategy for what it's good at, there is no
mismatch at all.
> 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.
Take out the word "merely", and recognize that "persistence" is more
than just storage.
--
Robert C. Martin (Uncle Bob)Â Â | email: uncl...@objectmentor.com
Object Mentor Inc.       | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716Â Â Â Â Â Â Â Â Â Â |
topmind
wrote:
> On Mon, 3 Mar 2008 11:44:07 -0800 (PST), topmind wrote:
> > Dmitry A. Kazakov wrote:
> >> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
>
> >>>news:zpSdnSj5fPTYqVHa...@pipex.net...
>
> >>>> I completely, 100% agree with that. Code is evil.
>
> >>> It appears, from reading c.o., that OO people regard data structures as
> >>> evil.
>
> >> Right, the structure of data would be too low-level to be able to capture
> >> behavior. As in mathematics, in OO the internal structure of objects is
> >> irrelevant and when considered, then only as an implementation detail to be
> >> abstracted away. OO deals with the structures of sets of objects exposing
> >> same behavior and relations between such sets.
>
> > This is misleading. An association between object A and object B does
> > NOT go away just because it is managed via accessors.
>
> Associations are not managed via links. There are no strings tying the
> numbers 1 (object A) and 2 (object B).
>
> But I guess you probably meant a data structure called "linked list".
> Please note: _data structure_. Watch out, you fall into heresy, dear
> topmind!
I did not say that *all* objects have associations between them. In
practice, there are a lot of associations between objects. In memory
these become a graph of object pointers. Even in UML, relationship
diagrams are common. If all that could be magically encapsulated under
the carpet so that nobody had to worry about them, then why have
relationship diagrams? If one doesn't focus on such, then duplication
(among other problems) slips in.
>
> > OOP not only
> > doesn't get one away from dealing with things as "structures", but
> > uses structures that were discredited in late 60's.
>
> How can anybody discredit a data structure? Recently I was taught by our
> c.d.t. colleges that data are recorded facts. You didn't object them. So,
> may I humble ask you, who and how could discredit facts? (outside Usenet
> discussion forums, I mean... (:-))
Navigational structures are unwieldy on a larger scale for most
mortals. Dr. Codd introduced relational to reign in the chaos of the
pasta machines that were growing around that time. OOP didn't fix the
problems with navigational structures. Putting accessors around them
was not a fix. A developer/designer must still know and manage
relationships between objects.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
-T-
Robert Martin
<spec...@processed.almost.meat> said:
> Code is evil.
SQL is code.
Robert Martin
> There is, however, a different level of abstraction where an RDB is
> two-dimensional. So Tom is not "wrong" all the way. And it may be at that
> level of abstraction where the OO RM impedance match comes about.
I don't know. Computer memory is one-dimensional.
Robert Martin
<spec...@processed.almost.meat> said:
> However I notice that I am surrounded by programmers who consume most
> the development budget writing code, and when a change request comes along I
> can accommodate it in the database in minutes and they spend months spewing
> out more code (sometimes after doing an extensive and expensive impact
> assessment). Code may not be evil, but it sure has a case to answer.
Silly developers and DBAs always have a case to answer. Their tools
are innocent.
BTW, "minutes"? "weeks"? Why didn't you make the change in "minutes"
and demonstrate it while everybody else was still working on the impact
analysis?
topmind
> topmind wrote:
> > JOG wrote:
>
> >>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> 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:
>
> The text had too many blatant errors to start enumerating them all.
Most of them are statements about philosophy or practice rather than
absolutes; thus its hard for them to be objectively or "blatantly"
wrong. Whether that's a good thing or not is another issue. I see the
list as a starting point for discussion even if it does not settle
everything.
It brings up interesting questions, such as why not have schema
inheritance? If inheritance is good or OO, why is it not good for
relational schema's? The answer is that OO and relational approach
things differently.
> The
> problem with wikipedia is any ignorant fool can just start typing
> nonsense. Even when one follows the requirements for references to
> primary sources, the quality of the end product can vary over many
> orders of magnitude.
-T-
Robert Martin
> My experience is somewhere between 2 and 3 orders of magnitude
> difference between implementing a business rules change in the db vs.
> the programming team doing it in OO code.
Then you should be able to fly rings around the programmers and get
them all fired. Why haven't you?
Ladies and gentlemen, there are certainly tasks that are better suited
to SQL and stored procedures. There are other tasks that are better
suited to general purpose languages. True wisdom comes from knowing
the strengths and weaknesses of both. Good architects build systems
that combine the tools synergistically.
Robert Martin
> It appears, from reading c.o., that OO people regard data structures as
> evil.
Not at all. Data structures are not evil, they just aren't objects.
Objects expose behaviors and hide their data. Data structures expose
their data and have no behavior. So the two are in almost diametric
opposition.
Moreover, software that uses data structures is easy to add new
functions to, but hard to add new data to. On the other hand, software
that uses objects is easy to add new objects to but hard to add new
functions to.
These two different affordances are the tools that a good architect
will use to construct systems that are easy to change. The architect
will use data structures in those areas where new functions are likely
to be added, and will use objects in those areas where new data is
likely to be added.
JOG
> On 2008-03-03 10:52:10 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> > On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> 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.
>
> There is indeed more to it than that. OO and RDB are both strategies
> for partitioning data. However, the motivation behind the partitioning
> is completely different. OO partitions data based on the way a
> particular application will process that data.
Is it really as clean cut as that? A single application may be
required to process data in several ways - and some may be initially
unforseen, as requirements (inevitably) may change?
> RDBs partition data
> based on how many different applications will need to access that data.
...or based on the different ways a single application will need to
process the data, no?
>
> This really isn't an impedance mismatch. It's a mismatch of intent.
> When designers use each strategy for what it's good at, there is no
> mismatch at all.
>
> > 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.
>
> Take out the word "merely", and recognize that "persistence" is more
> than just storage.
Perhaps you could expand? I was referring to the fact that databases
do more than 'persist' objects.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
Robert Martin
>> Right, the structure of data would be too low-level to be able to capture
>> behavior. As in mathematics, in OO the internal structure of objects is
>> irrelevant and when considered, then only as an implementation detail to be
>> abstracted away. OO deals with the structures of sets of objects exposing
>> same behavior and relations between such sets.
>
> This is misleading. An association between object A and object B does
> NOT go away just because it is managed via accessors. OOP not only
> doesn't get one away from dealing with things as "structures", but
> uses structures that were discredited in late 60's.
>
> Hiding behind accessors is merely a shell game. setMess and getMess is
> *still* a mess.
Bryce, he wasn't talking about setters and getters.
--
Robert C. Martin (Uncle Bob)Â Â | email: uncl...@objectmentor.com
Robert Martin
<mai...@dmitry-kazakov.de> said:
Bryce is all hot and bothered about the vague similarity between
network databases (which he asserts were discredited even though they
remain the heart of nearly all directory systems and REST hierarchies)
and object graphs.
Bob Badour
Your question presupposes that inheritance is good for OO.
David Cressey
"Roy Hann" <spec...@processed.almost.meat> wrote in message
> Until I know their reasons for their views on data structures I couldn't
> say. However I notice that I am surrounded by programmers who consume
most
> the development budget writing code, and when a change request comes along
I
> can accommodate it in the database in minutes and they spend months
spewing
> out more code (sometimes after doing an extensive and expensive impact
> assessment). Code may not be evil, but it sure has a case to answer.
I have to agree with this comment, based on my own experience.
*However*, my experience, and perhaps yours as well, may be biased towards
cases in business where relatively rich data is subjected to fairly
straightforward transformations. A lot of commercial data processing fits
that description.
Roy Hann
"Robert Martin" <uncl...@objectmentor.com> wrote in message
news:2008030315531543042-unclebob@objectmentorcom...
> On 2008-03-03 11:24:20 -0600, "Roy Hann" <spec...@processed.almost.meat>
> said:
>
>> Code is evil.
>
> SQL is code.
SQL is a botch. It is vile rather than evil. :-)
Roy
David Cressey
"Bob Badour" <bba...@pei.sympatico.ca> wrote in message
news:47cc383f$0$4041$9a56...@news.aliant.net...
> It's pretty obvious to me: object-relational mismatch is to relations as
> assembler-object mismatch is to objects.
I didn't get this comment. Now that someone else has flagged it as a
keeper, I feel the need to ask for an explanation.
David Cressey
That would certainly explain the impedance mismatch!
Roy Hann
> On 2008-03-03 12:08:39 -0600, "Roy Hann" <spec...@processed.almost.meat>
> said:
>
>> However I notice that I am surrounded by programmers who consume most
>> the development budget writing code, and when a change request comes
>> along I
>> can accommodate it in the database in minutes and they spend months
>> spewing
>> out more code (sometimes after doing an extensive and expensive impact
>> assessment). Code may not be evil, but it sure has a case to answer.
>
> Silly developers and DBAs always have a case to answer. Their tools are
> innocent.
I admit I am just being provocative, so I probably deserve a baffling non
sequiter as a response. However you seem to be claiming that code doesn't
routinely take weeks and months to write (which is what I assume you mean
when you say the tools are innocent). That is nonsense, of course.
> BTW, "minutes"? "weeks"? Why didn't you make the change in "minutes" and
> demonstrate it while everybody else was still working on the impact
> analysis?
Well if I had something better than an improvised ad hoc language that has
its roots in the late 1960s and early 1970s, which offers me a collection of
datatypes barely richer than those of FORTRAN IV, I might have done. But as
long as most people think writing procedural code at the speed of human
fingers is all we can reasonably aspire to, I won't be getting anything
better to work with.
Roy
Robert Martin
> It depends on how you use the DB. In Robert Martin's version of the
> payroll application, the DB is almost reduced to a dumb filing system
> ("persistence layer") because the app code does all the work. However,
> in my version:
>
> http://www.geocities.com/tablizer/payroll2.htm
>
> I *leveraged* the DB so that much if not most of the work is done by
> the database and queries *instead* of the app code.
Well, that might be a bit of an exaggeration. Here's just one part of
the code in your example:
<cffunction name="printStubs">
<cfquery name="stubQry" datasource="#dsn#">
SELECT *
FROM payStubs, employees, payItems
WHERE empRef = empID AND payItemRef = payItemID
ORDER BY payDate, empRef, lineNum
</cfquery>
<!--- <cfdump var="#stubQry#"> [for debugging] --->
<h3>Pay Stub Samples</h3>
<cfset shadeClr = "##f0f0f0">
<cfoutput query="stubQry" group="empID"> <!--- outer group by empID --->
<cfset sumPay = 0> <!--- init --->
<hr>
<table border=1 cellpadding=2 cellspacing=0>
<tr>
<td bgcolor="#shadeClr#" width="25%">Name:</td>
<td colspan=3>#stubQry.lastName#, #stubQry.firstName#
#stubQry.middle#</td>
</tr>
<tr>
<td bgcolor="#shadeClr#">Empl. ID:</td>
<td colspan=3>#stubQry.empID#</td>
</tr>
<tr>
<td bgcolor="#shadeClr#">Payroll Date:</td>
<td colspan=3>#stubQry.payDate#</td>
</tr>
<!--- column headings --->
<tr bgcolor="#shadeClr#">
<th colspan=2>Item<br>Description</th>
<th>Reference<br>Value</th>
<th>Pay<br>Amount</th>
</tr>
<!--- for each line item --->
<cfoutput>
<!--- skip line if zero-amount suppression is on --->
<cfif Not (stubQry.displayOptions Contains '(supprzero)'
And stubQry.amount EQ 0.00)>
<tr>
<td colspan=2>#stubQry.lineDescript#</td>
<td align="right">
<cfif stubQry.sumMult is 0>
#stubQry.referenceAmt#
<cfelse>
</cfif>
</td>
<td align="right">
<cfif stubQry.sumMult NEQ 0>
#numberFormat(stubQry.amount,"-9,999,999,999.99")#
<cfelse>
</cfif>
</td>
</tr>
</cfif>
<cfset sumPay = sumPay + stubQry.amount>
</cfoutput>
<!--- Total Line --->
<tr>
<td colspan=3 align="right"><b>Total</b></td>
<td
align="right">#numberFormat(sumPay,"-9,999,999,999.99")#</td>
</tr>
</table>
</cfoutput>
</cffunction>
That's a lot of processing code.
However, I think your point is not completely invalid. You *did* use
more database facilities than I did. Was your code smaller or better?
From the above I would say that it was not better. In the C++ example
from my book "Agile Software Development, Principles, Patterns, and
Practices" you won't see any methods that are even a quarter as long as
what you have there. As for whether it was smaller, it's hard to say
because the two programs don't do very similar things. You used a very
different set of requirements than I did.
Still, your point is valid in that I purposely pulled out any kind of
SQL from my example, and made use of C++ code rather than database
tools -- to the extent that I even did a linear search through all
employees rather than using the database to efficiently query them.
This was done on purpose because the book is an exposition on OO design
principles as opposed to database principles.
You might complain that a book about writing good software *should*
have database concepts mixed in with it. I sympathize, but authors
must make choices, just as you did in your example.
David Cressey
> Ladies and gentlemen, there are certainly tasks that are better suited
> to SQL and stored procedures. There are other tasks that are better
> suited to general purpose languages. True wisdom comes from knowing
> the strengths and weaknesses of both. Good architects build systems
> that combine the tools synergistically.
Agreed. But often the suitability of a given task has less to do with the
language
than it does with the domain of responsibilities of either data managers or
code managers.
Both SQL and C++ are straw men in the sense that there are things that could
be done quite differently if one were to reimplement from scratch, know what
we now know.
I think it's relatively straight forward to extend a language like SQL so
that it becomes a general purpose language. (Whether it becomes a good one
or a bad one is a matter for further discussion). It doesn't seem as
straightforward to me to extend a language like C++ so that it becomes
suitable for declaring relational transformations on data. If it is
straight forward, then I'd like to hear from people who are doing it.
But the idea of a single language that is suitable for everything remains an
elusive goal, and probably an unproductive endeavor.
David Cressey
"Robert Martin"
> Moreover, software that uses data structures is easy to add new
> functions to, but hard to add new data to. On the other hand, software
> that uses objects is easy to add new objects to but hard to add new
> functions to.
>
> These two different affordances are the tools that a good architect
> will use to construct systems that are easy to change. The architect
> will use data structures in those areas where new functions are likely
> to be added, and will use objects in those areas where new data is
> likely to be added.
>
I honestly think the above undervalues data independence. It turns out to
be surprisingly easy to to add new data to a well designed database with
minimal impact on existing programs that access the data. The impact on
programs that provide data is greater, but still quite manageable.
Bob Badour
> "Thomas Gagne" <tga...@wide-open-west.com> wrote in message
> news:7vqdnf21dLOnrVHa...@wideopenwest.com...
>
>>JOG wrote:
>>
>>>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.
>>
>>The issue as I've discovered it has to do with the fact OO systems are
>>composed of graphs of data and RDBs are two-dimensional.
That is a remarkably uninformed and ill-conceived sentence. It's rather
like comparing boats and cars saying boats have hulls and cars are
pretty. Regardless of truth, the comparison is pointless on its face.
One can represent any graph on two-dimensional media just as one can
represent any relation on two-dimensional media. In fact, since a graph
is merely a set of vertices and a set of directed edges and since one
can easily represent vertices and directed edges as tuples, one can
easily represent any graph using relations.
The Great Debate was had about 3 decades ago and graphs lost. Nothing
has happened in the meantime to improve the outcome in the favour of graphs.
> RDBs are not two-dimensional, they are n-dimensional. You are confusing the
> picture of the thing with the thing. I have a three dimensional kitchen
> table. I have an RDB table with three columns (dimensions) called length,
> width and height that describes it.
>
>
>>What defines an account in an RDB may be composed of multiple tables.
>>An RDB might express multiple account types through multiple tables
>>where OO may reflect it as multiple classes. Attempts to make RDBs
>>function as graphs through mapping tools results in disappointing
>>performance and, in my experience, too much mapping, too much
What moron would want to make an RDB function as graphs in the first
place? We have known for 3 decades that graphs, themselves, result in
disappointing performance and too much mapping. After all, every time
one adds a new structural element, the design choices increase
geometrically with no logical justification for choosing among them.
This leads people to discard logical independence and invent physical
reasons. The arbitrary design choices then lead to query bias that
effectively makes large numbers of useful queries prohibitively
expensive to write or to execute.
>>infrastructure, and too much language/paradigm-specific layers. In
>>short, way more code, way more maintenance, and way more job-security
>>for consultants, pundits, and tool providers.
>
> I completely, 100% agree with that. Code is evil.
>
> Roy
JOG
This reminds me of a serious 'click' moment I had with data
structures. A long time ago, in a galaxy far far away, I once sat
blindly reinventing my own network model, with identifiers, pointers,
types, and all the fun of the fair. As an OO programmer it was the
only mindset I had. Then I considered encoding data similar to the
classic example of:
* Aristotle is a man
* All men are mortal
* |= Aristotle is mortal
Well, /clearly/ what I was dealing with here was a generic entity
class, of which Man was a subclass, and Aristotle an instance.
Something like:
class Entity
{
boolean mortal;
string name;
Entity(_name, _mortal) : name(_name), mortal(_mortal);
};
class Man : public Entity
{
date bday;
Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
};
But, as I extended the example, the structures got more convoluted,
and the result more and more of a mess. Finally something clicked. It
wasn't about types, objects or inheritance, it was about /inference/,
and what I actually had was:
Name(x, Aristotle) -> Species(x, Man)
Species(x, Man) -> Mortality(x, Mortal)
|= Name(x, Aristotle) -> Mortalilty(x, Mortal)
No types or reification in sight. Instead I had two groups of
statements:
People = {Name, Species, Bday}
Entities = {Species, Mortality}
A join of the two statements gave me the inference I required: {Name,
Mortality}. All of a sudden it seemed simple. So some questions:
1) So why not treat all 'inheritance' in this way?
2) Could one extend to include 'behaviour' as well?
3) And is this a crazy thing to suggest in a cross post to an OO
group?
Eric
>
> There is indeed more to it than that. OO and RDB are both strategies
> for partitioning data. However, the motivation behind the partitioning
> is completely different. OO partitions data based on the way a
> particular application will process that data. RDBs partition data
> based on how many different applications will need to access that data.
>
No, RDBs partition data so that it is sensibly and easily available to
any possible application. So if you use OO you are saying "there will
never be any other application that will need my data".
E
topmind
Compared to?
>
> However, I think your point is not completely invalid. You *did* use
> more database facilities than I did. Was your code smaller or better?
> From the above I would say that it was not better. In the C++ example
> from my book "Agile Software Development, Principles, Patterns, and
> Practices" you won't see any methods that are even a quarter as long as
> what you have there.
I could have shortened it if I wanted to by splitting it up, but I saw
no need in this case. The size can be shortened without resorting to
OOP. Clarity and shortness of methods/functions are not necessarily
the same thing. Then again, everybody likes things a different way.
Software engineering is largely about psychology, and everybody's
psychology is different. What trips you up may not trip me up, and
vise versa.
But I think anybody inspecting both examples will clearly see that my
version is a lot less total code.
> As for whether it was smaller, it's hard to say
> because the two programs don't do very similar things. You used a very
> different set of requirements than I did.
I satisfied almost everything on your opening list of requirements,
plus allowing more line items to be created without altering existing
code. You talk a lot about adding or changing things without it
impacting lots of code. By not hard-wiring formulas and line-items
into the code, I improved on this metric.
>
> Still, your point is valid in that I purposely pulled out any kind of
> SQL from my example, and made use of C++ code rather than database
> tools -- to the extent that I even did a linear search through all
> employees rather than using the database to efficiently query them.
> This was done on purpose because the book is an exposition on OO design
> principles as opposed to database principles.
>
> You might complain that a book about writing good software *should*
> have database concepts mixed in with it. I sympathize, but authors
> must make choices, just as you did in your example.
If I was writing a formal book on software engineering, I hopefully
would at least point out the pro's and con's of various design
decisions. We both came up with very different designs for solving
essentially the same problem. This is because the implementation
options are wide open.
> --
> Robert C. Martin (Uncle Bob)��| email: uncl...@objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
-T-
topmind
I think you'd like Prolog. And, I think a Prolog-relational merger
would be easier than an OO-Prolog merger.
Bob Badour
>
> Robert Martin wrote:
>
>>On 2008-03-03 12:46:09 -0600, topmind <top...@technologist.com> said:
[snip]
>>You might complain that a book about writing good software *should*
>>have database concepts mixed in with it. I sympathize, but authors
>>must make choices, just as you did in your example.
Oh my god, the idiot is an author?!? For his sake, it's a good thing we
don't have any concept of writing malpractice. He'd be giving a lot of
refunds and spending a lot of time in court.
Bob Badour
What do you know about assembler?
Bob Badour
> "Robert Martin" <uncl...@objectmentor.com> wrote in message
> news:2008030316112582327-unclebob@objectmentorcom...
>
>
>>Ladies and gentlemen, there are certainly tasks that are better suited
>>to SQL and stored procedures. There are other tasks that are better
>>suited to general purpose languages. True wisdom comes from knowing
>>the strengths and weaknesses of both.
Sadly, Robert Martin has demonstrated again and again that he lacks any
wisdom let alone true wisdom.
[snip]
Marshall
> On Mar 3, 9:50 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>
> > There is indeed more to it than that. OO and RDB are both strategies
> > for partitioning data. However, the motivation behind the partitioning
> > is completely different. OO partitions data based on the way a
> > particular application will process that data.
>
> Is it really as clean cut as that?
Boy howdy, no, it's not. For one thing, neither OO nor the RM
are strategies for partitioning data.
One's requirements dictate data with certain functional dependencies.
Among the easiest tasks in application design is one of the earliest:
structuring the data. The RM structures data as relations. Relational
structures lack query bias, which is one of the reasons why SQL
is so good at ad hoc queries (compared to the other choices.)
OO structures mandates an object structure (unsurprisingly): out the
gate, one has no choice but to build in a query bias, whether
one wants it or not.
Furthermore, since OOPLs lack physical independence, traversing
the graph may be quite expensive, particularly in the case where
the graph is backed by storage in a database, which is part of
why ORM is such a universally bad idea. Of course, one can
always build physical independence into one's objects, but
that has to be done manually, one pathway at a time.
> > > 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.
>
> > Take out the word "merely", and recognize that "persistence" is more
> > than just storage.
>
> Perhaps you could expand? I was referring to the fact that databases
> do more than 'persist' objects.
DBMSs don't even necessarily persist at all.
I've said in the past that persistence isn't even a first-tier dbms
feature.
It's a strong second-tier feature, to be sure! But a dbms with no
persistence still has strong use-cases. Which makes it clear enough
that anyone who considers SQL to be about persistence *primarily*
(if not exclusively) hasn't yet identified what the first-tier feature
even *are.*
Marshall
Marshall
>
> I was hoping perhaps people might be able to offer perspectives
> on the issues that they have encountered.
One piece of the puzzle that is often neglected is a qualitative
difference in the type systems of some of the most popular
OOPLs vs. SQL or a hypothetical relational language. This
difference doesn't get a lot of ink in industrial settings but
it's quite important.
C++ and Java and many similar languages are nominally
typed; SQL is structurally typed.
For example, suppose I have two Java classes as follows (toy
example for illustrative purposes):
class Foo { int x; int y; };
class Bar { int x, int y; };
The two classes are different; one cannot use an instance of one
as an instance of the other under any circumstances, not even
with a cast.
In SQL, if I have two relations with x and y int columns, I can
union them, or join on them, or whatever. There is no way,
in fact, to forbid such a thing, just like in Java there is no way
to allow such a thing.
One particular manifestation of this difference is that if one
is writing an ORM for Java, one has to address the issue
that one needs a new class for every distinct column-set
of every query one has. This fact sometimes drives unfortunate
design decisions.
Marshall
Leslie Sanford
I'm jumping in realizing that I may be revealing a bit of ignorance here, so
bear with me.
If I need to send a message to all persons who are mortal, I could join
People and Entities together by species and where Mortality is true?
Once I've performed the join, I then dispatch a message to the resulting
group: "GetAnnualCheckUp()" or something?
In the application I'm currently writing, I have a large list of parameters.
These parameters share some values such as Name and Label. However, there
are different types of parameters such as those that represent a boolean
state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
etc., and other types. My current approach is traditional OO, and that's to
have a hierarchy of Parameter classes. I can then keep a list of
heterogeneous parameters and treat them polymorphically. For example:
params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);
// Set a parameter value. All raw parameter values are in the range
// of [0, 1]. Each parameter class knows how to transform raw parameter
// values in an appropriate way.
params[parameterId].SetValue(value);
And all works well.
I'm trying to wrap my head around how I would approach this problem using
what you've described above. I could have a table representing attributes
common to all parameters. Then tables representing attributes specific to
one parameter type or another. I could relate the tables via foreign keys?
When I need to dispatch parameter changes, I could join the appropriate
tables and change the appropriate values?
I'm open to new ways of approaching things, but the mechanism to implement
all of this needs to be fast, in my case. Parameter changes can come in at
hundreds of times a second.
JOG
wrote:
Aye. Behaviour sits on top.
>
> In the application I'm currently writing, I have a large list of parameters.
> These parameters share some values such as Name and Label. However, there
> are different types of parameters such as those that represent a boolean
> state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
> etc., and other types. My current approach is traditional OO, and that's to
> have a hierarchy of Parameter classes. I can then keep a list of
> heterogeneous parameters and treat them polymorphically. For example:
>
> params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
> params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);
>
> // Set a parameter value. All raw parameter values are in the range
> // of [0, 1]. Each parameter class knows how to transform raw parameter
> // values in an appropriate way.
> params[parameterId].SetValue(value);
>
> And all works well.
If it works well don't touch it.
As if I need to tell you that.
>
> I'm trying to wrap my head around how I would approach this problem using
> what you've described above. I could have a table representing attributes
> common to all parameters. Then tables representing attributes specific to
> one parameter type or another. I could relate the tables via foreign keys?
> When I need to dispatch parameter changes, I could join the appropriate
> tables and change the appropriate values?
In your example all parameters had a name, and a value right? Well,
then you'd have a set of {paramName, value} tuples, where you could
update/insert values as necessary. (I'm assuming that we don't need
paramID and the paramName attribute uniquely identifies each
parameter).
In terms of other attributes recommended design would suggest a
relation for 'floatAttributes', and one for 'selectionAttibutes'. They
have different structures, and hence are collated under different
predicates (with just the paramName again in common and functioning as
a key). You'd join those to the values-relation as appropriate or
necessary via the paramName key.
I imagine that sounds wacky as hell if you are not used to a
relational approach, but there's no reason the functionality couldn't
be built into a programming language (as opposed to sitting in an
external db). As Codd showed in the 'great debate' it'd certainly
simplify querying the data, compared to std::iterating like its 1999.
>
> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.
Well, I'm talking theoretically atm - I'd certainly not abandon
everything for mysql given your requirements...
topmind
Leslie Sanford wrote:
> "JOG" wrote:
> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.
If the run-time performance needs to be predictable, then a RDBMS is
probably not the way to go. Garbage collection and index shifting/
restructuring may result in occasional pauses or slowdowns. Higher
abstraction often results in less predictable run-time performance.
(Less predictable and "slow" are not necessarily the same thing.)
-T-
Dmitry A. Kazakov
> On 2008-03-03 11:36:50 -0600, "David Cressey" <cres...@verizon.net> said:
>
>> There is, however, a different level of abstraction where an RDB is
>> two-dimensional. So Tom is not "wrong" all the way. And it may be at that
>> level of abstraction where the OO RM impedance match comes about.
>
> I don't know. Computer memory is one-dimensional.
(I remotely remember some early works on associative memory. A spatial
memory would be very interesting to have.)
I think that probably more important was that an execution path is single
dimensional and that many algorithms require existence of an order (that
includes the algorithms used in RDBMS). The balance could change, for
example under super parallel architectures. In a molecular computer a CPU
might become cheaper than a memory cell...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Dmitry A. Kazakov
> One can represent any graph on two-dimensional media just as one can
> represent any relation on two-dimensional media. In fact, since a graph
> is merely a set of vertices and a set of directed edges and since one
> can easily represent vertices and directed edges as tuples, one can
> easily represent any graph using relations.
In fact graph *is* a binary relation over the set of nodes. The notation
used in graph theory is relational. For instance, edges are denoted as aGb.
G is the graph. So what?
That proves / refutes nothing. Observe that any program is an integer
number. This certainly should make integer arithmetic hugely useful in for
software design. Let Windows XP be n, then to n+m would be Vista, n/2 would
Windows ME...
Argumentation to Turing/other-completeness is a fallacy in software design
disciplines.
Dmitry A. Kazakov
> On 2008-03-03, Robert Martin <uncl...@objectmentor.com> wrote:
>>
>> There is indeed more to it than that. OO and RDB are both strategies
>> for partitioning data.
No. OO stands for modeling, that might include data being modeled or
serving as models. It also might mean absence of data. In short, data are
irrelevant.
>> However, the motivation behind the partitioning
>> is completely different. OO partitions data based on the way a
>> particular application will process that data. RDBs partition data
>> based on how many different applications will need to access that data.
>
> No, RDBs partition data so that it is sensibly and easily available to
> any possible application. So if you use OO you are saying "there will
> never be any other application that will need my data".
No, it is engineering which says so. It translates as "put the requirements
first," or simpler "pigs do not fly."
Jan Hidders
> Roy Hann wrote:
> > "Thomas Gagne" <tga...@wide-open-west.com> wrote in message
> >news:7vqdnf21dLOnrVHa...@wideopenwest.com...
>
> >>JOG wrote:
>
> >>>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.
>
> >>The issue as I've discovered it has to do with the fact OO systems are
> >>composed of graphs of data and RDBs are two-dimensional.
>
> That is a remarkably uninformed and ill-conceived sentence. It's rather
> like comparing boats and cars saying boats have hulls and cars are
> pretty. Regardless of truth, the comparison is pointless on its face.
>
> One can represent any graph on two-dimensional media just as one can
> represent any relation on two-dimensional media. In fact, since a graph
> is merely a set of vertices and a set of directed edges and since one
> can easily represent vertices and directed edges as tuples, one can
> easily represent any graph using relations.
>
> The Great Debate was had about 3 decades ago and graphs lost.
I beg to differ. What lost was the idea that a close coupling is
required between how the data is stored and how it is accessed /
queried, i.e., that in that sense you cannot have data independence.
But such data independence can be just as well achieved with graph-
based data models.
-- Jan Hidders
Bob Badour
Well, I have yet to see it. Until I see any real evidence of a
graph-based data model with physical data independence, we will just
have to disagree.
Eric
So no-one ever says "we should be able to get that stuff out of the xyz
application and combine it with our data so that we can..."!
E
Dmitry A. Kazakov
You should plan this use case in advance. That would be a requirement. A
system can only do things it was designed for. (This applies to RDBMS as
well). For each application exist things it cannot do. That implies: either
A) there will never be any other application that will ask to do these, or
B) the application is incorrect (= does not fulfill the requirements).
Eric
So you will always know, in advance, what all the possible future
applications will want! I hope you are not crazy enough to believe that.
So you are left with minimising "things it cannot do". I guess that
means you should have something which can make the data available to any
application that asks, according to any logically possible criterion.
Did you know that this is what an RDBMS does?
Perhaps not, since you have also said that "data are irrelevant".
E
H. S. Lahman
>> 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.
First, I think it is important to clarify that the 'relational' in the
mismatch isn't referring to the fact that the OO paradigm uses something
other than set theory's relational model. The nature of the impedance
mismatch lies in the way the OO and RDB paradigms implement the same
relational model.
I think the lack of 1:1 tuple mapping is just a symptom of the mismatch.
There are several contributors to the mismatch...
Applications (not just OO) are designed to solve specific problems so
they are highly tailored to the particular problem in hand. In contrast,
databases are designed to provide ad hoc, generic access to data that is
independent of particular problem contexts. If one had to choose a
single characterization of the mismatch, this would be it; everything
else stems from it.
Object properties include behavior. Behaviors interact in much more
complex ways than data. Managing behaviors is the primary cause of
failing to map 1:1 between OO Class Diagrams and Data Models of the same
subject matter. That's because managing behavior places additional
constraints on the way the software is constructed.
OO relationships are instantiated at the object (tuple) level rather
than the class (table) level. This allows much better tailoring of
optimization to the problem in hand. It also focuses on capturing
business rules and policies in the way relationships are instantiated.
That, in turn, emphasizes preselecting sets of entities before they are
actually accessed. Thus query-like searches for object collaborations
are relatively rare in well-formed OO applications.
Corollary: the OO paradigm navigates relationship paths consisting of
individual binary associations and sequentially processes object sets
resulting from such navigation. Thus there is no direct equivalent of an
RDB join in OOPL or AAL syntax. (One can argue that the query/join
approach is less tedious, but the OO paradigm has additional goals to
satisfy, such as limiting access to knowledge.)
Object identity is usually not explicitly embedded as an attribute of
the object; OO applications are designed around address-based identity
in computer memory. This profoundly changes the way one manages
referential integrity. Thus OO developers will avoid class-level
identity searches whenever possible.
The relations in OO generalizations cannot be instantiated separately; a
single tuple resolves the entire generalization. This is the one
situation where a Class Model and a Data Model can never map 1:1. The
reason lies in the OO paradigm's support of polymorphism.
> 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.
The short answer is that any OO application developer sees the DBMS as
an implementation of a persistence layer.
I think it is important to distinguish between pure persistence in the
form of an RDB and a bundle of specialized server-side applications that
are layered on top of an RDB and form a DBMS. Some CRUD/USER processing
can be quite complex, such as data mining, but from the end customer's
perspective all the server-side applications are providing is data
access and formatting.
Similarly, it is important to distinguish between CRUD/USER processing
and other problems. In CRUD/USER processing the only problems being
solved for the customer are data entry, data selection, and conversion
to a convenient display representation. The RAD IDEs and layered model
infrastructures already handle that sort of processing quite well (e.g.,
it is no accident that they employ form-based UIs that conveniently map
into RDB tables) and applying OO development there would be largely
redundant.
Thus OO developers always believe that a database is a persistence
mechanism because they deal with problems outside CRUD/USER processing.
IOW, the OO application's solution *starts* with accessing data from a
persistent store and *ends* with shipping results off for display
rendering. That problem solution doesn't care what kind of data access
services the DBMS may provide; it just wants to access and store
particular piles of data. Similarly, it doesn't care whether user
communications are via GUI, web browser, or heliograph.
To put it more bluntly, from the OO application's solution perspective,
the developer couldn't care less that the data was mined from multiple
sources using exotic algorithms or whether it is stored in an RDB, an
OODB, flat files, or on clay tablets. At the level of abstraction of the
OO problem solution, only two services are required: "Save this pile of
data I call 'X'" and "Give me the pile of data I call 'X'". Thus the
entire interface for accessing persistence from an OO application's
problem solution is typically just three messages of the form {message
ID, [data packet]} that might look something like:
{SAVE_DATA, data ID, dataset} // to persistence
{GET_DATA, data ID} // to persistence
{HERE_IS_DATA, data ID, dataset} // response from persistence
The application solution will provide its own unique encode/decode of
the message data packets into its objects and their attributes that is
completely independent of the persistence schemas, etc..
Bottom line: the DBMS may provide all sorts of elegant CRUD/USER access
services but the OO application doesn't care about that; that belongs to
a different trade union.
<aside>
As a practical matter, the client-side does care because somehow those
messages need to be mapped into the server-side DBMS services (e.g.,
creating SQL queries, performance caching, and optimizing joins for the
DBMS). But to do that one only needs to provide the mapping once in a
subsystem that is reusable by any application that accesses that DBMS.
Typically that subsystem would be designed and implemented by someone
who has specialized DBA skills to utilize the DBMS services in an
appropriately clever fashion. IOW, the subsystem represents a
fundamental separation of concerns from the specific problem solution by
isolating and encapsulating specific mechanisms and optimizations
related to persistence access.
Note that when developing large OO applications, one does this sort of
subsystem encapsulation for *all* subsystems within the application; UI
and DB subsystems just happen to be ubiquitous concerns. One does OO
development because one wants maintainable applications. Hence
separation of concerns and encapsulation at the subsystem level is
critically important for decoupling implementations in different parts
of the application.
</aside>
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Dmitry A. Kazakov
> On 2008-03-04, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>
>>> On 2008-03-04, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>
>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>> any possible application. So if you use OO you are saying "there will
>>>>> never be any other application that will need my data".
>>>>
>>>> No, it is engineering which says so. It translates as "put the requirements
>>>> first," or simpler "pigs do not fly."
>>>
>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>> application and combine it with our data so that we can..."!
>>
>> You should plan this use case in advance. That would be a requirement. A
>> system can only do things it was designed for. (This applies to RDBMS as
>> well). For each application exist things it cannot do. That implies: either
>> A) there will never be any other application that will ask to do these, or
>> B) the application is incorrect (= does not fulfill the requirements).
>>
> So you will always know, in advance, what all the possible future
> applications will want! I hope you are not crazy enough to believe that.
No, I am. When I am looking for a solution I have to know what is the
problem. Is that crazy? Further, dealing with a generalized problem I shall
consider what would be the consequences of such generalization. There is
always a price to pay. You certainly have heard about computability, NP
problems and such stuff. But just going from 1ms to 100μs makes a huge
difference.
> So you are left with minimising "things it cannot do". I guess that
> means you should have something which can make the data available to any
> application that asks, according to any logically possible criterion.
> Did you know that this is what an RDBMS does?
No it does not, when "asking" is defined as diffuse as in the natural
language. There exist certain limitations on what and how can be asked.
These limitations should be specified as functional and non-functional
requirements. If you prefer to buy a cat in the bag named RDBMS (or
whatever), that's up to you. I merely state that there is always something
in any bag. As for the bag RDBMS, among the thing it contains are
object-relational impedance, SQL, poor performance, unpredictable behavior,
maintenance costs, etc.
> Perhaps not, since you have also said that "data are irrelevant".
Yes, I did. I am working mainly in the area of industrial data acquisition
and control. It might sound funny, but being so close to "data" one starts
to better understand why data are irrelevant.
David Cressey
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:4bza4t1lmhj9.1734ger7g3zac$.dlg@40tude.net...
This is true for an RDBMS. But more to the point, can a relational (or
SQL) database be designed in such a way that it has moderately good support
for thousands of anticipated queries, of which only a few dozen will
actually come to be used ? And will those few dozens of uses provide the
appropriate payback on the investment in building the database?
Based on my experience with databases, I offer the firm opinion that the
answer is yes.
Dmitry A. Kazakov
That's OK to me. But the question, as I understood it, was about
qualitative design changes. My point was that there is always a presumption
of the nature of changes which can and of those that cannot happen. A
design is good when this presumption matches the reality. From this point
of view there is no difference between deployment of OO or RDB solutions.
As engineering both would solve some class of problems and anticipate
quantitative changes of certain kind, but not qualitative ones.
When I read what Eric wrote, that made me think that he believed that RDB
would solve all problems and thus anticipate any changes. This would be
obviously wrong. I guess that his hidden argument was "because RDB
apparently solves all problems, then data-centric view is the right one."
Yet another logical fallacy was a data-centric problem statement: "there
will never be any other application that will need my data," used in order
to prove data-centric view itself. In OO problems are not modeled in terms
of applications using data. This alone does not yet imply anything about
the problems being solved. Actually we all are solving similar problems,
otherwise there would be no such quarrel between us.
P.S. OO is especially focused on maintenance. H.S. Lahman already wrote
about it in another post, so I need not to repeat it here.
Eric
> On Tue, 4 Mar 2008 17:58:02 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
>>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>>
>>>> On 2008-03-04, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote:
>>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>>
>>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>>> any possible application. So if you use OO you are saying "there will
>>>>>> never be any other application that will need my data".
>>>>>
>>>>> No, it is engineering which says so. It translates as "put the requirements
>>>>> first," or simpler "pigs do not fly."
>>>>
>>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>>> application and combine it with our data so that we can..."!
>>>
>>> You should plan this use case in advance. That would be a requirement. A
>>> system can only do things it was designed for. (This applies to RDBMS as
>>> well). For each application exist things it cannot do. That implies: either
>>> A) there will never be any other application that will ask to do these, or
>>> B) the application is incorrect (= does not fulfill the requirements).
>>>
>> So you will always know, in advance, what all the possible future
>> applications will want! I hope you are not crazy enough to believe that.
>
> No, I am. When I am looking for a solution I have to know what is the
> problem. Is that crazy? Further, dealing with a generalized problem I shall
> consider what would be the consequences of such generalization. There is
> always a price to pay. You certainly have heard about computability, NP
> difference.
Everything has a price. You have to choose. What I see is someone taking
only the short-term view.
>
>> So you are left with minimising "things it cannot do". I guess that
>> means you should have something which can make the data available to any
>> application that asks, according to any logically possible criterion.
>> Did you know that this is what an RDBMS does?
>
> No it does not, when "asking" is defined as diffuse as in the natural
> language. There exist certain limitations on what and how can be asked.
That's what I said - logically possible criteria.
> These limitations should be specified as functional and non-functional
> requirements.
If possible. What I meant was that you should minimise the limitations
on both the expected and the unknown futures.
> If you prefer to buy a cat in the bag named RDBMS (or
> whatever), that's up to you. I merely state that there is always something
> in any bag.
Cat? What cat? But actually, see what I said above about price.
> As for the bag RDBMS, among the thing it contains are
> object-relational impedance,
You made this one up because you don't understand.
> SQL,
OK, it's not the perfect language, but what is? And it is possible to
have an RDBMS that doesn't use it.
> poor performance,
Relative to what? Where are the tests? Do you install an RDBMS product
and just go with whatever myths you have heard lately, or do you get a
product specialist to sort it out?
> unpredictable behavior,
Please explain. Unless you're talking about bugs, but everything has
those.
> maintenance costs,
Everything has those too. Again, I have to assume that you take only the
short-term view.
> etc.
What else would you like to make up?
>
>> Perhaps not, since you have also said that "data are irrelevant".
>
> Yes, I did. I am working mainly in the area of industrial data acquisition
> and control. It might sound funny, but being so close to "data" one starts
> to better understand why data are irrelevant.
>
Aha! Your data is transient, and what you are mostly doing is
transforming it. I at least have no problem with using OO programming
for that. Also, that explains your short-term view. But what do you do
with the data (presumably transformed) that does get kept for longer?
Put it somewhere that will be available for a variety of expected and
unexpected uses? But we were here before!
E
Stefan Nobis
> First, I think it is important to clarify that the 'relational' in
> the mismatch isn't referring to the fact that the OO paradigm uses
> something other than set theory's relational model. The nature of
> the impedance mismatch lies in the way the OO and RDB paradigms
> implement the same relational model.
Huh? I know of the lambda calculus as a foundation of functional
languages and the relation model as foundation of RDBs. But I wonder
what the formal foundations of the OO family of languages is
(references, please).
As far as I understand those matters I would say the relational model
is more abstract than the OO model (only the most common language use
for the relational model, SQL, is... improvable).
--
Stefan.
Dmitry A. Kazakov
Huh, now after all these cries that DB is not about persistency... What
makes a temporal aspect so relevant then?
>>> So you are left with minimising "things it cannot do". I guess that
>>> means you should have something which can make the data available to any
>>> application that asks, according to any logically possible criterion.
>>> Did you know that this is what an RDBMS does?
>>
>> No it does not, when "asking" is defined as diffuse as in the natural
>> language. There exist certain limitations on what and how can be asked.
>
> That's what I said - logically possible criteria.
What about things which cannot be spelt in SQL? What about response times?
Can you specify/guess an upper bound for all requests? For a certain subset
of?
>> These limitations should be specified as functional and non-functional
>> requirements.
>
> If possible. What I meant was that you should minimise the limitations
> on both the expected and the unknown futures.
No optimum exists under these conditions.
>> If you prefer to buy a cat in the bag named RDBMS (or
>> whatever), that's up to you. I merely state that there is always something
>> in any bag.
>
> Cat? What cat? But actually, see what I said above about price.
You said that the price has to be paid. Right, but the question is about
performance/price ratio. You can buy a bigger car, but it would require
more gasoline and it would be more difficult to park. Software developing
is an expensive thing.
>> As for the bag RDBMS, among the thing it contains are
>> object-relational impedance,
>
> You made this one up because you don't understand.
What didn't I? That impedance exists or that it does not?
>> SQL,
>
> OK, it's not the perfect language, but what is? And it is possible to
> have an RDBMS that doesn't use it.
>
>> poor performance,
>
> Relative to what? Where are the tests? Do you install an RDBMS product
> and just go with whatever myths you have heard lately, or do you get a
> product specialist to sort it out?
Come on, show me the nearest neighbour search in ten-dimensional space
implemented in RDBMS. What would be the complexity of? You should clearly
understand that it is possible to break the neck of *any* indexing method.
This refutes the argument to "any logically possible criterion.".
>> unpredictable behavior,
>
> Please explain. Unless you're talking about bugs, but everything has
> those.
And what are the means available in order to prevent bugs? How much RDBMS
support static analysis? SQL is practically untyped. Design by contract,
how? Code reuse is close to none, well, code is evil, why should we reuse
it? Upper bounds for memory footprint? For response times?
>> maintenance costs,
>
> Everything has those too. Again, I have to assume that you take only the
> short-term view.
No,I mean long-term maintenance costs.
>> etc.
>
> What else would you like to make up?
Actually I don't want to concentrate on critique of RDBMS. It is a hardware
to me. I would buy one in case I needed it.
My objective is rather data-centric view. Which is IMO the reason for
object-relational impedance. BTW, I see nothing wrong in RA, which has in
my view fully independent on the notion of data. RA would nicely fit into
OO as a set of types with corresponding operations.
>>> Perhaps not, since you have also said that "data are irrelevant".
>>
>> Yes, I did. I am working mainly in the area of industrial data acquisition
>> and control. It might sound funny, but being so close to "data" one starts
>> to better understand why data are irrelevant.
>
> Aha! Your data is transient, and what you are mostly doing is
> transforming it.
Well, one viewed it this way in 50-60s, I guess. But it is a long time
since one dropped this data-centric view on the system as a huge signal
filter. This model does not scale and is inadequate (event controlled and
non-numeric things, GUI etc).
> I at least have no problem with using OO programming
> for that. Also, that explains your short-term view. But what do you do
> with the data (presumably transformed) that does get kept for longer?
> Put it somewhere that will be available for a variety of expected and
> unexpected uses? But we were here before!
Yes, here we go again. Data are meaningless if usage is unexpected. Nobody
can use a CD-ROM in a wind-up phonograph, deaf people notably.
The system does not keep anything it exists and behaves. Deployment of DB
there is always problematic. There are much ongoing efforts in this area in
recent years, mainly to standardize the schemas. That is not enough,
because relational model does not fit. Channels are largely event
controlled with time stamps. So you cannot make any reasonable relations
beyond (time, value) without data corruption. The queries would be like
"give me the oil temperature profile when the velocity was out of range for
longer than 10s before the event E." You need various interpolation
methods, calculated channels and ones simulated from previously recorded
measurements. Channels are created and destroyed, their properties change.
The end effect is that when DBs are used then only marginally. I remember
an amusing customer requirement: "we want to be able to run our tests even
if the DB server is off-line." (:-))
TroyK
> On 2008-03-03 12:29:02 -0600, TroyK <cs_tr...@juno.com> said:
>
> > My experience is somewhere between 2 and 3 orders of magnitude
> > difference between implementing a business rules change in the db vs.
> > the programming team doing it in OO code.
>
> Then you should be able to fly rings around the programmers and get
> them all fired. Â Why haven't you?
If by "fly rings around the programmers" you mean having a fully
functioning reference implementation up and running in SQL within 2
weeks that ends up taking a team of 3 programmers over 3 months to
implement in code, then, yeah, I guess I do. But the architecture
called for the programming to be done in a business layer implemented
in C# -- we expected and planned for that, so, happily, no one gets
fired.
> Ladies and gentlemen, there are certainly tasks that are better suited
> to SQL and stored procedures. Â There are other tasks that are better
Who said anything about stored procedures? I'm talking about
implementing the business rules via constraint declaration in the
database, and deriving new values throught the application of SQL
queries.
> suited to general purpose languages. Â True wisdom comes from knowing
> the strengths and weaknesses of both. Â Good architects build systems
> that combine the tools synergistically.
And good agile programmers know to use a high-level language in order
to enable iterating over design at a rapid pace.
TroyK
Marshall
> Stefan Nobis <sno...@gmx.de> writes:
> >But I wonder what the formal foundations
> >of the OO family of languages is
>
> well-specified term. What is a »formal foundation«?
> The syntax and semantics of any specific object-oriented
> language is given in the specification of that language.
If it has one. And even if it has a spec, is it formal spec,
or a prose spec? The Java spec for example is not formal.
Still, that's better than you get from most. With many
languages the "spec" is the reference implementation.
> But I do not know when you will deem a specification to be
> »formal« or a »formal foundation«.
Start here:
http://en.wikipedia.org/wiki/Formal_language
Marshall
Robert Martin
> It doesn't seem as
> straightforward to me to extend a language like C++ so that it becomes
> suitable for declaring relational transformations on data. If it is
> straight forward, then I'd like to hear from people who are doing it.
Take a look at LINQ.
--
Robert C. Martin (Uncle Bob)Â Â | email: uncl...@objectmentor.com
Object Mentor Inc.       | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716Â Â Â Â Â Â Â Â Â Â |
Robert Martin
> But the idea of a single language that is suitable for everything remains an
> elusive goal, and probably an unproductive endeavor.
Agreed.
Robert Martin
>
> "Roy Hann" <spec...@processed.almost.meat> wrote in message
> news:nfWdnW05its1o1Ha...@pipex.net...
>
>
>> Until I know their reasons for their views on data structures I couldn't
>> say. However I notice that I am surrounded by programmers who consume
> most
>> the development budget writing code, and when a change request comes along
> I
>> can accommodate it in the database in minutes and they spend months
> spewing
>> out more code (sometimes after doing an extensive and expensive impact
>> assessment). Code may not be evil, but it sure has a case to answer.
>
> I have to agree with this comment, based on my own experience.
OK, then I'll ask you the same question I asked Roy. If you *could
have* done it in minutes, why didn't you?
Robert Martin
> But I think anybody inspecting both examples will clearly see that my
> version is a lot less total code.
C++ is a pretty wordy language. If I wrote it in Ruby I bet I'd beat
you by a wide margin.
Robert Martin
> A join of the two statements gave me the inference I required: {Name,
> Mortality}. All of a sudden it seemed simple.
Interesting story. Yes, when you have a problem of inference, it's
good to use an inference engine.
> So some questions:
>
> 1) So why not treat all 'inheritance' in this way?
Because all inheritance is not about inference.
> 2) Could one extend to include 'behaviour' as well?
Yes. See the Prolog language.
> 3) And is this a crazy thing to suggest in a cross post to an OO
> group?
I've seen a lot crazier things.
Robert Martin
> One's requirements dictate data with certain functional dependencies.
> Among the easiest tasks in application design is one of the earliest:
> structuring the data. The RM structures data as relations. Relational
> structures lack query bias, which is one of the reasons why SQL
> is so good at ad hoc queries (compared to the other choices.)
> OO structures mandates an object structure (unsurprisingly): out the
> gate, one has no choice but to build in a query bias, whether
> one wants it or not.
Agreed. That "bias" can work very well if you only use the biased
queries. That works well in the context of a single application, or a
single piece of an application. It does not work well in the general
case, which is why OODBs never quite took off.
>
> Furthermore, since OOPLs lack physical independence, traversing
> the graph may be quite expensive, particularly in the case where
> the graph is backed by storage in a database, which is part of
> why ORM is such a universally bad idea.
No, you have this wrong. ORMs generally use standard SQL queries to
traverse and gather data from the DB. Then that data is placed into OO
structures so that the application can take advanage of the bias.
Robert Martin
>
> "Bob Badour" <bba...@pei.sympatico.ca> wrote in message
> news:47cc383f$0$4041$9a56...@news.aliant.net...
>
>
>> It's pretty obvious to me: object-relational mismatch is to relations as
>> assembler-object mismatch is to objects.
>
> I didn't get this comment. Now that someone else flagged it as a
> keeper, I feel the need to ask for an explanation.
Explanation: "WAA WAA WAA WAA WAA WAA". (The sound made by the adults
in the Peanuts cartoons).
Robert Martin
> In SQL, if I have two relations with x and y int columns, I can
> union them, or join on them, or whatever. There is no way,
> in fact, to forbid such a thing, just like in Java there is no way
> to allow such a thing.
You are confusing OO with static typing. In OO languages like Ruby,
Python, or Smalltalk you can pass any object to any function
irrespective of type.
Dmitry A. Kazakov
> On 2008-03-03 16:49:29 -0600, "David Cressey" <cres...@verizon.net> said:
>
>> But the idea of a single language that is suitable for everything remains an
>> elusive goal, and probably an unproductive endeavor.
>
> Agreed.
Disagreed.
The idea of multilingual system is the most damaging thing in software
developing history.
Dmitry A. Kazakov
> On 2008-03-03 18:34:39 -0600, Marshall <marshal...@gmail.com> said:
>
>> In SQL, if I have two relations with x and y int columns, I can
>> union them, or join on them, or whatever. There is no way,
>> in fact, to forbid such a thing, just like in Java there is no way
>> to allow such a thing.
>
> You are confusing OO with static typing. In OO languages like Ruby,
> Python, or Smalltalk you can pass any object to any function
> irrespective of type.
Which is a bad idea.
Nevertheless you don't need dynamic typing in order to deal with that. You
could have a class of relations in order to define operations (like join)
on them. That will give a static type to the result of any join.
The problem is elsewhere. How do I know in *advance* that the result of
join is a relation of certain narrower kind? Both "statically untyped" SQL
and "dynamically untyped" fancy languages have no answer to that until run
time. Note that this is a software design issue.
S Perryman
> "H. S. Lahman" <h...@pathfindermda.com> writes:
>>First, I think it is important to clarify that the 'relational' in
>>the mismatch isn't referring to the fact that the OO paradigm uses
>>something other than set theory's relational model. The nature of
>>the impedance mismatch lies in the way the OO and RDB paradigms
>>implement the same relational model.
> Huh? I know of the lambda calculus as a foundation of functional
> languages and the relation model as foundation of RDBs. But I wonder
> what the formal foundations of the OO family of languages is
> (references, please).
1. The prog lang (Simula) came first, not the formalisms.
Which then inspired +/- aligned with other notions (ADTs etc) that
were present/emerging in the CS community at that time.
2. The closest basic formalism that OO could be mapped to is ADTs.
ADT theory uses a number of formalisms (algebraic specification,
type theories etc) to define the behaviour of ADTs.
But these formalisms use the same 'language' (propositional/predicate
logic, set theory etc) as the Relational model.
> As far as I understand those matters I would say the relational model
> is more abstract than the OO model
The ADT formalisms suggest otherwise.
> (only the most common language use for the relational model, SQL, is... improvable).
Indeed.
Regards,
Steven Perryman
S Perryman
> On 2008-03-03 18:34:39 -0600, Marshall <marshal...@gmail.com> said:
>> In SQL, if I have two relations with x and y int columns, I can
>> union them, or join on them, or whatever. There is no way,
>> in fact, to forbid such a thing, just like in Java there is no way
>> to allow such a thing.
> You are confusing OO with static typing. In OO languages like Ruby,
> Python, or Smalltalk you can pass any object to any function
> irrespective of type.
And you (both) are equating the (strong) typing model of Simula as the
only strong typing model. Go and look at Functional prog langs etc for
examples of how Marshalls' gripe would be done in a type-safe manner.
Regards,
Steven Perryman
Eric
> On Tue, 04 Mar 2008 19:45:30 GMT, David Cressey wrote:
>
>>
>> This is true for an RDBMS. But more to the point, can a relational (or
>> SQL) database be designed in such a way that it has moderately good support
>> for thousands of anticipated queries, of which only a few dozen will
>> actually come to be used ? And will those few dozens of uses provide the
>> appropriate payback on the investment in building the database?
>
>> Based on my experience with databases, I offer the firm opinion that the
>> answer is yes.
>
> That's OK to me.
Good.
> But the question, as I understood it, was about
> qualitative design changes. My point was that there is always a presumption
> of the nature of changes which can and of those that cannot happen. A
> design is good when this presumption matches the reality. From this point
> of view there is no difference between deployment of OO or RDB solutions.
> As engineering both would solve some class of problems and anticipate
> quantitative changes of certain kind, but not qualitative ones.
>
> When I read what Eric wrote, that made me think that he believed that RDB
> would solve all problems and thus anticipate any changes. This would be
> obviously wrong.
I don't believe that merely using an RDBMS will solve all problems. What
I meant was that, accepting what David said above, if you keep your data
in an RDBMS, it will be easily available for the solution of any
possible problem that can be solved using that data.
> I guess that his hidden argument was "because RDB
> apparently solves all problems, then data-centric view is the right one."
No, the argument is that the data-centric view is often (not necessarily
always) the right one to take, and that keeping the data in an RDBMS
provides a better basis for solving future problems using the data than
any other way of keeping it.
> Yet another logical fallacy was a data-centric problem statement: "there
> will never be any other application that will need my data," used in order
> to prove data-centric view itself.
There is no fallacy here. First there is a fact - you have data, however
you choose to view it. Do you want to deny this? If you do we may need
to sort out the meaning of the word "data". Given this fact, I am saying
that you can not guarantee that there will be no other uses for your
data, so you must keep open a way for those other uses to see your data.
> In OO problems are not modeled in terms
> of applications using data.
No, but the data is still there.
> This alone does not yet imply anything about
> the problems being solved. Actually we all are solving similar problems,
> otherwise there would be no such quarrel between us.
>
> P.S. OO is especially focused on maintenance. H.S. Lahman already wrote
> about it in another post, so I need not to repeat it here.
>
E
Eric
> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>
<snip>
>>
>> That's what I said - logically possible criteria.
>
> What about things which cannot be spelt in SQL?
Use the query language (not necessarily SQL) to pass the data to
something that can deal with it.
> What about response times?
> Can you specify/guess an upper bound for all requests? For a certain subset
> of?
This is just a prejudice - get the right RDBMS and the right expert to
tune it (specifically for what it must do, not generically) and you
might be surprised.
But I don't believe that an RDBMS can do everything. I would not be
surprised to find the data defining the ten-dimensional space in an
RDBMS, but I would never expect to do such a calculation in the query
language.
No collection of data is useful to everybody, so deaf people have got
nothing to do with it.
Other than that, you have just demonstrated a lack of understanding of
the difference between the logical and the physical. It is possible for
me to collect the necessary bits of technology to transfer a piece of
music from a CD-ROM to a disc or cylinder for the wind-up phonograph. It
is still the same piece of music.
>
> The system does not keep anything it exists and behaves.
But it has inputs and outputs. There may also be a need for it to record
some of its behaviour. There may be a reason to keep some of the
outputs, or even the inputs (for later extended analysis?). If you have
a system that genuinely keeps nothing, I have no argument with how you
choose to create it, as long as it works.
> Deployment of DB
> there is always problematic. There are much ongoing efforts in this area in
> recent years, mainly to standardize the schemas. That is not enough,
> because relational model does not fit. Channels are largely event
> controlled with time stamps. So you cannot make any reasonable relations
> beyond (time, value) without data corruption. The queries would be like
> "give me the oil temperature profile when the velocity was out of range for
> longer than 10s before the event E." You need various interpolation
> methods, calculated channels and ones simulated from previously recorded
> measurements. Channels are created and destroyed, their properties change.
> The end effect is that when DBs are used then only marginally. I remember
> an amusing customer requirement: "we want to be able to run our tests even
> if the DB server is off-line." (:-))
>
E
Eric
> On Wed, 5 Mar 2008 00:46:14 -0600, Robert Martin wrote:
>
>> On 2008-03-03 16:49:29 -0600, "David Cressey" <cres...@verizon.net> said:
>>
>>> But the idea of a single language that is suitable for everything remains an
>>> elusive goal, and probably an unproductive endeavor.
>>
>> Agreed.
>
> Disagreed.
>
> The idea of multilingual system is the most damaging thing in software
> developing history.
>
Well, that opinion explains a lot of the things you have said. You also
appear to have assumed that other people agreed, leading you to
misinterpret what they said.
If you should not use multiple languages, there must be a universal
language. What is it, is it really universal _right now_, and if not,
when will it be and what should we do in the meantime?
E
JOG
> On 2008-03-03 17:06:05 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> > A join of the two statements gave me the inference I required: {Name,
> > Mortality}. All of a sudden it seemed simple.
>
> Interesting story. Yes, when you have a problem of inference, it's
> good to use an inference engine.
>
> > So some questions:
>
> > 1) So why not treat all 'inheritance' in this way?
>
> Because all inheritance is not about inference.
Hmmm. Then might you give an example of a situation where inheritance
cannot be described in terms of inference?
>
> > 2) Could one extend to include 'behaviour' as well?
>
> Yes. See the Prolog language.
>
> > 3) And is this a crazy thing to suggest in a cross post to an OO
> > group?
>
> I've seen a lot crazier things.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
Thomas Gagne
> On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
>
>
>> You are confusing OO with static typing. In OO languages like Ruby,
>> Python, or Smalltalk you can pass any object to any function
>> irrespective of type.
>>
>
> Which is a bad idea.
>
> Nevertheless you don't need dynamic typing in order to deal with that. You
> could have a class of relations in order to define operations (like join)
> on them. That will give a static type to the result of any join.
>
> The problem is elsewhere. How do I know in *advance* that the result of
> join is a relation of certain narrower kind? Both "statically untyped" SQL
> and "dynamically untyped" fancy languages have no answer to that until run
> time. Note that this is a software design issue.
>
predictably what does it matter?
--
Visit <http://blogs.instreamco.com/anything.php> to read
my rants on technology and the finance industry. Visit
<http://tggagne.blogspot.com/> for politics, society and culture.
Bob Badour
> "JOG" wrote:
>
>>This reminds me of a serious 'click' moment I had with data
>>structures. A long time ago, in a galaxy far far away, I once sat
>>blindly reinventing my own network model, with identifiers, pointers,
>>types, and all the fun of the fair. As an OO programmer it was the
>>only mindset I had. Then I considered encoding data similar to the
>>classic example of:
>>
>>* Aristotle is a man
>>* All men are mortal
>>* |= Aristotle is mortal
>>
>>Well, /clearly/ what I was dealing with here was a generic entity
>>class, of which Man was a subclass, and Aristotle an instance.
>>Something like:
>>
>>class Entity
>>{
>>boolean mortal;
>>string name;
>>Entity(_name, _mortal) : name(_name), mortal(_mortal);
>>};
>>
>>class Man : public Entity
>>{
>>date bday;
>>Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
>>};
>>
>>
>>But, as I extended the example, the structures got more convoluted,
>>and the result more and more of a mess. Finally something clicked. It
>>wasn't about types, objects or inheritance, it was about /inference/,
>>and what I actually had was:
>>
>>Name(x, Aristotle) -> Species(x, Man)
>>Species(x, Man) -> Mortality(x, Mortal)
>>|= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>>
>>No types or reification in sight. Instead I had two groups of
>>statements:
>>People = {Name, Species, Bday}
>>Entities = {Species, Mortality}
>>
>>A join of the two statements gave me the inference I required: {Name,
>>Mortality}. All of a sudden it seemed simple. So some questions:
>>
>>1) So why not treat all 'inheritance' in this way?
>>2) Could one extend to include 'behaviour' as well?
>>3) And is this a crazy thing to suggest in a cross post to an OO
>>group?
>
>
> I'm jumping in realizing that I may be revealing a bit of ignorance here, so
> bear with me.
>
> If I need to send a message to all persons who are mortal, I could join
> People and Entities together by species and where Mortality is true?
>
> Once I've performed the join, I then dispatch a message to the resulting
> group: "GetAnnualCheckUp()" or something?
>
> In the application I'm currently writing, I have a large list of parameters.
> These parameters share some values such as Name and Label. However, there
> are different types of parameters such as those that represent a boolean
> state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
> etc., and other types. My current approach is traditional OO, and that's to
> have a hierarchy of Parameter classes. I can then keep a list of
> heterogeneous parameters and treat them polymorphically. For example:
>
> params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
> params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);
>
> // Set a parameter value. All raw parameter values are in the range
> // of [0, 1]. Each parameter class knows how to transform raw parameter
> // values in an appropriate way.
> params[parameterId].SetValue(value);
>
> And all works well.
>
> I'm trying to wrap my head around how I would approach this problem using
> what you've described above. I could have a table representing attributes
> common to all parameters. Then tables representing attributes specific to
> one parameter type or another. I could relate the tables via foreign keys?
> When I need to dispatch parameter changes, I could join the appropriate
> tables and change the appropriate values?
>
> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.
Leslie,
Relationally, I would approach what you are doing almost exactly as you
are now. The data type for parameter values would be a union type with
sub-types as appropriate.
Whether one has a single base relation with all parameter types or one
has a different base relation for each sub-type becomes almost moot. No
matter which one chooses, one can have both using views. Either a
restrict view to derive each sub-type relation from the single base
relation or a single union view to derive the super-type relation from
the individual sub-type base relations.
If this is a subject that interests you, I highly recommend Fabian
Pascal's _Practical Issues in Database Management ..._
Bob Badour
> Responding to JOG...
>
>>> 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.
>
> First, I think it is important to clarify that the 'relational' in the
> mismatch isn't referring to the fact that the OO paradigm uses something
> other than set theory's relational model. The nature of the impedance
> mismatch lies in the way the OO and RDB paradigms implement the same
> relational model.
Frankly, the paragraph above is nonsense.
> I think the lack of 1:1 tuple mapping is just a symptom of the mismatch.
> There are several contributors to the mismatch...
>
> Applications (not just OO) are designed to solve specific problems so
> they are highly tailored to the particular problem in hand. In contrast,
> databases are designed to provide ad hoc, generic access to data that is
> independent of particular problem contexts. If one had to choose a
> single characterization of the mismatch, this would be it; everything
> else stems from it.
>
> Object properties include behavior. Behaviors interact in much more
> complex ways than data. Managing behaviors is the primary cause of
> failing to map 1:1 between OO Class Diagrams and Data Models of the same
> subject matter. That's because managing behavior places additional
> constraints on the way the software is constructed.
The above three paragraphs are not much better.
> OO relationships are instantiated at the object (tuple) level rather
> than the class (table) level.
Equating object instances with tuples and object classes with relations
is a great blunder. One of two great blunders detailed in Date's and
Darwen's _The Third Manifesto_.
A tuple is actually a logical join of N object values. An object class
extent is a unary relation. OO has no concept equal to a binary
relation--let alone an n-ary relation.
[remaining nonsense snipped]
Marshall
> >
> > Furthermore, since OOPLs lack physical independence, traversing
> > the graph may be quite expensive, particularly in the case where
> > the graph is backed by storage in a database, which is part of
> > why ORM is such a universally bad idea.
>
> No, you have this wrong. ORMs generally use standard SQL queries to
> traverse and gather data from the DB. Then that data is placed into OO
> structures so that the application can take advanage of the bias.
Just the fact that they use SQL isn't sufficient. They have to
use it as well as a person could, though an interface that
is generally information-lossy enough (or at least, used in
a lossy way) that that's impossible.
The most gratuitous example I can think of was some early
EJB containers I played with, back when I was still thinking
that ORM was something that could possibly be done well.
Against a table of a few hundred rows, one could execute
"delete from table". The comparable command through the
ORM issued SQL to load every row as an object, then
in a loop called obj.delete() which issued a single DELETE
statement for that row. It was ten thousand times slower,
and that's for only a couple hundred rows. Of course this
example is extreme, but it's still illustrative of a general
principle.
I have *often* seen four and five order of magnitude
performance difference between straight SQL and
ORM SQL, across a wide variety of ORMs. The
very idea of ORM demands it: you have to try to
push a whole set-oriented language through a functional
interface.
Marshall
H. S. Lahman
>> First, I think it is important to clarify that the 'relational' in
>> the mismatch isn't referring to the fact that the OO paradigm uses
>> something other than set theory's relational model. The nature of
>> the impedance mismatch lies in the way the OO and RDB paradigms
>> implement the same relational model.
>
> Huh? I know of the lambda calculus as a foundation of functional
> languages and the relation model as foundation of RDBs. But I wonder
> what the formal foundations of the OO family of languages is
> (references, please).
The foundation is much broader because of the need to provide dynamic
elements (i.e., the relational model is a subset of the OO foundation).
However, the point in this context is that a UML Class Diagram *is* an
Entity Relationship Diagram and it is normalized exactly the same way as
an ERD Data Model. But the Class Diagram is just one view of the overall
solution and it needs to play with other views so the semantics of
construction are somewhat different, as I indicated in my post.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Marshall
> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spi...@gmail.com> said:
>
> > In SQL, if I have two relations with x and y int columns, I can
> > union them, or join on them, or whatever. There is no way,
> > in fact, to forbid such a thing, just like in Java there is no way
> > to allow such a thing.
>
> You are confusing OO with static typing.
How supremely annoying to have gone to some lengths
to carefully use the most strictly defined, modern type
system terminology, only to have it labeled as a novice
error by someone who missed my point entirely.
At least you didn't say "duck typing."
> In OO languages like Ruby,
> Python, or Smalltalk you can pass any object to any function
> irrespective of type.
Actually, the dimension I was referring to is
"nominal" vs. "structural" typing. This axis is independent
of static vs. "dynamic" typing. Ruby, Python
and Smalltalk all use structural, dynamic (aka runtime) typing.
C++ uses static, nominal typing. Java uses a static, nominal
type system with the addition of runtime types; SQL uses
static, structural typing.
I was speaking of nominal vs. structural.
Marshall
topmind
H. S. Lahman wrote:
> Responding to Nobis...
>
> >> First, I think it is important to clarify that the 'relational' in
> >> the mismatch isn't referring to the fact that the OO paradigm uses
> >> something other than set theory's relational model. The nature of
> >> the impedance mismatch lies in the way the OO and RDB paradigms
> >> implement the same relational model.
> >
> > Huh? I know of the lambda calculus as a foundation of functional
> > languages and the relation model as foundation of RDBs. But I wonder
> > what the formal foundations of the OO family of languages is
> > (references, please).
>
> The foundation is much broader because of the need to provide dynamic
> elements (i.e., the relational model is a subset of the OO foundation).
This "subset" thing is perhaps misleading. While trying to figure out
how to merge paradigms in another forum in order to make everybody
happy and stop the bickering, we eventually generally agreed that
paradigms are more about *constraints* than features. What a paradigm
*doesn't* allow is often more important to defining it than what it
does allow. The "no side-effects" rule of Functional Programming is an
example. If one tries to create a language or tool that allows
multiple paradigms, it often has to relax such constraints such that
the essence of the original paradigm is lost.
One cannot "reason" about the results as easily because they don't
know which rules a given thing will abide by. Paradigms are tools to
help human reasoning by providing rules for the "atoms" to follow. If
there are too many rules, or a lack of rules, then it becomes a big
ball of twine too hard to get one's head around because any assumption
you rely on to mentally narrow down the possible paths something can
take may just be all wrong.
>
> However, the point in this context is that a UML Class Diagram *is* an
> Entity Relationship Diagram and it is normalized exactly the same way as
> an ERD Data Model. But the Class Diagram is just one view of the overall
> solution and it needs to play with other views so the semantics of
> construction are somewhat different, as I indicated in my post.
>
>
> --
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
-T-
topmind
> On 2008-03-03 17:25:48 -0600, topmind <topm...@technologist.com> said:
>
> > But I think anybody inspecting both examples will clearly see that my
> > version is a lot less total code.
>
> C++ is a pretty wordy language. If I wrote it in Ruby I bet I'd beat
> you by a wide margin.
I am a skeptical, but you are welcome to try. And, it would probably
be the meta features of Ruby that cut it down, not OOP.
> --
> Robert C. Martin (Uncle Bob) | email: uncle...@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716 |
-T-
Marshall
> >> In SQL, if I have two relations with x and y int columns, I can
> >> union them, or join on them, or whatever. There is no way,
> >> in fact, to forbid such a thing, just like in Java there is no way
> >> to allow such a thing.
> > You are confusing OO with static typing. In OO languages like Ruby,
> > Python, or Smalltalk you can pass any object to any function
> > irrespective of type.
>
> And you (both) are equating the (strong) typing model of Simula as the
> only strong typing model.
No I most certainly am not, and there isn't anything in my post
that could lead one to conclude that I am.
Marshall
Marshall
> "H. S. Lahman" <h...@pathfindermda.com> writes:
>
> > the mismatch isn't referring to the fact that the OO paradigm uses
> > something other than set theory's relational model. The nature of
> > the impedance mismatch lies in the way the OO and RDB paradigms
> > implement the same relational model.
>
> Huh? I know of the lambda calculus as a foundation of functional
> languages and the relation model as foundation of RDBs. But I wonder
> what the formal foundations of the OO family of languages is
> (references, please).
The foundation of OO mostly hasn't been laid down yet.
Little work has been done. If you are interested:
http://www.google.com/search?q=theory+of+objects
Abadi and Cardelli have done some work in this area.
Cardelli in particular is a brilliant CS researcher; you cannot
go wrong paying attention to anything he has to say.
Marshall
Marshall
>
> ... the relational model is a subset of the OO foundation ...
Please describe where JOIN and UNION for example,
are to be found in the OO foundation. Or in any OO language.
Marshall