Mixing OO and DB
Victor Porton
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?
Tegiri Nenashi
> 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.
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.
topmind
They *are* incompatible. Here's an excerpt 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-
Dmitry A. Kazakov
> 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.
Sorry, but the idea of subsets used in place of subtypes far surpasses in
naiveness anything one could charge "naive OO" with.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Tegiri Nenashi
wrote:
> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
> > 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.
>
> Sorry, but the idea of subsets used in place of subtypes far surpasses in
> naiveness anything one could charge "naive OO" with.
Are you referring to apparent object propelleheads unability to even
coherently define what the object/type is? Then, the ability to
operate a concept without defining it is certainly a sign of
superiority of your method.
JOG
If your true intention was not to start some serious flaming (which
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 ;)
Tegiri Nenashi
> 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.
This snippet highlights a major problem with wikipedia articles which
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!
topmind
It should be pointed out that biological taxonomies are often not an
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).
>
> 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.
-T-
topmind
> > 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.
>
> Sorry, but the idea of subsets used in place of subtypes far surpasses in
> naiveness anything one could charge "naive OO" with.
Oh goody, another Types-Vs.-Sets fight is brewing. Get the popcorn...
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
-T-
frebe
Whether OO and a relational DB is incompatible or not, depends on how
you use OO. In the relational camp, objects and relations are
considered being orthogonal features. A relation (table), is a
relation between values (objects). In fact, classes are one way of
defining types (domains) needed in the relational model. For example,
the datetime type or a currency type may be defined using classes.
The problem occurs when one try to use classes/objects as data
structures. The relational model only allow relations as data
structures. If you create classes like "employee", "customer", you
will soon encounter big problems. But classes like "SSN", "telephone
no", "zip code" will fit perfect together with the relational model.
One other important thing is that objects used in relations must be
immutable. Objects are values. If you start using mutable (data)
objects in multi-user environments, you will soon encounter a lot of
concurrency issues, that the RDBMS is supposed to do for you instead.
Objects and classes can obviously be used successfully for other
things not related to data management. For example, classes/objects
are suitable for buildning a GUI.
//frebe
Dmitry A. Kazakov
> On Feb 7, 2:04 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
>>> 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.
>>
>> Sorry, but the idea of subsets used in place of subtypes far surpasses in
>> naiveness anything one could charge "naive OO" with.
>
> Are you referring to apparent object propelleheads unability to even
> coherently define what the object/type is?
At least they try to face the problem. Which is not about clustering some
arbitrary set of attributes.
> Then, the ability to
> operate a concept without defining it is certainly a sign of
> superiority of your method.
Certainly a notion of type can be given with all necessary rigorousness.
The only question is how useful a particular definition is in the context
of software design (correctness, maintenance, complexity, non-functional
constraints).
P.S. Plucked chicken is not yet a man (remembering a two thousand year old
anecdote).
JOG
wrote:
> On Thu, 7 Feb 2008 14:15:53 -0800 (PST), Tegiri Nenashi wrote:
> > On Feb 7, 2:04 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
> >>> 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.
>
> >> Sorry, but the idea of subsets used in place of subtypes far surpasses in
> >> naiveness anything one could charge "naive OO" with.
>
> > Are you referring to apparent object propelleheads unability to even
> > coherently define what the object/type is?
>
> At least they try to face the problem.
Although you only have to face the problem of definining what an
"object" is if you've conjured that problem in the first place.
> Which is not about clustering some arbitrary set of attributes.
What is it about then? Genuinely interested.
Dmitry A. Kazakov
> On Feb 8, 8:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 7 Feb 2008 14:15:53 -0800 (PST), Tegiri Nenashi wrote:
>>> On Feb 7, 2:04 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
>>>>> 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.
>>
>>>> Sorry, but the idea of subsets used in place of subtypes far surpasses in
>>>> naiveness anything one could charge "naive OO" with.
>>
>>> Are you referring to apparent object propelleheads unability to even
>>> coherently define what the object/type is?
>>
>> At least they try to face the problem.
>
> Although you only have to face the problem of definining what an
> "object" is if you've conjured that problem in the first place.
Much confusion arise from mixing domain and solution spaces when talking
about "objects." Otherwise I see nothing impossible neither in defining
"object" as a language term nor in doing so in the corresponding problem
domain. One should just remember that they are different beasts.
>> Which is not about clustering some arbitrary set of attributes.
>
> What is it about then? Genuinely interested.
It is about software design. Assuming that to design software is to cluster
a set of all possible programs into the categories "does-the-thing",
"does-other-thing" is funny, at least.
Daniel T.
> 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?
You specifically mention SQL, what language are you trying to "meddle"
SQL to? I expect, in any case, that it isn't going to be easy. It
usually isn't easy to "meddle" two languages together. (I'm assuming
here that "meddle" means the same thing as "meld".)
> 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 don't know much about "DB development" myself, but Robert Martin's
"Designing Object Oriented C++ Applications using the Booch Method" has
a section about mixing DB and OOP. He basically says that you need to
use down-casts to mix them. (Which implies that they don't mix well.)
Patrick May
> 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.
You're experiencing the well known "object relational impedance
mismatch." There are two basic issues underlying this problem.
First, the relational approach focuses on data while the OO approach
focuses on behavior. Of course you can implement some behavior in an
RDBMS and manage state in a OO language, but the design drivers are
different.
Second, and partly related to the first issue, when used in the
same software system the two components change for different reasons.
A relational schema is often used by multiple different applications
and must therefore provide reasonable performance for a broad range of
data creation, read, update, and deletion patterns. Even when the
relational schema is embedded in a single application, state changes
for different reasons and as different rates from behavior.
The object model, on the other hand, is optimized to address
non-functional requirements (NFRs) related to the problem domain. The
supported behaviors may change or be extended without needing to
change state at all.
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?
Because of the impedance mismatch, most OO systems use some form
of object-relational mapping. A quick Google turns up this as a
reasonable starting point for your research:
http://www.agiledata.org/essays/mappingObjects.html
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
David Cressey
"Victor Porton" <por...@narod.ru> wrote in message
news:89b92dec-b710-4c24...@u10g2000prn.googlegroups.com...
First off, I think it's reall the mixing of OO and RDM that's of interest,
rather than the mixing of OO and DB.
Better minds than mine have attempted to deal with the impedance mismatch
between OO and RDM. In general, they have been disappointed by their own
results.
I suspect that most of them have gone about it in the wrong way. Most of
them have tried to project an object world onto a system of relations. What
they end up with is presistent data that captures the state of each object,
and its membership in a class. The behavior of objects that belong to any
class is generally defined outside of any coherent data model (even if it's
stored in a blob in a database).
I think it might be interesting to explore the whole concept backwards:
start with the idea that a table is just a specific class of object, and a
persistent table is just a specific class of persistent object. Then come
up with two things: how to store persistent objects and retrieve them when
necessary without regard for any data model; and how to get tables and
application objects to collaborate on common objectives.
This doesn't sound easy to me, at all. But it could be promising, provided
there is real value in OO. I don't know OO well enough to have a considered
opinion on that score.
Bob Badour
> "Victor Porton" <por...@narod.ru> wrote in message
> news:89b92dec-b710-4c24...@u10g2000prn.googlegroups.com...
>
>>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?
>
> First off, I think it's reall the mixing of OO and RDM that's of interest,
> rather than the mixing of OO and DB.
>
> Better minds than mine have attempted to deal with the impedance mismatch
> between OO and RDM. In general, they have been disappointed by their own
> results.
Nuh uh--Not me! I was not disappointed. Raising the programming language
from the low OO level to the higher RM level works great!
> I suspect that most of them have gone about it in the wrong way. Most of
> them have tried to project an object world onto a system of relations. What
> they end up with is presistent data that captures the state of each object,
> and its membership in a class. The behavior of objects that belong to any
> class is generally defined outside of any coherent data model (even if it's
> stored in a blob in a database).
>
> I think it might be interesting to explore the whole concept backwards:
> start with the idea that a table is just a specific class of object,
A great blunder.
and a
> persistent table is just a specific class of persistent object. Then come
> up with two things: how to store persistent objects and retrieve them when
> necessary without regard for any data model; and how to get tables and
> application objects to collaborate on common objectives.
>
> This doesn't sound easy to me, at all. But it could be promising, provided
> there is real value in OO. I don't know OO well enough to have a considered
> opinion on that score.
Have you read _The Third Manifesto_ ? D&D put a lot of thought into what
parts of OO have any real value.
David Cressey
"frebe" <fre...@gmail.com> wrote in message
news:081cbab9-89f6-4459...@s37g2000prg.googlegroups.com...
> The problem occurs when one try to use classes/objects as data
> structures. The relational model only allow relations as data
> structures. If you create classes like "employee", "customer", you
> will soon encounter big problems. But classes like "SSN", "telephone
> no", "zip code" will fit perfect together with the relational model.
Alan Kay once said "I don't like data structures". This was in the context
of some lecture on virtual reality. If you'll think about the consequences
of that opinion for a little while, you'll be devastated.
Dmitry A. Kazakov
> I think it might be interesting to explore the whole concept backwards:
> start with the idea that a table is just a specific class of object, and a
> persistent table is just a specific class of persistent object.
It so obvious that I wonder how one could even consider it "interesting,"
rather than mandatory. (BTW, persistence is an orthogonal issue to typed
relations. As well as concurrency is.)
The problem is that contemporary type systems in OOPL aren't very good to
handle this.
> This doesn't sound easy to me, at all. But it could be promising, provided
> there is real value in OO. I don't know OO well enough to have a considered
> opinion on that score.
Look, if typed systems had no sense, then why would anybody have table
cells typed? Once you accept usefulness of the latter, you should also
apply types to the former.
S Perryman
> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:
>>I think it might be interesting to explore the whole concept backwards:
>>start with the idea that a table is just a specific class of object
In an RDB, a "table" T is more than that.
It also represents the extent set (all instances) of T.
Then we have issues coming from the semantics of relational algebra.
For example:
In an object type system, what would the semantics of "joins" be ??
Should it have the same semantics as the relational model (a new type
tuple etc) ?? Or something else ??
If so, how would this new type be implemented/realised in the underlying
system (closures etc) when the join is done on two different object
instances ??
>Then come up with two things: how to store persistent objects and
>retrieve them when
>necessary without regard for any data model; and how to get tables and
>application objects to collaborate on common objectives.
For me, the big problem has always been the following :
SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
In the OO world, the problem is that for each instance of SomeType held
in Somewhere, the *implementation* of the property 'x' could be merely
an actual data value, or a serious computation process. That is the ADT/OO
way.
If the implementation is a computation process, there is also no guarantee
that each instance in Somewhere actually use the *same* implementation.
So all the optimisation etc that is achievable when you constrain x/y/z to
be raw data values only, is lost when you can no longer presume such
constraints.
It is because of this that I believe that the only paradigm that is capable
of providing the true engine for a relational info base that caters for
both OO and current RDBMS, is Functional programming (data values and
computation entities - functions - are treated the same, techniques such as
lazy evaluation, "copy on write" behaviour etc) .
With imperative prog langs (C, C++ , Java etc) , I can never see the
"mismatch impedence" ever being overcome. :-(
Regards,
Steven Perryman
-CELKO-
SD where Bjarne Stroustrup gave a talk on C++ and OO programming
(overhead slides, not Powerpoints!)
We asked about putting OO into SQL3 (the internal name of the working
draft Standard at that time). He said that Bells Labs had tried four
ways to do this and they were all failures. Bells Labs was the
smarter people on Earth at that time. He summary was that OO was good
for programming and bad for data.
Jan Hidders
They asked Bjarne Stroustrup? Why??
"I invented the term Object-Oriented, and I can tell you I did not
have C++ in mind."
- Alan Kay
-- Jan Hidders
Jan Hidders
> "frebe" <freb...@gmail.com> wrote in message
For some reason it doesn't have that effect on me. Without more
context it's a bit hard to say what he exactly meant, and I can think
of a few interpretations that range from the quite silly to the really
brilliant.
-- Jan Hidders
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>
>> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:
>
>>>I think it might be interesting to explore the whole concept backwards:
>>>start with the idea that a table is just a specific class of object
>
> In an RDB, a "table" T is more than that.
> It also represents the extent set (all instances) of T.
>
> Then we have issues coming from the semantics of relational algebra.
>
> For example:
>
> In an object type system, what would the semantics of "joins" be ??
>
> Should it have the same semantics as the relational model (a new type
> tuple etc) ?? Or something else ??
>
> If so, how would this new type be implemented/realised in the underlying
> system (closures etc) when the join is done on two different object
> instances ??
The same problem exists with any algebra less flat than numeric fields.
What is the type of Matrix x Matrix? What is the type of Velocity /
Duration? etc. The problem is rather fundamental and appears when we deal
with operations built on tuples of types.
The point is though that there is nothing in RA to deserve a special
treatment. That is actually is not an option, because we just cannot
provide a tailored solution for each and ever algebra.
> >Then come up with two things: how to store persistent objects and
> >retrieve them when
> >necessary without regard for any data model; and how to get tables and
> >application objects to collaborate on common objectives.
>
> For me, the big problem has always been the following :
>
> SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> In the OO world, the problem is that for each instance of SomeType held
> in Somewhere, the *implementation* of the property 'x' could be merely
> an actual data value, or a serious computation process. That is the ADT/OO
> way.
>
> If the implementation is a computation process, there is also no guarantee
> that each instance in Somewhere actually use the *same* implementation.
>
> So all the optimisation etc that is achievable when you constrain x/y/z to
> be raw data values only, is lost when you can no longer presume such
> constraints.
I see it different. First the above should be decomposed into primitive
operations over the types involved. There is at least the type of the table
and one of the cell. If SELECT were doubly dispatching, then one could
certainly provide different implementations for different combinations of
types.
To me a bigger problem is that RA is "computationally instable" in the
sense that a minor variations of same constructs may have massive effects
on resources consumptions, i.e. distributed overhead. OO tries to localize
effects by decoupling and encapsulation.
> It is because of this that I believe that the only paradigm that is capable
> of providing the true engine for a relational info base that caters for
> both OO and current RDBMS, is Functional programming (data values and
> computation entities - functions - are treated the same, techniques such as
> lazy evaluation, "copy on write" behaviour etc) .
Doesn't it just postpone the problem until run-time?
> With imperative prog langs (C, C++ , Java etc) , I can never see the
> "mismatch impedence" ever being overcome. :-(
That would be unfortunate, because I see a general problem with declarative
approaches as they try to sort things out per means of "magic." Without
magical devices at hand, we should design them by themselves. How?
Tegiri Nenashi
wrote:
> The same problem exists with any algebra less flat than numeric fields.
> What is the type of Matrix x Matrix?
Speaking of matrices, what do you possibly achieve by bundling
together the multiply(Matrix,Matrix) function together with the Matrix
data structure (other than loosing the symmetry: consider
matrix1.multiply(matrix2) method call how ugly is that)? Perhaps you
want a convenient listing of all the functions that have Matrix as a
first argument? Such a query shouldn't be a problem in any of
contemporary IDEs which *are* databases storing the source code. Or
you imply that you can define Matrix2x2 and subtype it into
GeneralMatrix? How silly is that (given that it is just simpler to
write general implementation). Or maybe one is advised to subclass the
other way?
If you serious about working with matrices (or any math) in your
application, then you design a mini-language which looks as Maple,
Matlab, or Mathematica.
> The point is though that there is nothing in RA to deserve a special
> treatment. That is actually is not an option, because we just cannot
> provide a tailored solution for each and ever algebra.
You mean you don't want to, or you are not qualified to?
> > For me, the big problem has always been the following :
>
> > SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> > s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> > In the OO world, the problem is that for each instance of SomeType held
> > in Somewhere, the *implementation* of the property 'x' could be merely
> > an actual data value, or a serious computation process. That is the ADT/OO
> > way.
If x is computed, then why don't you introduce a function that
computes it? In relational world a function call is a join. If this
function is not known at runtime, then what logic is involved in
selecting it? Can't the problem solved by dynamically constructing
this query?
> I see it different. First the above should be decomposed into primitive
> operations over the types involved. There is at least the type of the table
> and one of the cell. If SELECT were doubly dispatching, then one could
> certainly provide different implementations for different combinations of
> types.
What is SELECT? The whole query? The projection part? You OO guys
perfected the art speaking gibberish.
> To me a bigger problem is that RA is "computationally instable" in the
> sense that a minor variations of same constructs may have massive effects
> on resources consumptions, i.e. distributed overhead. OO tries to localize
> effects by decoupling and encapsulation.
You mean optimization? This is true, query optimization in relational
world is far more advanced than the one in the procedural programming
(which includes OO), and therefore it has more challenging problems.
> > It is because of this that I believe that the only paradigm that is capable
> > of providing the true engine for a relational info base that caters for
> > both OO and current RDBMS, is Functional programming (data values and
> > computation entities - functions - are treated the same, techniques such as
> > lazy evaluation, "copy on write" behaviour etc) .
Function is just a relation with functional dependency. It works
pretty much like an index. When a function is called from a query, it
is essentially a join, although there is no ambiguity which order this
join is evaluated. Therefore, in principle, FP is too weak to embrace
relational. It is more likely to happen the other way.
Relational programing has its weaknesses, but they are not what OO
propellerheads think. One missing part in the relational is formal
grammars and languages. The underlying theory of grammars and language
theory is Kleene algebra which is incompatible with RA. Witness how
regular expressions are integrated into SQL, as if there is no common
operation in relational algebra and algebra of strings...
H. S. Lahman
> 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?
Superficially they are not. An OO Class Model and a Data Model (nee
Entity Relationship Diagram) use essentially the same notation and both
are normalized using the same NF criteria.
The difference lies in the way the models are constructed and the way
that elements of the entire model (the Class Diagram is only one
component of an OOA/D model and cannot be separated from the other
components) play together. While the construction paradigms are not
directly incompatible, they will typically lead to different models
because different things are abstracted (problem space subject matters
vs data) and there are different goals in creating the model.
One manifestation of that is that the OO model will be highly tailored
to the unique rules and policies needed to solve the problem in hand. In
contrast, the goal of a Data Model is to represent data in a generic,
usage-independent manner.
Thus there is an inherent incompatibility but it lies in the goals and
construction methodologies rather than the notation syntax or element
semantics.
Generally speaking the OO paradigm is overkill for pure data processing
(i.e., classic CRUD/USER processing). In addition the RAD IDEs have
largely automated much of what one would construct from scratch in an OO
context. In doing so, though, the RAD IDEs have limited themselves to
situations where 2D layered models apply and one can provide 1:1 mapping
between the UI and the DB (i.e., form-based UIs that map conveniently to
stored tables). For that sort of pure data processing the RAD paradigm
is much better suited.
OTOH, when one has to solve a large problem using complex business rules
and policies in a manner that is unique to the problem, one begins to
realize the benefits of the OO paradigm -- particularly when the
requirements are volatile over time. But for those sorts of
applications, both the UI and the persistence mechanisms are of
relatively little importance. Thus the problem solution doesn't care if
one communicates with the user via a GUI, a web browser, or smoke
signals. Nor does the problem solution care if the data store is an RDB,
an OODB, flat files, or clay tablets.
So in OO applications, the UI and persistence access tend to be isolated
and encapsulated as low level service subsystems. The subsystem
interface then allows the mechanisms to be substituted transparently
without touching the problem solution.
A corollary is that because such subsystems are narrowly defined around
a particular subject matter like an RDB, one can abstract the invariants
of the paradigm. Thus for an RDB access subsystem one abstracts classes
like Schema, Table, Tuple, and Query rather than objects like Customer,
Order, and Shipment. That, in turn, allows one to express detailed
differences in terms of external configuration data. (In an RDB, the
schema itself becomes an identity mapping mechanism; one just needs to
link interface messages to schema names.) So typically one only needs to
design and implement a UI or DB paradigm once in an OO fashion; one can
then reuse the subsystem across different applications by simply
providing an appropriate configuration file and an interface (think: GoF
Facade pattern).
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
If you are solving CRUD/USER problems my advice would be to forget about
using OO and employ traditional RAD techniques. If you are solving
non-CRUD/USER problems, then I think all you have to do is isolate,
encapsulate, and abstract the invariants of the DB paradigm.
>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?
You might check out Fig. 17.2 in "Executable UML" by Mellor and Balcer.
The example is about abstracting a web browser UI but it is a good
example of abstracting the paradigm invariants. Exactly the same model
could be used for any application that talks to a web browser; all that
changes is what instances are initialized and what their attribute
values are -- all provided by configuration data. The extrapolation to a
model with objects like Table and Query should be fairly obvious.
--
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 Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> The same problem exists with any algebra less flat than numeric fields.
>> What is the type of Matrix x Matrix?
>
> Speaking of matrices, what do you possibly achieve by bundling
> together the multiply(Matrix,Matrix) function together with the Matrix
> data structure (other than loosing the symmetry: consider
> matrix1.multiply(matrix2) method call how ugly is that)?
Egh, prefix notation is just a notation, utterly misleading in most cases,
BTW. Semantically matrix multiplication deals with a triplet:
Multiply : Matrix x Matrix -> Matrix
So if Multiply is to be bound to an object then that has to be a tuple
(Matrix, Matrix, Matrix).
(If you think that OO = prefix notation, then it is not the OO I meant.)
> If you serious about working with matrices (or any math) in your
> application, then you design a mini-language which looks as Maple,
> Matlab, or Mathematica.
Really? And what if I am serious about working with something else too?
What about "serious" working with matrices *and* data bases? So next time
it should be me whining here about impedance between OO, DB and now a fancy
matrix language? What a brilliant future waits for us...
>> The point is though that there is nothing in RA to deserve a special
>> treatment. That is actually is not an option, because we just cannot
>> provide a tailored solution for each and ever algebra.
>
> You mean you don't want to, or you are not qualified to?
Neither. I do admire compiler construction, but customers became thrifty.
Silly they don't want to pay for developing a new programming language for
each other new project!
>> To me a bigger problem is that RA is "computationally instable" in the
>> sense that a minor variations of same constructs may have massive effects
>> on resources consumptions, i.e. distributed overhead. OO tries to localize
>> effects by decoupling and encapsulation.
>
> You mean optimization? This is true, query optimization in relational
> world is far more advanced than the one in the procedural programming
> (which includes OO), and therefore it has more challenging problems.
If solution is itself a problem... No, I didn't mean optimization. What
makes you believe in optimization? How reliable your belief is? Let you
look at a program, can you predict if it meets time and space constraints?
Before optimization? After optimization?
Bob Badour
> Responding to Porton...
>
>> 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?
>
> Superficially they are
[snipped lengthy bs complete with not 1 but 8 paradigms]
> fairly obvious.
Seldom in the history of mankind have so many words said so little.
(Lots of greek and latin roots always bode ill.)
Leslie Sanford
I cringe every time I see a thread crossposted to these two groups. Good
seldomn comes of it.
JOG
wrote:
> [snip]
> That would be unfortunate, because I see a general problem with declarative
> approaches as they try to sort things out per means of "magic." Without
> magical devices at hand, we should design them by themselves. How?
I'm wondering if that made more sense in the original russian?
mAsterdam
In practise we do it all the time.
In theory it can't work.
Leslie Sanford wrote:
Do you have an explanation for that?
Within one group, the easy way is: the other guys are so stupid.
Let's skip 'the other guys are so stupid' in this sub-thread.
I re-included cdt.
Let's cross this divide, and behave as if it is a real border.
This means you can't carry all of your preconceptions, and you will
have to adapt your language.
Any ideas except 'the other guys are so stupid'?
--
What you see depends on where you stand.
Dmitry A. Kazakov
> Leslie Sanford wrote:
>
>> Newsgroups: comp.object, comp.databases.theory
>> I cringe every time I see a thread crossposted to these two groups.
>> Good seldomn comes of it.
>
> Do you have an explanation for that?
>
> Any ideas except 'the other guys are so stupid'?
Market. Both OO and RDB are technologies with market products on sale.
Between us we can admit shortcomings and problems, but what if customers
would hear that? I don't accuse anybody of being hypocritical. Just once
anybody gets accustomed to doublespeak it becomes difficult for him to
switch back. It is like being confronted by a salesman in a shop. Relax, we
aren't to buy anything, just looking around...
P.S. I don't want to appear politically correct. IMO comp.object is less
aggressive than comp.databases.theory. People like topmind and frebe aren't
excommunicated regardless their propaganda. Does comp.databases.theory have
such?
frebe
> relational schema is embedded in a single application, state changes
> for different reasons and as different rates from behavior.
Would you mind giving examples of such changes? (You can skip the
"denormalisation for performance" example.)
> The object model, on the other hand, is optimized to address
> non-functional requirements (NFRs) related to the problem domain.
Doesn't that indicate that OO is pretty low-level, and that the
coupling between the logical model and the phisycal model is high?
Wouldn't it be better if we could separate the logical model handling
functional requirements, and the physical model handling non-
functional requirements?
> > Maybe somebody may suggest me some article about mixing together DB
> > and OOP?
>
> Because of the impedance mismatch, most OO systems use some form
> of object-relational mapping.
O/R mapping is not the best way of mixing together DB and OOP.
//frebe
mAsterdam
> mAsterdam wrote:
>
>> Leslie Sanford wrote:
>>
>>> Newsgroups: comp.object, comp.databases.theory
>>> I cringe every time I see a thread crossposted to these two groups.
>>> Good seldomn comes of it.
>> Do you have an explanation for that?
>>
>> Any ideas except 'the other guys are so stupid'?
>
> Market. Both OO and RDB are technologies with market products on sale.
Let's see if I can play with this using a metaphore.
So are, say, ships and engines (technologies with market products on
sale). Both have their own laws.
Designing a motorized boat requires a shared understanding
of some of them. There is a market for sailing boats,
there is a market for engines wchich can be used in other things than
ships. In this thread, we /are/ mixing. Shouldn't there be a market
for motorizing boats and for engines fit for use on a ship?
> Between us we can admit shortcomings and problems, but what if customers
> would hear that? I don't accuse anybody of being hypocritical. Just once
> anybody gets accustomed to doublespeak it becomes difficult for him to
> switch back. It is like being confronted by a salesman in a shop. Relax, we
> aren't to buy anything, just looking around...
>
> P.S. I don't want to appear politically correct.
> IMO comp.object is less
> aggressive than comp.databases.theory. People like topmind and frebe aren't
> excommunicated regardless their propaganda. Does comp.databases.theory have
> such?
This is a c.o politically correct
'the other guys are so stupid' question.
David Cressey
"mAsterdam" <mAst...@vrijdag.org> wrote in message
news:47ad7dc5$0$85790$e4fe...@news.xs4all.nl...
> Any ideas except 'the other guys are so stupid'?
My reaction is biased towards databases. That's where I'm coming from. No
apologies for that.
I'd like to suggest that the origins of the database appraoch and the
origins of the object oriented approach are very different. The database
approach started from an enterprise wide database and has scaled its way
down to tiny (conceptually) databases embedded in single applications. The
object oriented approach started with simulations and scaled its way up to
the problems that are being worked on now, including enterprise wide
solutions.
The fundamental problem to be addressed in database work is shareability.
If database data is not shareable, it's less valuable. Codd's work on
applying the relational model of data to the organization of databases for
large scale sharing of large scale data is fundamentally aimed at promoting
uniformity and thereby shareability without unduly limiting flexibility at
the low end. In the trade-off between uniformity and flexibility, the
relational model pushed the envelope so far out that all of the other
database contenders from the 1970s have been almost pushed off the map. I'm
thinking of the graph based DBMS products that dominated the market in circa
1978.
While theoretical advances such as those discussed in c.d.t. are important
in their own right, the fundamental market presence of the relational model
in practical work has settled on the SQL model of data. A lot of us mere
practicioners treat the SQL model and the relational model as variations on
the same theme. In terms of the internals of data storage, data blocks
that can contain table rows or index nodes make up the bulk of the data
whose management is transparent to the users of the DBMS.
The fundamental problem in simulations, as I see it, is autonomy. If each
unit in a simulation is not autonomous, the simulation will be constrained
at the system level to behave in ways that do not mimic the systems being
simulated. Objects are largely autonomous, and that is their great
utility. Objects are more autonomous than functions and procedures from the
great programming languages of the 1970s because objects carry state. That
is why OOP has displaced structured programming to a large extent.
In order for objects to collaborate they have to exchange signals (data).
In order to usefully exchange data, there has to be a common convention
regarding both the form and the content of the messages passed between
objects. Most of the OO stuff I've seen (which isn't very much)
concentrate on bilateral contracts between pairs of objects as to what the
form and content (meaning?) of exchanged messages will be.
Most of the best database work concentrates on universal contracts (although
the word "contracted" isn't widely used) governing the entire body of data
stored in a database, and a vast multitude of transactions that collaborate
(going forward in time) that adhere to the single contract or some subset of
it.
This looks overly contraining to the programmer accustomed to object
oriented thinking.
The bilateral contracts that tend to govern data exchange in object worlds
look chaotic to someone such as myself, schooled in database work.
This is the best I can do to describe the differences in non-pejorative
terms.
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> mAsterdam wrote:
>>
>>> Leslie Sanford wrote:
>>>
>>>> Newsgroups: comp.object, comp.databases.theory
>>>> I cringe every time I see a thread crossposted to these two groups.
>>>> Good seldomn comes of it.
>>> Do you have an explanation for that?
>>>
>>> Any ideas except 'the other guys are so stupid'?
>>
>> Market. Both OO and RDB are technologies with market products on sale.
>
> Let's see if I can play with this using a metaphore.
>
> So are, say, ships and engines (technologies with market products on
> sale). Both have their own laws.
> Designing a motorized boat requires a shared understanding
> of some of them. There is a market for sailing boats,
> there is a market for engines wchich can be used in other things than
> ships. In this thread, we /are/ mixing. Shouldn't there be a market
> for motorizing boats and for engines fit for use on a ship?
Ship and engine design are a proper engineering activities, while "software
engineering" is not. Exaggerating a lot, we could compare it with religions
and their "market products." Certainly a god is more worth if there is no
any other...
All technical disciplines are based on natural sciences which provide a
common ground for an interdisciplinary communication. This is not the case
for either OO or RDB. They not only compete in selling, often snake oil,
which questions whether they indeed are different disciplines, as your
example suggests. But also they do not have any elaborated scientific
disciplines backing them and shared by them. (I don't count mathematics,
which is as unspecific to software engineering, as for example English
language is)
> > People like topmind and frebe aren't
> > excommunicated regardless their propaganda. Does comp.databases.theory have
> > such?
> This is a c.o politically correct 'the other guys are so stupid' question.
I just wished to know it for statistics... So the answer is 'no'? (:-))
Patrick May
>> Even when the relational schema is embedded in a single
>> application, state changes for different reasons and as different
>> rates from behavior.
>
> Would you mind giving examples of such changes? (You can skip the
> "denormalisation for performance" example.)
Denormalization for performance of a particular application is a
perfectly valid example. Thanks for mentioning it. Another reason
for the different rates of change are that new behaviors can be added
without the need for additional data.
>> The object model, on the other hand, is optimized to address
>> non-functional requirements (NFRs) related to the problem domain.
>
> Doesn't that indicate that OO is pretty low-level, and that the
> coupling between the logical model and the phisycal model is high?
Not at all. OO supports the creation of abstractions that
represent concepts in both the problem and solution domain. Those
abstractions constitute a type of domain specific language (DSL) for
better expression of the solution implementation. Naturally, some
languages are better at this abstraction than others.
Some of the components in an OO system will be closer to details
such as data formats and network protocols while others will deal with
problem and solution concepts like service lease management and value
at risk calculations (to take two examples from a recent project).
Techniques like dependency inversion, among many others, allow these
components to be decoupled as much as possible, to allow
non-disruptive modification and extension.
The terms "high level" and "low level" tend to be more pejorative
than descriptive in these discussions. They make sense within a
particular paradigm, but generate more heat than light across paradigms.
> Wouldn't it be better if we could separate the logical model
> handling functional requirements, and the physical model handling
> non- functional requirements?
That can be easily done with OO techniques. In fact, one of the
selling points of the product suite I work with in my day job is that
the application code is insulated from the deployment topology. That
product is built on an OO design using OO languages.
>> > Maybe somebody may suggest me some article about mixing together
>> > DB and OOP?
>>
>> Because of the impedance mismatch, most OO systems use some
>> form of object-relational mapping.
>
> O/R mapping is not the best way of mixing together DB and OOP.
What alternative do you recommend?
Daniel T.
> Any ideas except 'the other guys are so stupid'?
I've been on comp.object a long time, never visited
comp.databases.theory. David Cressey admitted to having "not seen much"
of OO theory, so I will have to admit to having not seen much of
database theory, and even less of SQL.
I bring up SQL because Mr. Cressey says that, "A lot of us mere
practicioners [sic] treat the SQL model and the relational model as
variations on the same theme." If SQL is the exemplar of the relational
model, then let me propose that SmallTalk be used as the exemplar of the
OO model (some in comp.object will strongly disagree, primarily because
SmallTalk cannot handle multi-dispatching, but I'm willing to settle.)
Now I grant that I know very little of SQL, in fact I may know less of
SQL than Mr. Cressey knows of SmallTalk, :-) but it seems to me that
comparing the two languages, as exemplars, is fundamentally unfair to
SQL simply because as I understand it, SQL is *not* turing complete,
whereas SmallTalk is.
Since "mAsterdam" brought up the ship metaphor... Imagine two companies,
one makes engines, while the other makes whole boats (engine included.)
Even if the first company's engines are superior to the engines made by
the second company, is it really fair to compare which of the companies'
products are the best for going out to sea? I think not.
In response to mAsterdam's call for a civilized discussion of the pros
and cons of both theories, I can't say much because I only know one side
of the argument. But I will be following the thread in the hopes of
learning something.
Patrick May
Ah, an idealist. I love the smell of them being burned by their
own side in the morning....
Seriously, I wish you luck in this endeavor. My thoughts on this
are that different approaches ("paradigms", for lack of a better term)
are more suited to particular problem domains. Not particularly
profound, I know. The problem seems to stem from an all too common
desire, perhaps even a deep-seated human need, to identify with a
single paradigm. It's the Highlander Principle in software: There
can only be one!
I'm old enough to have made the transition from client-server
systems written in C and SQL (Oracle 3 and 4, no less) to OO, first
with Zortech C++ and then other languages. The people I know who went
through that transition are far less likely to be single-paradigm
bigots than people who know only Java (damn young whippersnappers)
because they have personally experienced the costs and benefits of
each set of techniques and idioms.
Working in a variety of domains (both problem and solution) seems
to ameliorate single-paradigm bigotry as well. People who have spent
their careers with big iron databases often lack the context to
understand the benefits of other paradigms, just as do newly minted
grads who know only Java. One of my favorite interview questions is
"What do you like best about your favorite programming language or
environment and what would you change about it if you could?" Anyone
who can't think of an improvement is out the door.
I prefer to work with people who understand procedural,
relational, OO, and functional programming. The boundaries between
these paradigms are not sharp -- useful techniques span paradigms.
Ultimately I'm looking for a gestalt development environment that
leverages the benefits of the superset of these techniques to deliver
high quality software. That's the real goal, after all.
Bob Badour
> "mAsterdam" <mAst...@vrijdag.org> wrote in message
> news:47ad7dc5$0$85790$e4fe...@news.xs4all.nl...
>
>>Any ideas except 'the other guys are so stupid'?
>
> My reaction is biased towards databases. That's where I'm coming from. No
> apologies for that.
>
> I'd like to suggest that the origins of the database appraoch and the
> origins of the object oriented approach are very different. The database
> approach started from an enterprise wide database and has scaled its way
> down to tiny (conceptually) databases embedded in single applications. The
> object oriented approach started with simulations and scaled its way up to
> the problems that are being worked on now, including enterprise wide
> solutions.
Did you see the sample code I wrote for a simulation in D a year or two ago?
[snip]
frebe
> >> application, state changes for different reasons and as different
> >> rates from behavior.
>
> > Would you mind giving examples of such changes? (You can skip the
> > "denormalisation for performance" example.)
>
> Denormalization for performance of a particular application is a
> perfectly valid example.
Unless your database supports materialized views.
> Another reason
> for the different rates of change are that new behaviors can be added
> without the need for additional data.
Yes, pretty obvious. The schema is the foundation of the application.
There are many reason to change the application stack on top of the
schema. But do you have some example of a schema that need to be
changed, and the behavior doesn't need to change?
> >> The object model, on the other hand, is optimized to address
> >> non-functional requirements (NFRs) related to the problem domain.
>
> > Doesn't that indicate that OO is pretty low-level, and that the
> > coupling between the logical model and the phisycal model is high?
>
> Not at all. OO supports the creation of abstractions that
> represent concepts in both the problem and solution domain.
And the abstractions for concepts in the problem domain doesn't have
to be optimized to address non-functional requirements?
> The terms "high level" and "low level" tend to be more pejorative
> than descriptive in these discussions. They make sense within a
> particular paradigm, but generate more heat than light across paradigms.
I might have a naive definition of "high level" and "low level": If
you implement a solution using two different tools, the solution that
has less lines of source code and takes less time to implement, is the
most high-level.
> >> > Maybe somebody may suggest me some article about mixing together
> >> > DB and OOP?
>
> >> Because of the impedance mismatch, most OO systems use some
> >> form of object-relational mapping.
>
> > O/R mapping is not the best way of mixing together DB and OOP.
>
> What alternative do you recommend?
My recommendation is that if you already are using a database, you
should not use objects as data structures. That is job is supposed to
be done by the database.
//frebe
David Cressey
"Daniel T." <dani...@earthlink.net> wrote in message
news:daniel_t-2CAF35...@earthlink.vsrv-sjc.supernews.net...
> mAsterdam <mAst...@vrijdag.org> wrote:
>
> > Any ideas except 'the other guys are so stupid'?
>
> I've been on comp.object a long time, never visited
> comp.databases.theory. David Cressey admitted to having "not seen much"
> of OO theory, so I will have to admit to having not seen much of
> database theory, and even less of SQL.
>
> I bring up SQL because Mr. Cressey says that, "A lot of us mere
> practicioners [sic] treat the SQL model and the relational model as
> variations on the same theme." If SQL is the exemplar of the relational
> model, then let me propose that SmallTalk be used as the exemplar of the
> OO model (some in comp.object will strongly disagree, primarily because
> SmallTalk cannot handle multi-dispatching, but I'm willing to settle.)
>
> Now I grant that I know very little of SQL, in fact I may know less of
> SQL than Mr. Cressey knows of SmallTalk, :-) but it seems to me that
> comparing the two languages, as exemplars, is fundamentally unfair to
> SQL simply because as I understand it, SQL is *not* turing complete,
> whereas SmallTalk is.
Turing completeness is not, IMO, as important in a data sublanguage as it is
in a programming language. A Turing complete extension of SQL could be
made.
BTW, SQL is, strictly speaking, not in line with the relational model. The
differences were important to Ed Codd. They are also important to some of
the c.d.t. regulars. Smalltalk is closer to being mainstream in OOP than
SQL is to being mainstream in RM.
>
> Since "mAsterdam" brought up the ship metaphor... Imagine two companies,
> one makes engines, while the other makes whole boats (engine included.)
> Even if the first company's engines are superior to the engines made by
> the second company, is it really fair to compare which of the companies'
> products are the best for going out to sea? I think not.
>
Database theory and practice does not cover the same ground that programming
theory and practice does.
> In response to mAsterdam's call for a civilized discussion of the pros
> and cons of both theories, I can't say much because I only know one side
> of the argument. But I will be following the thread in the hopes of
> learning something.
If the past is any guide, the discussion will generate more heat than
light.
topmind
The problem with paradigm-potpourri is that its more expensive to hire
people who have sufficient experience in them all. The industry tends
to force programmers into managers or unemployment after about 15
years, and 15 years is not enough for most programmers to master that
many paradigms. And, I don't think the benefits of mixing is strong
enough to offset that either.
>
> Regards,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | Large scale, mission-critical, distributed OO
> | systems design and implementation.
> p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
-T-
topmind
Dmitry A. Kazakov wrote:
> P.S. I don't want to appear politically correct. IMO comp.object is less
> aggressive than comp.databases.theory. People like topmind and frebe aren't
> excommunicated regardless their propaganda.
Believe me, they've tried.
> Does comp.databases.theory have
> such?
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
topmind
In name only, actually. Most production code for custom apps is not
very OOP. It may use a lot of pre-packaged classes, but the code
itself is mostly procedural in OO clothing.
>
> In order for objects to collaborate they have to exchange signals (data).
> In order to usefully exchange data, there has to be a common convention
> regarding both the form and the content of the messages passed between
> objects. Most of the OO stuff I've seen (which isn't very much)
> concentrate on bilateral contracts between pairs of objects as to what the
> form and content (meaning?) of exchanged messages will be.
>
> Most of the best database work concentrates on universal contracts (although
> the word "contracted" isn't widely used) governing the entire body of data
> stored in a database, and a vast multitude of transactions that collaborate
> (going forward in time) that adhere to the single contract or some subset of
> it.
>
> This looks overly [constraining] to the programmer accustomed to object
> oriented thinking.
I think part of the problem is that there are not enough "nimble
RDBMS" or table engines around, with such ideas as dynamic columns and
dynamic tables. It's like judging OOP by only looking at Java and
Eiffel instead of Smalltalk and Python.
>
> The bilateral contracts that tend to govern data exchange in object worlds
> look chaotic to someone such as myself, schooled in database work.
>
> This is the best I can do to describe the differences in non-pejorative
> terms.
If there is rhyme and reason to OO designs, OO proponents are
obligated to show it. Instead we get different stories and black-box
anecdotes.
-T-
Patrick May
>> >> Even when the relational schema is embedded in a single
>> >> application, state changes for different reasons and as
>> >> different rates from behavior.
>>
>> > Would you mind giving examples of such changes? (You can skip the
>> > "denormalisation for performance" example.)
>>
>> Denormalization for performance of a particular application is
>> a perfectly valid example.
>
> Unless your database supports materialized views.
And if your application can accept that the data in those views
may be out of date.
>> Another reason for the different rates of change are that new
>> behaviors can be added without the need for additional data.
>
> Yes, pretty obvious. The schema is the foundation of the
> application.
Actually, it's the behavior that's the foundation of the
application. A relational schema may not be necessary at all or may
be simply an implementation choice.
> There are many reason to change the application stack on top of the
> schema. But do you have some example of a schema that need to be
> changed, and the behavior doesn't need to change?
In addition to denormalization for performance, examples where
the database is shared are trivial to find. Not all applications
change at the same rate, so not all applications need the same schema
changes.
With a single application database, distributed applications
demonstrate additional trivial scenarios. A new service or agent
might need data that is not of interest to existing services and
agents.
>> >> The object model, on the other hand, is optimized to
>> >> address non-functional requirements (NFRs) related to the
>> >> problem domain.
>>
>> > Doesn't that indicate that OO is pretty low-level, and that the
>> > coupling between the logical model and the phisycal model is high?
>>
>> Not at all. OO supports the creation of abstractions that
>> represent concepts in both the problem and solution domain.
>
> And the abstractions for concepts in the problem domain doesn't have
> to be optimized to address non-functional requirements?
Some may be involved in addressing NFRs such as performance,
scalability, high availability, resiliency, and so forth, certainly.
>> The terms "high level" and "low level" tend to be more
>> pejorative than descriptive in these discussions. They make sense
>> within a particular paradigm, but generate more heat than light
>> across paradigms.
>
> I might have a naive definition of "high level" and "low level": If
> you implement a solution using two different tools, the solution
> that has less lines of source code and takes less time to implement,
> is the most high-level.
That sounds closer to a definition of "expressiveness".
>> >> > Maybe somebody may suggest me some article about mixing
>> >> > together DB and OOP?
>>
>> >> Because of the impedance mismatch, most OO systems use some
>> >> form of object-relational mapping.
>>
>> > O/R mapping is not the best way of mixing together DB and OOP.
>>
>> What alternative do you recommend?
>
> My recommendation is that if you already are using a database, you
> should not use objects as data structures. That is job is supposed
> to be done by the database.
So your answer to the question "How do I mix OO and relational?"
is "Don't use OO." Succinct, but not particularly responsive.
Sincerely,
mAsterdam
> mAsterdam wrote:
>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>> Leslie Sanford wrote:
>>>>
>>>>> Newsgroups: comp.object, comp.databases.theory
>>>>> I cringe every time I see a thread crossposted to these two groups.
>>>>> Good seldomn comes of it.
>>>> Do you have an explanation for that?
>>>>
>>>> Any ideas except 'the other guys are so stupid'?
>>> Market. Both OO and RDB are technologies with market products on sale.
>> Let's see if I can play with this using a metaphore.
>>
>> So are, say, ships and engines (technologies with market products on
>> sale). Both have their own laws.
>> Designing a motorized boat requires a shared understanding
>> of some of them. There is a market for sailing boats,
>> there is a market for engines wchich can be used in other things than
>> ships. In this thread, we /are/ mixing. Shouldn't there be a market
>> for motorizing boats and for engines fit for use on a ship?
>
> Ship and engine design are a proper engineering activities, while "software
> engineering" is not. Exaggerating a lot, we could compare it with religions
> and their "market products." Certainly a god is more worth if there is no
> any other...
Metaphores only go so far. However, if you are extending it to
religion just to illustrate the depth of the divide and the
presence of the unknown, there is no need to do so.
No shipwright knows all there is to know about ships,
even about the ones of his own design.
Engines have come a long enough way to have that as well.
> All technical disciplines are based on natural sciences which provide a
> common ground for an interdisciplinary communication. This is not the case
> for either OO or RDB. They not only compete in selling, often snake oil,
> which questions whether they indeed are different disciplines, as your
> example suggests.
It does indeed. If studying OO and DB are not
different disciplines then their whole ground is common.
What is left is dogma, groupthink and language.
Does that explain the whole of the divide?
I don't think so.
> But also they do not have any elaborated scientific
> disciplines backing them and shared by them. (I don't count mathematics,
> which is as unspecific to software engineering, as for example English
> language is)
Though specialized formalisms do exist, math is helpfull
to all disciplines. So, yes.
I think it can't be the main source of the divide.
<interesting snip>
>>> People like topmind and frebe aren't
>>> excommunicated regardless their propaganda. Does comp.databases.theory have
>>> such?
>
>> This is a c.o politically correct 'the other guys are so stupid' question.
>
> I just wished to know it for statistics... So the answer is 'no'? (:-))
Table manners can be quite offensive.
mAsterdam
> mAsterdam wrote:
<unsnip>
>> Leslie Sanford wrote:
>> Newsgroups: comp.object, comp.databases.theory
>>
>> I cringe every time I see a thread crossposted to these two groups.
>> Good seldomn comes of it.
</unsnip>
> Any ideas except 'the other guys are so stupid'?
[snip]
> Since "mAsterdam" brought up the ship metaphor... Imagine two companies,
> one makes engines, while the other makes whole boats (engine included.)
> Even if the first company's engines are superior to the engines made by
> the second company, is it really fair to compare which of the companies'
> products are the best for going out to sea? I think not.
Metaphores only... etc. We have to constantly check wether the nuance
of a metaphore is still relevant to the topic. In this case, I think
it is. I am not asking to compare products. I am wondering why
problems, which are dealt with in practise every day, are not dealt
with in theory.
> In response to mAsterdam's call for a civilized discussion of the pros
> and cons of both theories, I can't say much because I only know one side
> of the argument. But I will be following the thread in the hopes of
> learning something.
While I would not mind such a discussion in a specific setting,
it is not what I am asking for. If it is just a matter of pros and
cons in general, let's just pick the best and get on.
OO and DB serve different purposes.
The balance should be situational.
mAsterdam
> mAsterdam writes:
>> Mixing OO and DB:
>> In practise we do it all the time.
>> In theory it can't work.
>>
>> Leslie Sanford wrote:
>>
>>> Newsgroups: comp.object, comp.databases.theory
>>> I cringe every time I see a thread crossposted to these two groups.
>>> Good seldomn comes of it.
>> Do you have an explanation for that?
>>
>> Within one group, the easy way is: the other guys are so stupid.
>> Let's skip 'the other guys are so stupid' in this sub-thread. I
>> re-included cdt.
>>
>> Let's cross this divide, and behave as if it is a real border. This
>> means you can't carry all of your preconceptions, and you will have
>> to adapt your language.
>>
>> Any ideas except 'the other guys are so stupid'?
>
> Ah, an idealist. I love the smell of them being burned by their
> own side in the morning....
Idealist - who, me? Don't know, I don't think so.
Anyway, the ones burning those who cross borders
are not on my side. They never were.
> Seriously, I wish you luck in this endeavor. My thoughts on this
> are that different approaches ("paradigms", for lack of a better term)
approach?
> are more suited to particular problem domains. Not particularly
> profound, I know. The problem seems to stem from an all too common
> desire, perhaps even a deep-seated human need, to identify with a
> single paradigm. It's the Highlander Principle in software: There
> can only be one!
>
> I'm old enough to have made the transition from client-server
> systems written in C and SQL (Oracle 3 and 4, no less) to OO, first
> with Zortech C++ and then other languages.
Zortech, because Borland did not like the name Zorland.
> The people I know who went
> through that transition are far less likely to be single-paradigm
> bigots than people who know only Java (damn young whippersnappers)
> because they have personally experienced the costs and benefits of
> each set of techniques and idioms.
>
> Working in a variety of domains (both problem and solution) seems
> to ameliorate single-paradigm bigotry as well. People who have spent
> their careers with big iron databases often lack the context to
> understand the benefits of other paradigms, just as do newly minted
> grads who know only Java. One of my favorite interview questions is
> "What do you like best about your favorite programming language or
> environment and what would you change about it if you could?" Anyone
> who can't think of an improvement is out the door.
>
> I prefer to work with people who understand procedural,
> relational, OO, and functional programming. The boundaries between
> these paradigms are not sharp -- useful techniques span paradigms.
> Ultimately I'm looking for a gestalt development environment that
> leverages the benefits of the superset of these techniques to deliver
> high quality software. That's the real goal, after all.
That is stricly one side of the fence - it is the goal for a
software development process.
The goal for a DB is to serve as a vehicle to manage data.
Paradigm, gestalt development environment, leverages the benefits of
the superset of these techniques, gestalt development, I'll requote:
>> Let's cross this divide, and behave as if it is a real border.
>> This means you can't carry all of your preconceptions,
>> and you will have to adapt your language.
Do I need to explain?
topmind
mAsterdam wrote:
> Patrick May wrote:
> > The people I know who went
> > through that transition are far less likely to be single-paradigm
> > bigots than people who know only Java (damn young whippersnappers)
> > because they have personally experienced the costs and benefits of
> > each set of techniques and idioms.
> >
> > Working in a variety of domains (both problem and solution) seems
> > to ameliorate single-paradigm bigotry as well. People who have spent
> > their careers with big iron databases often lack the context to
> > understand the benefits of other paradigms, just as do newly minted
> > grads who know only Java. One of my favorite interview questions is
> > "What do you like best about your favorite programming language or
> > environment and what would you change about it if you could?" Anyone
> > who can't think of an improvement is out the door.
> >
> > I prefer to work with people who understand procedural,
> > relational, OO, and functional programming. The boundaries between
> > these paradigms are not sharp -- useful techniques span paradigms.
> > Ultimately I'm looking for a gestalt development environment that
> > leverages the benefits of the superset of these techniques to deliver
> > high quality software. That's the real goal, after all.
>
> That is stricly one side of the fence - it is the goal for a
> software development process.
> The goal for a DB is to serve as a vehicle to manage data.
>
The line between those can be very fuzzy. It is possible to formulate
the vast majority of just about any app you see as "managing data",
especially if you have good data-centric tools. How far one goes is an
age-old battle.
-T-
Patrick May
> Patrick May wrote:
>> I prefer to work with people who understand procedural,
>> relational, OO, and functional programming. The boundaries between
>> these paradigms are not sharp -- useful techniques span paradigms.
>> Ultimately I'm looking for a gestalt development environment that
>> leverages the benefits of the superset of these techniques to
>> deliver high quality software. That's the real goal, after all.
>
> That is stricly one side of the fence - it is the goal for a
> software development process. The goal for a DB is to serve as a
> vehicle to manage data.
I disagree. Software is a means to an end, not an end in itself,
at least in the vast majority of commercial settings. Databases are
just one type of software. The end goal is to provide business
value. Quality software, meaning software that meets the current
needs of the business, that can be easily extended to meet future
needs, and that is economically feasible to develop, provides that
business value. No business really wants a database per se, but many
do want the benefits of rapid access to consistent business
information.
> Paradigm, gestalt development environment, leverages the benefits of
> the superset of these techniques, gestalt development, I'll requote:
>
>>> Let's cross this divide, and behave as if it is a real border.
>>> This means you can't carry all of your preconceptions, and you
>>> will have to adapt your language.
>
> Do I need to explain?
Evidently, because I don't accept that the divide exists in any
meaningful sense. I use multiple paradigms as the situation warrants
and I work with a number of people who do as well. They're all just
different tools, each with advantages and disadvantages. Grouping one
set of tools together and calling it "relational", another set "object
oriented", and another set "functional" is useful to identify those
that complement each other, but it's important to realize that those
sets are not disjoint. It's also important to realize that the tools
in each set complement each other _in a particular context_. In a
different context, that is, a different problem or solution domain,
different sets of tools may make sense.
There are more things in heaven and earth, mAsterdam, than are
dreamt of in your paradigms.
topmind
But OOP and relational often don't compliment each other, but instead
fight over territory. Unless clear and logical rules form that tell us
when to stop one and start the other, this problem is not small.
Product/domain classification systems are a prime example. If you
manage them in the database, then you don't need polymorphism (unless
you duplicate information unnecessarily). Further, the set-oriented
classification systems used in relational are often not compatible
with the DAG/tree-based classification systems preferred by OO.
It's not just where the classification is represented, but how.
Personally, I think sets are superior to DAG-based taxonomies for
managing variations-on-a-theme.
>
> There are more things in heaven and earth, mAsterdam, than are
> dreamt of in your paradigms.
>
> Regards,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | Large scale, mission-critical, distributed OO
> | systems design and implementation.
> p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
-T-
frebe
> frebe <freb...@gmail.com> writes:
> >> >> Even when the relational schema is embedded in a single
> >> >> application, state changes for different reasons and as
> >> >> different rates from behavior.
>
> >> > Would you mind giving examples of such changes? (You can skip the
> >> > "denormalisation for performance" example.)
>
> >> Denormalization for performance of a particular application is
> >> a perfectly valid example.
>
> > Unless your database supports materialized views.
>
> And if your application can accept that the data in those views
> may be out of date.
Unless you do "refresh on commit".
Having a denormalized schema is also a good way of introducing data
that is out of date. It is also an advantage if the RDBMS can handle
the consistency issues. If you try to handle them by yourself, it is
more likely that it will fail.
> With a single application database, distributed applications
> demonstrate additional trivial scenarios. A new service or agent
> might need data that is not of interest to existing services and
> agents.
The reason why the schema change is that the behavior change. Behavior
and schema doesn't change for different reasons.
> >> >> > Maybe somebody may suggest me some article about mixing
> >> >> > together DB and OOP?
>
> >> >> Because of the impedance mismatch, most OO systems use some
> >> >> form of object-relational mapping.
>
> >> > O/R mapping is not the best way of mixing together DB and OOP.
>
> >> What alternative do you recommend?
>
> > My recommendation is that if you already are using a database, you
> > should not use objects as data structures. That is job is supposed
> > to be done by the database.
>
> So your answer to the question "How do I mix OO and relational?"
> is "Don't use OO." Succinct, but not particularly responsive.
I didn't say that. Like I said before, classes may perfectly well be
used for defining types for relational attributes. Objects map to
attribute values, not to relations.
//frebe
David Cressey
"topmind" <top...@technologist.com> wrote in message
news:09e3c5bf-b099-46b1...@i29g2000prf.googlegroups.com...
>
>
> David Cressey wrote:
> > The fundamental problem in simulations, as I see it, is autonomy. If
each
> > unit in a simulation is not autonomous, the simulation will be
constrained
> > at the system level to behave in ways that do not mimic the systems
being
> > simulated. Objects are largely autonomous, and that is their great
> > utility. Objects are more autonomous than functions and procedures from
the
> > great programming languages of the 1970s because objects carry state.
That
> > is why OOP has displaced structured programming to a large extent.
>
> In name only, actually. Most production code for custom apps is not
> very OOP. It may use a lot of pre-packaged classes, but the code
> itself is mostly procedural in OO clothing.
>
A very analogous problem exists in many SQL databases in the field. At
least, the problem existed 7 years ago, and I believe persists to this day.
A large number of SQL database designers have only a primitive idea of how
the relational data model works, or how to use it wisely. They design
databases as if they were designing a network of linked records, just as
they would have in the 1970s.
Then they dress their design in relational clothing, and pass it off as
relational. As a consequence, what can really be done with a relational
system is frequently so completely misrepresented that the unwary form a
distorted view of what it's all about.
> >
> > In order for objects to collaborate they have to exchange signals
(data).
> > In order to usefully exchange data, there has to be a common convention
> > regarding both the form and the content of the messages passed between
> > objects. Most of the OO stuff I've seen (which isn't very much)
> > concentrate on bilateral contracts between pairs of objects as to what
the
> > form and content (meaning?) of exchanged messages will be.
> >
> > Most of the best database work concentrates on universal contracts
(although
> > the word "contracted" isn't widely used) governing the entire body of
data
> > stored in a database, and a vast multitude of transactions that
collaborate
> > (going forward in time) that adhere to the single contract or some
subset of
> > it.
> >
> > This looks overly [constraining] to the programmer accustomed to object
> > oriented thinking.
>
> I think part of the problem is that there are not enough "nimble
> RDBMS" or table engines around, with such ideas as dynamic columns and
> dynamic tables. It's like judging OOP by only looking at Java and
> Eiffel instead of Smalltalk and Python.
>
Your idea of "nimble" and my idea of "chaotic" might overlap. We are going
to have to watch out for that subthread if we are going to in fact exchange
useful views on OO and RDM, and not quickly degenerate into name calling.
David Cressey
"Patrick May" <p...@spe.com> wrote in message news:m2sl01s...@spe.com...
> mAsterdam <mAst...@vrijdag.org> writes:
> > Patrick May wrote:
> >> I prefer to work with people who understand procedural,
> >> relational, OO, and functional programming. The boundaries between
> >> these paradigms are not sharp -- useful techniques span paradigms.
> >> Ultimately I'm looking for a gestalt development environment that
> >> leverages the benefits of the superset of these techniques to
> >> deliver high quality software. That's the real goal, after all.
> >
> > That is stricly one side of the fence - it is the goal for a
> > software development process. The goal for a DB is to serve as a
> > vehicle to manage data.
>
> I disagree. Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings. Databases are
> just one type of software.
I would have said "DBMSes are just one type of software." Is that what you
meant?
I don't think of a database as "software".
I agree with much of your major point, by the way.
Dmitry A. Kazakov
So software engineering will do in the future. But presently there is no
hundreds of years behind us. Consider, year 2000 B.C., a discussion about
merits of whips against clubs for slave management. Surely slave management
is fundamental for ships propelling, slaves have to be arranged in rows,
etc...
>> All technical disciplines are based on natural sciences which provide a
>> common ground for an interdisciplinary communication. This is not the case
>> for either OO or RDB. They not only compete in selling, often snake oil,
>> which questions whether they indeed are different disciplines, as your
>> example suggests.
>
> It does indeed. If studying OO and DB are not
> different disciplines then their whole ground is common.
> What is left is dogma, groupthink and language.
> Does that explain the whole of the divide?
Yes, because the common ground is not understood and not even articulated.
When in a subthread Patrick May wrote about the goals of software design
(quality), you disagreed. In your metaphor, he just said that a ship should
float. You replied that it is not about ships. How can we discuss means
when there is no agreement on what we are going to achieve?
Anybody on my side of the fence would say that DB is merely a software. But
that is a consequence of an even more heretical concept that data is a
fiction, a product of some language. (So any distinction between DB and
DBMS is also fictional.) This is what divides us, not engineering
techniques.
> Table manners can be quite offensive.
from food's point of view...
Bob Badour
When did vehicles cease to be means to ends and become ends themselves?
mAsterdam
> mAsterdam writes:
>> Patrick May wrote:
>>> I prefer to work with people who understand procedural,
>>> relational, OO, and functional programming. The boundaries between
>>> these paradigms are not sharp -- useful techniques span paradigms.
>>> Ultimately I'm looking for a gestalt development environment that
>>> leverages the benefits of the superset of these techniques to
>>> deliver high quality software. That's the real goal, after all.
>> That is stricly one side of the fence - it is the goal for a
>> software development process. The goal for a DB is to serve as a
>> vehicle to manage data.
>
> I disagree.
Whith 'The goal for a DB is to serve as a vehicle to manage data.',
or with 'stricly one side of the fence', or with both?
> Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings.
Software is a business asset, not the business itself
'in the vast majority of commercial settings'.
That is just excluding software companies.
One can distinguish between their products and
the stuff they use to do their business - even
when they do eat their own dogfood.
I don't see the relevance of this exclusion (yet?).
If your point is just a proposal to look at it as
a means to an end - I'm ok with that.
> Databases are just one type of software.
Conflating database and the software supporting it, DBMS.
Do you need that? The further you are away from something
the less distinctions you see, of course, but when reasoning
about one part leads you to wrong conclusions about the whole,
you'll have to inspect more closely.
> The end goal is to provide business value.
Is data a business asset in your view?
> Quality software, meaning software that meets the current
> needs of the business, that can be easily extended to meet future
> needs, and that is economically feasible to develop, provides that
> business value. No business really wants a database per se, but many
> do want the benefits of rapid access to consistent business
> information.
Somewhat like answering 'Is data a business asset in your view?'
With 'not per se'.
Not accepting a reason of being is another way of
saying 'the other guys are so stupid'.
>> Paradigm, gestalt development environment, leverages the benefits of
>> the superset of these techniques, gestalt development, I'll requote:
>>
>>>> Let's cross this divide, and behave as if it is a real border.
>>>> This means you can't carry all of your preconceptions, and you
>>>> will have to adapt your language.
>> Do I need to explain?
>
> Evidently, because I don't accept that the divide exists in any
> meaningful sense.
So, nothing to mix. This denies the validity of the OP's question.
I'd snip the rest, but there was something of interest per se
in the remainder of your post.
> I use multiple paradigms as the situation warrants
> and I work with a number of people who do as well.
> They're all just different tools, each with advantages and disadvantages.
http://en.wikipedia.org/wiki/Paradigm currently says:
"Kuhn defines a scientific paradigm as:
* what is to be observed and scrutinized
* the kind of questions that are supposed to be asked and
probed for answers in relation to this subject
* how these questions are to be structured
* how the results of scientific investigations should be
interpreted",
and there is a link to a nice article:
http://www.mnsu.edu/comdis/kuster/Infostuttering/Paradigmparalysis.html
Liberal and overly selfconfident use of the word
paradigm hints at entrenchment within one, not the capability
of distinguishing the boundaries, their nature and how to
deal with them.
> Grouping one set of tools together and calling it "relational",
> another set "object oriented", and another set "functional"
> is useful to identify those that complement each other,
> but it's important to realize that those sets are not disjoint.
> It's also important to realize that the tools in each set
> complement each other _in a particular context_. In a
> different context, that is, a different problem or solution domain,
> different sets of tools may make sense.
Agreed. A consequence of this position is, though,
that it becomes crucial to recognize contexts,
particularity of situations and the divides between them.
> There are more things in heaven and earth, mAsterdam, than are
> dreamt of in your paradigms.
Queerer than we can suppose:
http://video.google.com/videoplay?docid=6308228560462155344
Patrick May
Clarification accepted, thank you.
> I agree with much of your major point, by the way.
As all right thinking people must. ;-)
Patrick May
>
> Conflating database and the software supporting it, DBMS.
Definitely sloppy wording on my part, clarified elsethread.
>> I use multiple paradigms as the situation warrants and I work with
>> a number of people who do as well. They're all just different
>> tools, each with advantages and disadvantages.
>
> http://en.wikipedia.org/wiki/Paradigm currently says:
> "Kuhn defines a scientific paradigm as:
>
> * what is to be observed and scrutinized
> * the kind of questions that are supposed to be asked and
> probed for answers in relation to this subject
> * how these questions are to be structured
> * how the results of scientific investigations should be
> interpreted",
> and there is a link to a nice article:
> http://www.mnsu.edu/comdis/kuster/Infostuttering/Paradigmparalysis.html
>
> Liberal and overly selfconfident use of the word paradigm hints at
> entrenchment within one, not the capability of distinguishing the
> boundaries, their nature and how to deal with them.
The word "paradigm" has evolved to have a less rigorous meaning
within software. I actually don't like the term thus applied, but I
was using it in the canonical sense for this context.
>> Grouping one set of tools together and calling it "relational",
>> another set "object oriented", and another set "functional" is
>> useful to identify those that complement each other, but it's
>> important to realize that those sets are not disjoint. It's also
>> important to realize that the tools in each set complement each
>> other _in a particular context_. In a different context, that is,
>> a different problem or solution domain, different sets of tools may
>> make sense.
>
> Agreed. A consequence of this position is, though, that it becomes
> crucial to recognize contexts, particularity of situations and the
> divides between them.
No argument here.
Patrick May
> On 10 Feb, 00:18, Patrick May <p...@spe.com> wrote:
>> >> Denormalization for performance of a particular application
>> >> is a perfectly valid example.
>>
>> > Unless your database supports materialized views.
>>
>> And if your application can accept that the data in those
>> views may be out of date.
>
> Unless you do "refresh on commit".
That still leaves a window during which the data can be out of
date. It also imposes certain performance costs that may or may not
be acceptable.
> Having a denormalized schema is also a good way of introducing data
> that is out of date.
How so? Regardless of the normalization of the schema,
operations should be ACID.
>> With a single application database, distributed applications
>> demonstrate additional trivial scenarios. A new service or agent
>> might need data that is not of interest to existing services and
>> agents.
>
> The reason why the schema change is that the behavior
> change. Behavior and schema doesn't change for different reasons.
As I pointed out, even with a database used only by a single,
albeit distributed, application, there are reasons for the schema to
change that do not require existing behaviors to change. Similarly,
there are behavior changes that do not impact the schema. This is
even more prevalent in databases used by multiple applications.
>> >> > O/R mapping is not the best way of mixing together DB and OOP.
>>
>> >> What alternative do you recommend?
>>
>> > My recommendation is that if you already are using a database,
>> > you should not use objects as data structures. That is job is
>> > supposed to be done by the database.
>>
>> So your answer to the question "How do I mix OO and
>> relational?" is "Don't use OO." Succinct, but not particularly
>> responsive.
>
> I didn't say that. Like I said before, classes may perfectly well be
> used for defining types for relational attributes. Objects map to
> attribute values, not to relations.
Do you have a reference to this technique being used in practice?
I'd need to see the details to understand what you mean.
mAsterdam
What matters here is: does the engineer know everythying there is to
know about his product? The answer is no - wether the product
is a ship, an engine, a database or a piece of software.
> Consider, year 2000 B.C., a discussion about
> merits of whips against clubs for slave management.
Yet another extension to the metaphore - you think it isn't
rich enough?
> Surely slave management
> is fundamental for ships propelling, slaves have to be arranged in rows,
> etc...
In your extension, you appear to map your slaves to data.
Slaves behave, objects do. Data doesn't.
>>> All technical disciplines are based on natural sciences which provide a
>>> common ground for an interdisciplinary communication. This is not the case
>>> for either OO or RDB. They not only compete in selling, often snake oil,
>>> which questions whether they indeed are different disciplines, as your
>>> example suggests.
>> It does indeed. If studying OO and DB are not
>> different disciplines then their whole ground is common.
>> What is left is dogma, groupthink and language.
>> Does that explain the whole of the divide?
>
> Yes, because the common ground is not understood and not even articulated.
All ground is common. This, like Patrick May's stance,
invalidates the OP's question.
> When in a subthread Patrick May wrote about the goals of software design
> (quality), you disagreed.
That is not what I disagreed with.
This is a serious misrepresentation.
You can read. Is it intentional?
> In your metaphor, he just said that a ship should
> float. You replied that it is not about ships.
Maybe you just misread it, maybe I said something in an unclear way.
Please quote the passage you are hinting at.
> How can we discuss means
> when there is no agreement on what we are going to achieve?
>
> Anybody on my side of the fence
Please describe the fence as seen from your side.
> would say that DB is merely a software.
> But that is a consequence of an even more heretical concept that data is
> a fiction, a product of some language. (So any distinction between DB
> and DBMS is also fictional.)
All models, all concepts are fictional, but we are
talking about shared fictions here, so that filosofical
insight does not help us here.
I see the same DB/DBMS conflation as Patrick made.
I asked Patrick, and I'm asking you:
Do you need that?
> This is what divides us, not engineering techniques.
>
>> Table manners can be quite offensive.
>
> from food's point of view...
You like rapid topic shifts?
frebe
> >> >> is a perfectly valid example.
>
> >> > Unless your database supports materialized views.
>
> >> And if your application can accept that the data in those
> >> views may be out of date.
>
> > Unless you do "refresh on commit".
>
> That still leaves a window during which the data can be out of
> date. It also imposes certain performance costs that may or may not
> be acceptable.
Doesn't "refresh on commit", refresh the materialized view within the
transaction?
Having redundant data may also impose certain performance costs that
may or may not be acceptable.
> > Having a denormalized schema is also a good way of introducing data
> > that is out of date.
>
> How so? Regardless of the normalization of the schema,
> operations should be ACID.
But it is up to the application programmer to make it ACID. Like you
said you might have other less well-written application accessing the
same schema, introducing update abnormalities. Database normalization
has many benifits. Denormalization has many disadvantages.
> >> With a single application database, distributed applications
> >> demonstrate additional trivial scenarios. A new service or agent
> >> might need data that is not of interest to existing services and
> >> agents.
>
> > The reason why the schema change is that the behavior
> > change. Behavior and schema doesn't change for different reasons.
>
> As I pointed out, even with a database used only by a single,
> albeit distributed, application, there are reasons for the schema to
> change that do not require existing behaviors to change.
Then it wouldn't be any problem for you to give some examples.
> Similarly, there are behavior changes that do not impact the schema.
I don't think we have a disagreement about this one.
> >> >> > O/R mapping is not the best way of mixing together DB and OOP.
>
> >> >> What alternative do you recommend?
>
> >> > My recommendation is that if you already are using a database,
> >> > you should not use objects as data structures. That is job is
> >> > supposed to be done by the database.
>
> >> So your answer to the question "How do I mix OO and
> >> relational?" is "Don't use OO." Succinct, but not particularly
> >> responsive.
>
> > I didn't say that. Like I said before, classes may perfectly well be
> > used for defining types for relational attributes. Objects map to
> > attribute values, not to relations.
>
> Do you have a reference to this technique being used in practice?
> I'd need to see the details to understand what you mean.
What part didn't you understand? Every relational attribute (table
colum) has a type (domain). Classes are suitable for defining types.
Examples of relational attributes are dates, telephon numbers, zip
codes, images, audio clips. But entities like customer, employee,
invoice, are not good candidates for classes, if you are using the
relational model.
//frebe
mAsterdam
> mAsterdam writes:
>> Patrick May wrote:
>>> Databases are just one type of software.
>> Conflating database and the software supporting it, DBMS.
>
> Definitely sloppy wording on my part, clarified elsethread.
Ok.
For the sake of discussion I'd prefer it if you would alert snips.
<unsnip>
>> Is data a business asset in your view?
</unsnip>
[snip prelude]
> The word "paradigm" has evolved to have a less rigorous meaning
> within software. I actually don't like the term thus applied, but I
> was using it in the canonical sense for this context.
Ok.
[snip agreement]
Dmitry A. Kazakov
> In your extension, you appear to map your slaves to data.
> Slaves behave, objects do. Data doesn't.
If data did not behave how would it be possible to use data?
[What is data, in your opinion? On my side: data are values semantically
bound to some entities from the problem space. (The type of values
describes the behavior of data.)]
>> Yes, because the common ground is not understood and not even articulated.
>
> All ground is common. This, like Patrick May's stance,
> invalidates the OP's question.
Yes.
>> When in a subthread Patrick May wrote about the goals of software design
>> (quality), you disagreed.
>
> That is not what I disagreed with.
So you agree that software design could be such a ground?
>> In your metaphor, he just said that a ship should
>> float. You replied that it is not about ships.
>
> Maybe you just misread it, maybe I said something in an unclear way.
> Please quote the passage you are hinting at.
"That is stricly one side of the fence - it is the goal for a software
development process. The goal for a DB is to serve as a vehicle to manage
data."
If the ultimate goal is same, then managing the thing called data is mere
one possible thread of the process.
> Please describe the fence as seen from your side.
In short and technically, it is refusal to view tables as typed values.
> I see the same DB/DBMS conflation as Patrick made.
> I asked Patrick, and I'm asking you:
> Do you need that?
Yes, I do, especially when talking about a common ground.
JOG
wrote:
> On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:
> > In your extension, you appear to map your slaves to data.
> > Slaves behave, objects do. Data doesn't.
>
> If data did not behave how would it be possible to use data?
>
> [What is data, in your opinion?
Data. Lots of datum - from latin, meaning statement of fact. Predicate
and value in FOL. A value without description is of course just
noise.
> On my side: data are values semantically bound
"Semantically bound"? yuck, I think you need to break that down to
brass tacks.
> to some entities from the problem space. (The type of values describes the behavior of data.)]
Entities feature in or are extracted from data, not the other way
around. Data is certainly not "bound to" entities, which is hand wavy
terminology at best. My concern for OO is not that its mechanisms are
not useful, but that it gives objects primacy before data, instead of
the other way around as per the definition of the term.
Entities don't store data. Rather, observed data allows us to
formulate entities.
Dmitry A. Kazakov
> On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:
>>> In your extension, you appear to map your slaves to data.
>>> Slaves behave, objects do. Data doesn't.
>>
>> If data did not behave how would it be possible to use data?
>>
>> [What is data, in your opinion?
>
> Data. Lots of datum - from latin, meaning statement of fact. Predicate
> and value in FOL. A value without description is of course just
> noise.
"Fact" in which domain? Or maybe you simply mean that data is a set of
statements in some formal language, without any particular meaning. Then
those aren't facts, but mere a program.
>> On my side: data are values semantically bound
>
> "Semantically bound"? yuck, I think you need to break that down to
> brass tacks.
Sure. After you have applied inference rules to the bunch of statements
called data, you get another bunch of statements which has as little sense
as the former had, unless there is a meaning attached to. This meaning
necessary lies outside the formal system.
>> to some entities from the problem space. (The type of values describes the behavior of data.)]
>
> Entities feature in or are extracted from data, not the other way
> around.
Entities extracted from data? Cool, if I only could extract warmth from 22
degrees Celsius, that would reduce my energy bills!
> My concern for OO is not that its mechanisms are
> not useful, but that it gives objects primacy before data, instead of
> the other way around as per the definition of the term.
(There is no any primacy as data just do not exist alone.) But returning to
the question about fences, if OO mechanisms are useful, what is wrong with
using them? What prevents you from talking about mechanisms rather than
pushing [dubious] philosophical agenda?
> Entities don't store data. Rather, observed data allows us to
> formulate entities.
I cannot decipher that. When I referred to entities I meant ones in the
problem space. "Observing data," makes me think that you believe in data
physically existing in the real world. I never saw the number 123 out
there, maybe I should work less, and more frequently look out of the window
in order to spot it...
Patrick May
>> >> >> Denormalization for performance of a particular
>> >> >> application is a perfectly valid example.
>>
>> >> > Unless your database supports materialized views.
>>
>> >> And if your application can accept that the data in those
>> >> views may be out of date.
>>
>> > Unless you do "refresh on commit".
>>
>> That still leaves a window during which the data can be out of
>> date. It also imposes certain performance costs that may or may
>> not be acceptable.
>
> Doesn't "refresh on commit", refresh the materialized view within
> the transaction?
That's one possible semantic. Another is to update post-commit,
in order to minimize the performance impact of materialized views on
the underlying schema.
> Having redundant data may also impose certain performance costs that
> may or may not be acceptable.
Certainly, but denormalization for performance is a relatively
common technique. It does provide value in some environments.
>> > Having a denormalized schema is also a good way of introducing
>> > data that is out of date.
>>
>> How so? Regardless of the normalization of the schema,
>> operations should be ACID.
>
> But it is up to the application programmer to make it ACID. Like you
> said you might have other less well-written application accessing
> the same schema, introducing update abnormalities. Database
> normalization has many benifits. Denormalization has many
> disadvantages.
Normalization is certainly to be preferred, but the benefits of
it must be balanced against its costs.
>> >> With a single application database, distributed
>> >> applications demonstrate additional trivial scenarios. A new
>> >> service or agent might need data that is not of interest to
>> >> existing services and agents.
>>
>> > The reason why the schema change is that the behavior
>> > change. Behavior and schema doesn't change for different reasons.
>>
>> As I pointed out, even with a database used only by a single,
>> albeit distributed, application, there are reasons for the schema
>> to change that do not require existing behaviors to change.
>
> Then it wouldn't be any problem for you to give some examples.
I've already done so. Denormalization for performance. Addition
of new functionality. We could add refactoring to take advantage of
new (or existing but unused) functionality of the RDBMS. Support for
additional reports (a subset of addition of new functionality).
I'm not sure where you're going with this. What point are you
trying to make?
>> >> So your answer to the question "How do I mix OO and
>> >> relational?" is "Don't use OO." Succinct, but not particularly
>> >> responsive.
>>
>> > I didn't say that. Like I said before, classes may perfectly well
>> > be used for defining types for relational attributes. Objects map
>> > to attribute values, not to relations.
>>
>> Do you have a reference to this technique being used in
>> practice? I'd need to see the details to understand what you mean.
>
> What part didn't you understand? Every relational attribute (table
> colum) has a type (domain). Classes are suitable for defining types.
> Examples of relational attributes are dates, telephon numbers, zip
> codes, images, audio clips. But entities like customer, employee,
> invoice, are not good candidates for classes, if you are using the
> relational model.
That ignores the fact that OO is about implementing behavior. In
many systems there is no need for the relational model, except as an
interface to other systems that happen to be database centric.
Can you provide an example of an RDBMS that integrates with
classes as you describe?
JOG
wrote:
> On Sun, 10 Feb 2008 10:29:58 -0800 (PST), JOG wrote:
> > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:
> >>> In your extension, you appear to map your slaves to data.
> >>> Slaves behave, objects do. Data doesn't.
>
> >> If data did not behave how would it be possible to use data?
>
> >> [What is data, in your opinion?
>
> > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > and value in FOL. A value without description is of course just
> > noise.
>
> "Fact" in which domain? Or maybe you simply mean that data is a set of
> statements in some formal language, without any particular meaning. Then
> those aren't facts, but mere a program.
Fact, as in... "statement of fact". As in a true proposition. That's
it. Nothing else.
Let's cut the blather, it's not necessary.
>
> >> On my side: data are values semantically bound
>
> > "Semantically bound"? yuck, I think you need to break that down to
> > brass tacks.
>
> Sure. After you have applied inference rules to the bunch of statements
> called data, you get another bunch of statements which has as little sense
> as the former had, unless there is a meaning attached to. This meaning
> necessary lies outside the formal system.
Fair enough, that makes sense.
>
> >> to some entities from the problem space. (The type of values describes the behavior of data.)]
>
> > Entities feature in or are extracted from data, not the other way
> > around.
>
> Entities extracted from data? Cool, if I only could extract warmth from 22
> degrees Celsius, that would reduce my energy bills!
Yes, and whatever other sentences you want to type in that don't make
sense, you fill your boots.
>
> > My concern for OO is not that its mechanisms are
> > not useful, but that it gives objects primacy before data, instead of
> > the other way around as per the definition of the term.
>
> (There is no any primacy as data just do not exist alone.)
There is no need to pluralize data. It has long been acceptable to use
the term in the singular.
> But returning to
> the question about fences, if OO mechanisms are useful, what is wrong with
> using them?
They bind you into a single brittle conceptual model, as opposed to
offering a neutral logical model from which different conceptual
models may be extracted. Lordy, why am I bothering? You aren't
interested in expanding your knowledge are you?
> What prevents you from talking about mechanisms rather than
> pushing [dubious] philosophical agenda?
Blah, blah. I have no agenda apart from building good systems. I use
both OO and RM, and understand the strength and weaknesses of both. I
gave you a definition of data, but you're gonna have to google the
difference between conceptual and logical models.
>
> > Entities don't store data. Rather, observed data allows us to
> > formulate entities.
>
> I cannot decipher that. When I referred to entities I meant ones in the
> problem space. "Observing data," makes me think that you believe in data
> physically existing in the real world. I never saw the number 123 out
> there, maybe I should work less, and more frequently look out of the window
> in order to spot it...
You "never saw the value '123' out there" in the real world? Good
grief. You've not seen a phone number written down either then, or a
room number, or heard of lotus 123? Right you are then.
Look I'm rapidly becoming aware that your responses are incoherent,
and as such are almost impossible to respond to sensibly. Perhaps
someone from comp.object can let me know if you normally offer any
salient points and there is merely a language issue at hand here, or
whether I'm wasting my time. There is no point in my posting again
until then.
mAsterdam
> mAsterdam wrote:
>
>> In your extension, you appear to map your slaves to data.
>> Slaves behave, objects do. Data doesn't.
>
> If data did not behave how would it be possible to use data?
Being active is not, as your question presupposes,
a prerequisite to being used.
> [What is data, in your opinion?
Recorded facts.
In the context of electronic dataprocessing
it only makes sense to talk about data when the medium on
which they are recorded is readable by some mechanism to
achieve electronic representation, but that is not inherent
to data.
> On my side: data are values semantically
> bound to some entities from the problem space.
The one recording the facts (or the designer of the datacapture)
will have some entities in mind when recording/capturing the data.
To make sure that the interpretation won't be far off, a
description in terms of entities (from the problem space) helps.
This does not garantee that the interpretation in terms of entities
of formerly collected facts will stay the same.
"semantically bound" suggests a formalism.
Did you intend that? If so which one?
> (The type of values describes the behavior of data.)]
How? I don't understand what you are saying here -
this may be a language thing, though.
An example might clarify.
>>> Yes, because the common ground is not understood and not even articulated.
>> All ground is common. This, like Patrick May's stance,
>> invalidates the OP's question.
>
> Yes.
>
>>> When in a subthread Patrick May wrote about the goals of software design
>>> (quality), you disagreed.
>> That is not what I disagreed with.
>
> So you agree that software design could be such a ground?
It is not clear what you are asking me to agree to.
>>> In your metaphor, he just said that a ship should
>>> float. You replied that it is not about ships.
>> Maybe you just misread it, maybe I said something in an unclear way.
>> Please quote the passage you are hinting at.
>
> "That is stricly one side of the fence - it is the goal for a software
> development process. The goal for a DB is to serve as a vehicle to manage
> data."
I do not see how you can read this as:
"In your metaphor, he just said that a ship should
float. You replied that it is not about ships."
Please state your own opinions.
You are not doing a good job stating mine.
> If the ultimate goal is same, then managing the thing called data is mere
> one possible thread of the process.
That does not follow.
Furthermore: after the process stops, the data remains.
>> Please describe the fence as seen from your side.
>
> In short and technically, it is refusal to view tables as typed values.
>
>> I see the same DB/DBMS conflation as Patrick made.
>> I asked Patrick, and I'm asking you:
>> Do you need that?
>
> Yes, I do, especially when talking about a common ground.
Patrick May considered his DB/DBMS conflation just sloppy,
you need it. Please elaborate.
Up to now your arguments do not yet
step outside the 'the other guys are so stupid' box.
Are you planning to? I specifically asked to skip those.
David BL
> On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> > [What is data, in your opinion?
>
> Data. Lots of datum - from latin, meaning statement of fact. Predicate
> and value in FOL. A value without description is of course just
> noise.
Latin datum is past participle of dare, "to give". What make you say
data is necessarily a set of propositions? Are you suggesting a value
is meaningless without a proposition? Why can't a datum just be a
value? Wouldn't you say a recorded image is data?
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> mAsterdam wrote:
>>
>>> In your extension, you appear to map your slaves to data.
>>> Slaves behave, objects do. Data doesn't.
>>
>> If data did not behave how would it be possible to use data?
>
> Being active is not, as your question presupposes,
> a prerequisite to being used.
No, I didn't meant that. Behavior is independent on who acts on whom.
Consider it as a list of all things you could ever do with data.
>> [What is data, in your opinion?
>
> Recorded facts.
>
> In the context of electronic dataprocessing
> it only makes sense to talk about data when the medium on
> which they are recorded is readable by some mechanism to
> achieve electronic representation, but that is not inherent
> to data.
True. Inherent is presence of some reading device.
But why is recording essential? It throws in many things which seem
unrelated or constraining, such as time aspect and physical presence. Or to
put it otherwise, can you consider unrecorded, not memorized data? May I
translate data into a different representation and then erase the original
record? Will data still be there?
>> On my side: data are values semantically
>> bound to some entities from the problem space.
>
> The one recording the facts (or the designer of the datacapture)
> will have some entities in mind when recording/capturing the data.
> To make sure that the interpretation won't be far off, a
> description in terms of entities (from the problem space) helps.
>
> This does not garantee that the interpretation in terms of entities
> of formerly collected facts will stay the same.
Yes. That cannot be guaranteed.
> "semantically bound" suggests a formalism.
> Did you intend that? If so which one?
Actually it suggests absence of formalism. A formal system operates on data
without any clue of the meaning of.
>> (The type of values describes the behavior of data.)]
>
> How? I don't understand what you are saying here -
> this may be a language thing, though.
> An example might clarify.
Consider the value 1. It has no behavior (and no use) so long you don't
tell us its type. It you say that 1 is an integer, then its behavior will
include "has negative inverse." If the type is Positive, then the behavior
will be "no negative inverse", "can be squared in R" etc.
(Behavior does not presume anything like tiny cogwheels hidden inside 1.
The cogwheels are rather big and all outside (:-))
>> If the ultimate goal is same, then managing the thing called data is mere
>> one possible thread of the process.
>
> That does not follow.
> Furthermore: after the process stops, the data remains.
Really? You wrote just above:
"it only makes sense to talk about data when the medium on
which they are recorded is readable by some mechanism to
achieve electronic representation, but that is not inherent
to data."
Which is all true. So let you have a medium without a process that can read
it, what did remain of data? It what sense do data remain? As a possibility
to start a process by some other process which still runs? Consider it on
the example with 1.
>>> Please describe the fence as seen from your side.
>>
>> In short and technically, it is refusal to view tables as typed values.
>>
>>> I see the same DB/DBMS conflation as Patrick made.
>>> I asked Patrick, and I'm asking you:
>>> Do you need that?
>>
>> Yes, I do, especially when talking about a common ground.
>
> Patrick May considered his DB/DBMS conflation just sloppy,
> you need it.
No, his first, maybe unconscious, reaction was right. DB in interesting to
us part is software, or else we should have been in sci.physics.
Alexandr Savinov
> 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?
Here is a short paper describing one possible approach to this problem:
Informal Introduction into the Concept-Oriented Programming:
http://conceptoriented.com/papers/CopInformalIntroduction.html
The paper is aimed at formulating main principles of the
concept-oriented programming but section 8 gives a general idea what the
concept-oriented data model is.
Some discussion can be found here:
http://www.theserverside.com/news/thread.tss?thread_id=47699
JOG
> On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> > > [What is data, in your opinion?
>
> > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > and value in FOL. A value without description is of course just
> > noise.
>
> Latin datum is past participle of dare, "to give". What make you say
> data is necessarily a set of propositions?
The OED. "Facts, esp. numerical facts, collected together for
reference or information." The etymology stems from 'dare', because
facts are always communicated or "given". I understand of course that
the term is thrown around wantonly and ambiguosly nowadays, but as
data theorists, we shouldn't be party to that imo ;)
> Are you suggesting a value
> is meaningless without a proposition? Why can't a datum just be a
> value?
Because ta value has to be associated with something. Hofstadter gave
a good example of this with the groove modulations on a vinyl record.
To us they are (musical) data, to an alien not knowing their context,
it is not. You need the context.
> Wouldn't you say a recorded image is data?
Of course, so long as I know it's an image. If its just ones and
zero's stored in a computer, without anyway of telling they represent
a picture, then it is simply noise.
David BL
Let's indeed assume we know how to interpret the 1's and 0's as an
image. So what have we got? Nothing but a *value*. We can display
it. We can comment on whether we like it - even if we haven't a clue
where it came from. But I don't see any sense in which the image
value gives us any statements of fact beyond the specification of a
value. A value simply "is".
I would suggest that a lot of the data in the world is characterised
more closely as "interesting values" than collections of
propositions. For example a recorded poem is an interesting value.
So also a movie, mp3, book, web page or source code listing.
JOG
No, you now have a value with applied context. That creates a fact.
You now therefore have data. It's simple to show - consider "1000001".
Thats currently a value, but its not data. Its only data when I store
it, and state one of the following:
"100001" is a text string
"100001" is an integer (i.e. 65)
"100001" is an ascii character (i.e. A)
etc..
> We can display
> it. We can comment on whether we like it - even if we haven't a clue
> where it came from. But I don't see any sense in which the image
> value gives us any statements of fact beyond the specification of a
> value. A value simply "is".
>
> I would suggest that a lot of the data in the world is characterised
> more closely as "interesting values" than collections of
> propositions.
You cannot store these interesting values without implicitly stating
some fact about them.
David BL
These "facts" are all tautologies that are true whether you record
them or not. I dispute your premise that the purpose of the data in
this case is to state a fact that is known a-priori to be true. If
that is its purpose then it conveys precisely zero information.
> > We can display
> > it. We can comment on whether we like it - even if we haven't a clue
> > where it came from. But I don't see any sense in which the image
> > value gives us any statements of fact beyond the specification of a
> > value. A value simply "is".
>
> > I would suggest that a lot of the data in the world is characterised
> > more closely as "interesting values" than collections of
> > propositions.
>
> You cannot store these interesting values without implicitly stating
> some fact about them.
By definition, when a value is specified, its type is specified as
well (except possibly if type inheritance is supported).
C. Date states the following in "Introduction to Database Systems",
section 5.2, and subsection titled "Values and Variables are typed":
"Every value has ... some type...Note that,
by definition, a given value always has
exactly one type, which never changes.
[footnote: except possibly if type
inheritance is supported]"
When a particular value like the integer 73 is specified, there is no
implicit fact being specified. The statement that the integer 73
exists in any absolute sense is entirely metaphysical and meaningless
within computer science.
Robert Martin
> 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?
The concepts are orthogonal. Objects are not tables. Tables are not
objects. The many efforts to try to force tables and objects together
always cause trouble. Things work better when you recognize the
benefits of tables, and the benefits of objects, and use each where
they belong rather than try to force one to use the other.
Tables expose data and have no behavior. Objects hide data and expose
behavior. These two descriptions are very nearly opposites of each
other. OO is a technique for organizing the dependencies between
source code modules in order to minimize the impact of change. DBs are
a technique for representing data in a formal and consistent fashion.
Learn each. Appreciate each. Apply each. Keep each where it belongs.
--
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
> I suggest that OO ideas are too naive to continue influence
> programming.
OO is not rocket science. It's a very simple, very pragmatic, and very
useful technique for managing source code dependencies. Don't try to
make more out of it than that. OO is not a deep philosophy, nor an all
encompasing world view. It's just a clever syntax for jump
indirection, and some rules for grouping data and functions together.
In one sense I agree with you. I think OO has had the maximum
influence it can have. I don't expect any more deep thoughts about OO,
nor any further revelations about it's implications. OO has run it's
course and has become throroghly insinuated into our programming
culture.
S Perryman
> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
SP>For me, the big problem has always been the following :
SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
SP>In the OO world, the problem is that for each instance of SomeType held
SP>in Somewhere, the *implementation* of the property 'x' could be merely
SP>an actual data value, or a serious computation process. That is the ADT/OO
SP>way.
> If x is computed, then why don't you introduce a function that computes it?
We have.
A function whose implementation may be different for every instance of
Sometype that is contained by Somewhere.
> In relational world a function call is a join.
A join on what specifically ??
> If this function is not known at runtime
> then what logic is involved in selecting it?
You will have to clarify what you mean here.
> Can't the problem solved by dynamically constructing this query?
The time of query construction is irrelevant.
>>I see it different. First the above should be decomposed into primitive
>>operations over the types involved. There is at least the type of the table
>>and one of the cell. If SELECT were doubly dispatching, then one could
>>certainly provide different implementations for different combinations of
>>types.
> What is SELECT? The whole query? The projection part? You OO guys
> perfected the art speaking gibberish.
As in the SQL construct ??
Or if you prefer ... s = { e IN Somewhere : e.x = 123 }
SP>It is because of this that I believe that the only paradigm that is capable
SP>of providing the true engine for a relational info base that caters for
SP>both OO and current RDBMS, is Functional programming (data values and
SP>computation entities - functions - are treated the same, techniques such as
SP>lazy evaluation, "copy on write" behaviour etc) .
> Function is just a relation with functional dependency. It works
> pretty much like an index. When a function is called from a query, it
> is essentially a join, although there is no ambiguity which order this
> join is evaluated.
The "order" of evaluation is an *implementation* decision.
> Therefore, in principle, FP is too weak to embrace
> relational. It is more likely to happen the other way.
FP is perfectly capable of accommodating RA.
Because RA is based on mathematical concepts, as is FP.
Therefore any computable predicate expressible in RA, can be expressed in
FP.
> Relational programing has its weaknesses, but they are not what OO
> propellerheads think.
The weakness, as with all things, is in the *implementation* of the
concept. No better demonstrated than SQL for databases, and C++ for OO prog
langs.
> One missing part in the relational is formal
> grammars and languages. The underlying theory of grammars and language
> theory is Kleene algebra which is incompatible with RA. Witness how
> regular expressions are integrated into SQL
SQL is a *specific implementation* of the relational model is it not.
There is nothing inherent in the relational model, or regexps, that prevent
the latter being defined in terms of the former (ie confirming my comment
above about implementations) .
Regards,
Steven Perryman
Robert Martin
> They asked Bjarne Stroustrup? Why??
>
> "I invented the term Object-Oriented, and I can tell you I did not
> have C++ in mind."
> - Alan Kay
I don't wish to minimize the contribution that Kay made. It has been
enormous. The undercurrents he started with Smalltalk continue to
pervade our industry, subsuming it from the bottom up. Revolutions in
our thought such as Design Patterns, Agile Development, Test Driven
Development, etc, etc, can all be traced to the Smalltalk community.
Having said that, Kay did not invent OO. He may have coined the term,
but the concepts were invented years before by Ole Johan Dahl, and
Kristian Nygaard in the language Simula-67. (When they moved the
calling frame from the stack to the heap.)
Now it happens that both Kay and Stroustrup were influenced by Simula.
Both came to very different ends. However, if you were to line up the
two results and compare them to the parents, you'd find more
similarities between Simula and C++, than between Simula and Smalltalk.
So it is possible to claim (though it would be naive) that Stroustrup
remained more faithful to the orginal concept.
Stroustrup's contribution was also huge. But whereas Kay was a
visionary who created a subculture that has influenced our industry
from the bottom up, Stroustrup was a pragmatist and a driver who
changed the industry from the top down. The evidence of this is in the
major languages used today (Java, C#). These languages can be very
clearly traced to C++. So in that sense it was Stroustrup who was
responsible for the fact that the industry has gone OO.
The Smalltalk subculture is still alive and well; and is showing up in
many interesting new forms. The Ruby/Rails community can trace its
roots directly to Smalltalk; and they are currently poised to grab a
huge chunk of the industry.
So I think we will see these two competing ideas continue to struggle
with each other, to the benefit of our industry. And we can thank both
Kay and Stroustrup for their equal and unique contributions.
Robert Martin
> Any ideas except 'the other guys are so stupid'?
Yes. Each group thinks it understands the other. Both are wrong.
Robert Martin
> My concern for OO is not that its mechanisms are
> not useful, but that it gives objects primacy before data, instead of
> the other way around as per the definition of the term.
OO gives *behavior* primacy over data. To say that a different way, OO
source code is organized around it's behavior, not around the data
manipulated by those behaviors.
An object is not a container of data. An object profers behavior. Any
data necessary to achieve that behavior is kept hidden.
Robert Martin
> In response to mAsterdam's call for a civilized discussion of the pros
> and cons of both theories, I can't say much because I only know one side
> of the argument.
The most amusing aspect of the "argument" to me is that the two
"theories" do not compete. There's nothing to argue about. It's
rather like arguing whether desert topings are better than floor waxes.
OO is a technique for organizing and decoupling source code modules.
RDB is a technique for organizing and representing data.
So the argument goes:
"My way of organizing source code is better than your way of organizing data."
"No, you are naive, you don't understand subsets and algebraic formality."
"You are an idiot, it's about polymorphism and inheritance."
It seems to me that we'd all be a lot better off if we tried very hard
not to get our peanut butter and chocolate mixed up. Each has it's
place. Each has it's purpose. Each has it's benefits and costs.
Neither can replace the other.
Robert Martin
> I prefer to work with people who understand procedural,
> relational, OO, and functional programming. The boundaries between
> these paradigms are not sharp -- useful techniques span paradigms.
> Ultimately I'm looking for a gestalt development environment that
> leverages the benefits of the superset of these techniques to deliver
> high quality software. That's the real goal, after all.
Well said.
It is true that the boundaries can be indistinct; but this happens
because it is *possible* to specify data within objects; and it is
*possible* to specify behavior within SQL.
I have consulted for shops in which the DBAs took total control over
the business rules, reducing the programmers to little more than GUI
form jockeys. I have also consulted for shops in which the programmers
took total control over all the data access, reducing the DBAs to
little more than DDL clerks. Neither extreme is appropriate.
There is a place for stored procedures, just as there is a place for
serialized objects in flat files.
Robert Martin
> The problem with paradigm-potpourri is that its more expensive to hire
> people who have sufficient experience in them all. The industry tends
> to force programmers into managers or unemployment after about 15
> years, and 15 years is not enough for most programmers to master that
> many paradigms. And, I don't think the benefits of mixing is strong
> enough to offset that either.
Congratulations Bryce! THAT was an intelligent point.
You and I come to very different conclusions about it though. For my
money, I think we should encourage programmers to mature in their craft
and become multi-paradigm specialists. I don't think it's wise to
throw a bunch of 20somethings into the paradigm mold and try to get
everything done with the clones that come out.
Robert Martin
> But OOP and relational often don't compliment each other, but instead
> fight over territory. Unless clear and logical rules form that tell us
> when to stop one and start the other, this problem is not small.
ANOTHER INTELLIGENT POINT BY BRYCE! That's two in one day!
I agree, there is conflict at the borders.
Do we create a stored procedure to calculate the pay of the employee?
Or should we query for the data and write a suite of algorithms in Java?
Which you choose depends on a whole suite of factors.
- How much will the business rules change?
- Do the business rules need to be independently deployed?
- How complex are the business rules?
- What kind of throughput are we going to need?
- Is the operation atomic?
etc. etc.
Bob Badour
> Tegiri Nenashi wrote:
>
>> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>
> SP>For me, the big problem has always been the following :
>
> SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> SP>In the OO world, the problem is that for each instance of SomeType held
> SP>in Somewhere, the *implementation* of the property 'x' could be merely
> SP>an actual data value, or a serious computation process. That is the
> ADT/OO
> SP>way.
>
>> If x is computed, then why don't you introduce a function that
>> computes it?
>
> We have.
> A function whose implementation may be different for every instance of
> Sometype that is contained by Somewhere.
Instance is just a synonym for variable. The dbms should choose an
implementation based on value and possibly on optimization hints
provided by the DBA. See specialization by constraint and generalization
by constraint.
>> In relational world a function call is a join.
>
> A join on what specifically ??
One joins relations. Functions are a proper subset of relations.
>> If this function is not known at runtime
>> then what logic is involved in selecting it?
>
> You will have to clarify what you mean here.
>
>
>> Can't the problem solved by dynamically constructing this query?
>
> The time of query construction is irrelevant.
If you say so.
>>> I see it different. First the above should be decomposed into primitive
>>> operations over the types involved. There is at least the type of the
>>> table
>>> and one of the cell. If SELECT were doubly dispatching, then one could
>>> certainly provide different implementations for different
>>> combinations of
>>> types.
Sounds like a horrendous and costly way of dealing with something so simple.
[snip]
> SP>It is because of this that I believe that the only paradigm that is
> capable
> SP>of providing the true engine for a relational info base that caters for
> SP>both OO and current RDBMS, is Functional programming (data values and
> SP>computation entities - functions - are treated the same, techniques
> such as
> SP>lazy evaluation, "copy on write" behaviour etc) .
>
>> Function is just a relation with functional dependency. It works
>> pretty much like an index. When a function is called from a query, it
>> is essentially a join, although there is no ambiguity which order this
>> join is evaluated.
>
> The "order" of evaluation is an *implementation* decision.
Um, sometimes. If the order of evaluation affects the result, it becomes
a logical decision that the user must understand.
>> Therefore, in principle, FP is too weak to embrace
>> relational. It is more likely to happen the other way.
>
> FP is perfectly capable of accommodating RA.
> Because RA is based on mathematical concepts, as is FP.
>
> Therefore any computable predicate expressible in RA, can be expressed in
> FP.
But why would one want to?
>> Relational programing has its weaknesses, but they are not what OO
>> propellerheads think.
>
> The weakness, as with all things, is in the *implementation* of the
> concept. No better demonstrated than SQL for databases, and C++ for OO
> prog langs.
I disagree. The weakness of graph based logical data models is in the
model itself.
>> One missing part in the relational is formal
>> grammars and languages. The underlying theory of grammars and language
>> theory is Kleene algebra which is incompatible with RA. Witness how
>> regular expressions are integrated into SQL
>
> SQL is a *specific implementation* of the relational model is it not.
Not really. It is a whole class of implementations based on something
somewhat similar to the relational model. It is the only commercially
successful language based on any relational principles, however.
topmind
Robert Martin wrote:
> On 2008-02-09 13:37:47 -0600, topmind <top...@technologist.com> said:
>
> > The problem with paradigm-potpourri is that its more expensive to hire
> > people who have sufficient experience in them all. The industry tends
> > to force programmers into managers or unemployment after about 15
> > years, and 15 years is not enough for most programmers to master that
> > many paradigms. And, I don't think the benefits of mixing is strong
> > enough to offset that either.
>
> Congratulations Bryce! THAT was an intelligent point.
>
> You and I come to very different conclusions about it though. For my
> money, I think we should encourage programmers to mature in their craft
> and become multi-paradigm specialists. I don't think it's wise to
> throw a bunch of 20somethings into the paradigm mold and try to get
> everything done with the clones that come out.
Okay, but I don't understand how we can encourage them to mature their
craft if they will be moving on to different pastures soon? Software
development has far less stability than say a medical doctor: it's a
burn-and-churn industry, and not getting any slower. And hiring is
usually done based on how well one knows a specific tool, not how many
paradigms they have mastered. And we are being told to become domain
specialists to help resolve and communicate "business needs" rather
than be merely "bit-heads".
Something has to give.
>
> --
> Robert C. Martin (Uncle Bob)��| email: uncl...@objectmentor.com
-T-
topmind
Robert Martin wrote:
> On 2008-02-09 23:58:27 -0600, topmind <top...@technologist.com> said:
>
> > But OOP and relational often don't compliment each other, but instead
> > fight over territory. Unless clear and logical rules form that tell us
> > when to stop one and start the other, this problem is not small.
>
> ANOTHER INTELLIGENT POINT BY BRYCE! That's two in one day!
>
> I agree, there is conflict at the borders.
>
> Do we create a stored procedure to calculate the pay of the employee?
> Or should we query for the data and write a suite of algorithms in Java?
>
> Which you choose depends on a whole suite of factors.
>
> - How much will the business rules change?
> - Do the business rules need to be independently deployed?
> - How complex are the business rules?
> - What kind of throughput are we going to need?
> - Is the operation atomic?
>
> etc. etc.
I think there is more too it than stored-procedures versus Java
methods. A stored procedure is often just a subroutine written in
Oracle's app language.
A bigger issue is how to manage "variations on a theme". OOP tends to
use polymorphism and object pointers, while a data-centric approach
tends to use set theory and attributes (meta data). I much prefer the
second. I won't claim it objectively better, but to my mind it is a
lot nicer, more flexible, and easier to report/study/sift via query
and table browsers. And more cross-app-language-friendly. It is just
easier to get my head around sets than graphs of object pointers. Sets
are a higher-level abstraction than graphs of object pointers IMO.
(Data-centric approaches are almost like building a domain-specific
interpreter.)
Another way of saying almost the same thing is that managing
relationships BETWEEN objects is a dark-grey art, while in data-
centric approaches relationship management is a light-grey art because
it was invented for mass relationship managment.
>
>
> --
> Robert C. Martin (Uncle Bob)��| email: uncl...@objectmentor.com
-T-
Tegiri Nenashi
> Tegiri Nenashi wrote:
> > On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> SP>For me, the big problem has always been the following :
>
> SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> SP>In the OO world, the problem is that for each instance of SomeType held
> SP>in Somewhere, the *implementation* of the property 'x' could be merely
> SP>an actual data value, or a serious computation process. That is the ADT/OO
> SP>way.
(removed confusing exchange)
Unless you state your problem in more detail -- I suggest one page
description -- I fail to understand it.
> FP is perfectly capable of accommodating RA.
> Because RA is based on mathematical concepts, as is FP.
>
> Therefore any computable predicate expressible in RA, can be expressed in
> FP.
This argument is too weak. There are plently of incompatible
mathematical models.
> There is nothing inherent in the relational model, or regexps, that prevent
> the latter being defined in terms of the former (ie confirming my comment
> above about implementations) .
No, one fundamental difference between the two models is the
properties of the join operation. In regular expressions join is not
commutative. For example the result of concatenating "ab" with "cde"
depends on the order. In relational algebra join is commutative. The
other huge difference is that in RA join is compatible with set
intersection; basically intersection is a join. In regular expressions
algebra intersection can't be expressed via join.
David Cressey
"Robert Martin" <uncl...@objectmentor.com> wrote in message
news:200802111038258930-unclebob@objectmentorcom...
> On 2008-02-08 11:17:54 -0600, Jan Hidders <hid...@gmail.com> said:
>
> > They asked Bjarne Stroustrup? Why??
> >
> > "I invented the term Object-Oriented, and I can tell you I did not
> > have C++ in mind."
> > - Alan Kay
>
> I don't wish to minimize the contribution that Kay made. It has been
> enormous. The undercurrents he started with Smalltalk continue to
> pervade our industry, subsuming it from the bottom up. Revolutions in
> our thought such as Design Patterns, Agile Development, Test Driven
> Development, etc, etc, can all be traced to the Smalltalk community.
>
> Having said that, Kay did not invent OO. He may have coined the term,
> but the concepts were invented years before by Ole Johan Dahl, and
> Kristian Nygaard in the language Simula-67. (When they moved the
> calling frame from the stack to the heap.)
>
> Now it happens that both Kay and Stroustrup were influenced by Simula.
As I said some ways back in this topic, OO had its origins in simulation.
Thank you for making the heritage more explicit.
David Cressey
> On 2008-02-09 04:21:08 -0600, mAsterdam <mAst...@vrijdag.org> said:
>
> > Any ideas except 'the other guys are so stupid'?
>
> Yes. Each group thinks it understands the other. Both are wrong.
>
"stupid" people who combine a certain stubbornness with a certain ignorance.
With regard to databases, a large number of newcomers come in with the
notion that, "I know next to nothing about databases, but I'm pretty
certain that there isn't much of importance to know."
For those of us who have studied databases for years either in theory or in
practice or both, and think we have learned a great deal in that time,
this attitude seems singularly counterproductive when it comes to learning
anything new.
We regulars also have our own habits of thought and communication, that
tend to shut down useful dialogue with many newcomers. You can judge for
yourself, based on this topic.
I think that if you are going to find any useful confluence betwen the
theory of DB and the theory of OO, you going to have to find it in the way
each of them deals with the theory of data. We do both deal with data,
don't we?
Speaking just for myself, I had been programming for some 20 years when I
began to "do databases", some 23 years ago now. I would say that the
cutover from process centered thinking to data centered thinking was much
more profound than the cutover from structured programming to object
oriented programming.
And I realize that OO is not just OOP.
topmind
David Cressey wrote:
> "Robert Martin" <uncl...@objectmentor.com> wrote in message
> news:200802111038258930-unclebob@objectmentorcom...
> > On 2008-02-08 11:17:54 -0600, Jan Hidders <hid...@gmail.com> said:
> >
> > > They asked Bjarne Stroustrup? Why??
> > >
> > > "I invented the term Object-Oriented, and I can tell you I did not
> > > have C++ in mind."
> > > - Alan Kay
> >
> > I don't wish to minimize the contribution that Kay made. It has been
> > enormous. The undercurrents he started with Smalltalk continue to
> > pervade our industry, subsuming it from the bottom up. Revolutions in
> > our thought such as Design Patterns, Agile Development, Test Driven
> > Development, etc, etc, can all be traced to the Smalltalk community.
> >
> > Having said that, Kay did not invent OO. He may have coined the term,
> > but the concepts were invented years before by Ole Johan Dahl, and
> > Kristian Nygaard in the language Simula-67. (When they moved the
> > calling frame from the stack to the heap.)
A bit backtracking here, but if he coined the term, then wouldn't that
mean that he gets to define what is and isn't "OOP"? Even though
*some* features (at least) of OO were in earlier languages, that does
not mean the *entire* earlier language was OO. In other words, he
gets to decide what belongs to "OO" and what doesn't, in this view.
Unless, one argues that "common usage" trumps Kay, which is a
legitimate claim. But either way, Simula is not really the key factor.
> >
> > Now it happens that both Kay and Stroustrup were influenced by Simula.
>
> As I said some ways back in this topic, OO had its origins in simulation.
> Thank you for making the heritage more explicit.
-T-
Bob Badour
> "Robert Martin" <uncl...@objectmentor.com> wrote in message
> news:2008021110401511272-unclebob@objectmentorcom...
>
>>On 2008-02-09 04:21:08 -0600, mAsterdam <mAst...@vrijdag.org> said:
>>
>>>Any ideas except 'the other guys are so stupid'?
>>
>>Yes. Each group thinks it understands the other. Both are wrong.
Martin is an idiot. I have been doing OO for 20 years and doing it very
well. My interest in OO pre-dates my interest in data management theory.
I call the comp.object folks ignorant and stupid because they are.
Martin more so than most. He is a self-aggrandizing ignorant.
[snip]
David Cressey
> On 2008-02-07 14:35:26 -0600, Victor Porton <por...@narod.ru> said:
>
> > 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?
>
> The concepts are orthogonal. Objects are not tables. Tables are not
> objects. The many efforts to try to force tables and objects together
> always cause trouble. Things work better when you recognize the
> benefits of tables, and the benefits of objects, and use each where
> they belong rather than try to force one to use the other.
>
> Tables expose data and have no behavior. Objects hide data and expose
> behavior.
I have a different understanding.
Objects do not always hide data. Specifically, they pass messages to each
other in the form of data. Going further, objects do not "see" the behavior
of other objects. What they see is the data, written into messages, that is
the result of behavior. Seeing the result of behavior is not the same thing
as seeing the behavior itself.
One could do a data centric analysis of an object world, by analyzing the
data passed among the objects in that world. Such an analysis would be much
more like the kind of analysis one makes of a database. Or, perhaps more
likely, analysis of a set of information requirements that is to be filled
by a database not yet designed.
Phlip
> Martin is an idiot.
Sure, but I trust him on OO over you. I trust TopMind over you.
JOG
I'm not seeing whats so controversial or difficult about the fact that
"10001" is just a meaningless binary value until you give it a
context. It seems somewhat obvious to me.
> I dispute your premise that the purpose of the data in
> this case is to state a fact that is known a-priori to be true.
A Datum is a given fact. That's what the word means formally. I have
said nothing more, and I have no idea what you are on about talking
about "the purpose of data".
> If that is its purpose then it conveys precisely zero information.
>
> > > We can display
> > > it. We can comment on whether we like it - even if we haven't a clue
> > > where it came from. But I don't see any sense in which the image
> > > value gives us any statements of fact beyond the specification of a
> > > value. A value simply "is".
>
> > > I would suggest that a lot of the data in the world is characterised
> > > more closely as "interesting values" than collections of
> > > propositions.
>
> > You cannot store these interesting values without implicitly stating
> > some fact about them.
>
> By definition, when a value is specified, its type is specified as
> well (except possibly if type inheritance is supported).
>
> C. Date states the following in "Introduction to Database Systems",
> section 5.2, and subsection titled "Values and Variables are typed":
>
> "Every value has ... some type...Note that,
> by definition, a given value always has
> exactly one type, which never changes.
> [footnote: except possibly if type
> inheritance is supported]"
>
> When a particular value like the integer 73 is specified, there is no
> implicit fact being specified. The statement that the integer 73
> exists in any absolute sense is entirely metaphysical and meaningless
> within computer science.
So you just wriite "73" down and are telling me its a datum? I'm
pretty sure that's what we call a "value", not data. I'm wondering if
you are misconstruing my point - "73" is only data when you apply some
context to it, like saying this its someones room number, or today's
average temperature, or the amount of red in a certain pixel of an
image (and yes, those are then facts).
JOG
Let me clarify the distinction I'm making David:
"RED" is a value.
"The first pixel in the image is RED" is a datum.
That can't be that contentious...can it?