Object-relational impedence

#41

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.

#42

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.

#43

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.

#44

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.

#45

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.

#46

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

It's pretty obvious to me: object-relational mismatch is to relations as
assembler-object mismatch is to objects.

#47

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

Quote:

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

#48

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

Quote:

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

#49

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

Quote:

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

#50

JOG wrote:

Quote:

On Mar 3, 2:07 pm, Thomas Gagne <tga... (AT) wide-open-west (DOT) 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.

Quote:

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