 | |
#41
 
| |||
| |||
|
Re: Mixing OO and DB -
02-07-2008
, 04:33 PM
|
I know both object oriented programming and DB (SQL). But it seems that these are incompatible. Or may somebody advice how to meddle them together? Being strong in both OOP and DB development, I am yet weak in writing object oriented programs which use DB. Maybe somebody may suggest me some article about mixing together DB and OOP?I |
is inevitable cross-posting to comp.object and comp.database), then
I'd have a look at Date and Darwen's Third Manifesto, which describes
an Object Relational Model. However, in many waysOOP (however that is
defined) and Database Theory are diametrically opposed. This is hardly
suprising given that Relational Databases replaced the Network
Databases which have so much in common with OO.
In the end OOA is conceptual modeling, and you'll get away with
translating that directly to a logical model as long as your data
isn't going to be shared by people or applications that use different
conceptual models (and you can put up with the clunkiness of
navigational querying of course). If you do want to (or more likely
have to) meld OO and RM together, then google "object relational
mapping" software... but rather you than me
#42
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#43
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#44
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#45
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#46
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#47
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#48
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#49
| |||
| |||
|
|
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. |
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.
First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.
Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
#50
| |||
| |||
|
|
On Feb 7, 12:35 pm, Victor Porton <por... (AT) narod (DOT) ru> wrote: I know both object oriented programming and DB (SQL). But it seems that these are incompatible. I suggest that OO ideas are too naive to continue influence programming. Formal Concept Analysis (FCA) is much more theoretically sound method how to organize things into taxonomies. Here is an example -- a hierarchy of living things, restricted to the set {Lamprey, Trout, Lungfish, ..., Human}. FCA starts with feature matrix like this: * * * * * * * * * *Jaws Limbs * Hair * *Lungs * Tail * *Shell Lamprey 0 * * * 0 * * * 0 * * * 0 * * * 1 * * * 0 Trout * * * * * * * 1 * 0 * * * 0 * * * 0 * * * 1 * * * 0 Lungfish * * * *1 * * * 0 * * * 0 * * * 1 * * * 1 * * * 0 Turtle * * * * * * *1 * 1 * * * 0 * * * 1 * * * 1 * * * 1 Cat * * * * * * * * 1 * 1 * * * 1 * * * 1 * * * 1 * * * 0 Gorilla * * * * * * 1 * 1 * * * 1 * * * 1 * * * 0 * * * 0 Human * * * * * * * 1 * 1 * * * 1 * * * 1 * * * 0 * * * 0 Then, the objects and the attributes (aka concepts) organize themselves into a lattice like this Lamprey -> Trout -> Lungfish -> Cat -> Gorilla * * * * * * * * * * * *| * * * * | * * * * * * * * * * * *| * * * * ---> Human * * * * * * * * * * * *| * * * * * * * * * * * *----> Turtle which is more powerful concept than OO hierarchy of classes. Each FCA concept is essentially a limited form of a relation. |
appropriate test of variations-on-a-theme management techniques for
many domains. This is because biology is based on descent-based
evolution; while other domain items, such as Apple Widgets are not,
and are composed of a buffet-like mix-and-match of features based on
S. Job's whims. He can make a Tiger-Crab if he wants, but evolution
won't (unless Monsanto goes mad).
Quote:
|
There are some reasons why FCA methods never enjoyed a success comparable to OO and Relational Model. They are simply more restrictive sets of relations which obey distributive property, why relations in general don't. |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.