Databases as objects

aloha.kakuikanu wrote:
> <snip>
>
> This is only the beginning of the list, and I assure you that you'll
> get more return on your investment not if you spend your time
> "brainstorming" how to fit databases into objects, but educating
> yourself what database management really is.
>
>
I'm going to keep saying this different ways until I finally say it, or
draw a picture, that makes it clear I am not trying to fit the database
inside an object. I am not trying to wrap it inside an object. I am
not advocating an OO framework to arbitrate all DB access.

I am saying domain-specific databases (what makes your application's DB
design different than mine) can be thought-of, and ultimately treated,
as objects. Now--don't run off and think I'm trying to wrap anything.
What I'm saying is that the rules OO designers use to decide what
methods an object should have (and not have) and the justifications for
resisting direct data manipulation can be applied to how applications
interface to database by deciding that 1) no application should directly
access the DB's data (no SQL) and 2) applications should use the DB only
through its interface. Stored procedures are the best example of the
latter I know of.

Ultimately, I think I may need to come up with another name for a
domain-ized database. The word 'database' has too many possibilities.
It's too general. After I've applied my schema to it it no longer has
all the possibilities it once had. After my schema's applied it becomes
something different. It's becomes my domain's data base. My domainabase?

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Thomas Gagne wrote:
> An unexpected thing happened while debating topmind: I had an epiphany.
> Instead of responding to the news group I thought about it for a short
> bit (very short) and posted an article to my blog titled, "The RDB is
> the biggest object in my system."
>
> <http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_i n_my_syst>
>
>
snip ...
>

Hej, Thomas.

I know nothing about databases.

(I always feel like I've just been to Confession whenever I write that
line; it's quite liberating.)

Your (very interesting) proposal, however, seems similar(ish) to the
ideas that pop up from time to time whenever DBers and OOers meeting for
a ho'down and some line-dancing. The general result of these fun
evenings is that DBers point to OO's diluting of the power of the DB in
some way (I've never been sure how). The point is: if you really want
some good DB-centric advice on your proposal, you should consider
posting to comp.databases.theory - those folks know everything there is
to know about DBs and could help you plug any leaks in your endeavours
(and perhaps save you some time in your studies).

If you do make such a post, however, do please multi-post; don't
cross-post (amazing: there is a use for cross-posting afterall). The
reason for this request is that cross-posts between c.o and c.d.t tend
to deteriorate alarmingly quickly into sulking, name-calling, and
kill-files bloating to significant proportions of their hosting discs.

Despite this, their DB expertise is, as mentioned, extraordinary; so do
consider popping over there for a chat ... but don't tell them who sent you.

Just a thought.

..ed

PS On an OO note, regarding your, "My schema is a class/my DB is an
object," concept (again, very interesting). I presume here you mean the
DB as the data it contains, rather than a particular vendor's DB such as
Oracle, etc. If so, then there should be a concept of changing the data
wholesale for some other data, without affecting the users of that data
(i.e., the application). I can't really see this happening. If I have
the data for a suit-tailoring business, and applications that graze this
data, then I can't really see that the applications will remain
unchanged when this data is dropped and the data for, say, a
car-manufacturer inserted instead. Silly example, of course, but I hope
it gets the point across: how often do you have one schema with multiple
data-sets conforming to it. Do bear in mind my first sentence ...

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
http://www.EdmundKirwan.com/servlet/...c-page130.html

Thomas Gagne <tgagne{}wide-open-west.com> writes:
>Stefan, what "subject" were you replying to when you wrote that?

Here are excerpts from the header lines of the post I wrote in July:

Newsgroups: comp.object
Subject: polymorphism (was: Poly Couples)
References: <1151999442.600805.230670{}75g2000cwc.googlegroups .com> <OO-20060704232303{}ram.dialup.fu-berlin.de> <1152157551.514387.8840{}j8g2000cwa.googlegroups.c om>
Expires: 28 Nov 2006 11:59:59 GMT
X-No-Archive: Yes
Message-ID: <db-20060706061022{}ram.dialup.fu-berlin.de>

Ed Kirwan wrote:
> <snip>
>
> Your (very interesting) proposal, however, seems similar(ish) to the
> ideas that pop up from time to time whenever DBers and OOers meeting
> for a ho'down and some line-dancing. The general result of these fun
> evenings is that DBers point to OO's diluting of the power of the DB
> in some way (I've never been sure how). The point is: if you really
> want some good DB-centric advice on your proposal, you should consider
> posting to comp.databases.theory - those folks know everything there
> is to know about DBs and could help you plug any leaks in your
> endeavours (and perhaps save you some time in your studies).
Thank you for the recommendation. I'll post it separately to avoid the
devolving arguments. ;-)
>
> <snip>
>
> PS On an OO note, regarding your, "My schema is a class/my DB is an
> object," concept (again, very interesting). I presume here you mean
> the DB as the data it contains, rather than a particular vendor's DB
> such as Oracle, etc. If so, then there should be a concept of changing
> the data wholesale for some other data, without affecting the users of
> that data (i.e., the application).
In theory (isn't it always) if the interface was consistent between
tailors and auto manufacturers then the answer would be yes. That would
be a kind of polymorphism. Of course, it depends on the interface
staying intact. If the interface is broken it matters little what's on
either side of it--the system is broken.

The metanoia I'm advocating cares little for the DB's vendor. Once
you've created a specific database model to support your application
domain you've created a hypostasis. You started with an empty database
with infinite potential and tailored its purpose for your specific needs
and given it an identity of its own. You started with the general and
hypostatized to the specific. Your database is no longer general
purpose. Its design is intellectual property and its contents proprietary.

This is what happens when we subclass Object to create something
specific, like a Date. Object has the potential to be anything, but
Date has been modified for a specific purpose. It, too, has been
hypostatized. Date has become a species independent of its superclass
with unique data and behavior.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Thomas Gagne wrote:
> Let me try to clear something up, and thanks to Topmind, Frans, and
> Stefan for helping me get there.
>
> In OO, objects are subclassed to make them more specific, not more
> general. I consider SQL to be a low level language, as far as RDBs are
> concerned, because it is application-ignorant. It's like C for
> relational operations. SQL doesn't know anything about my application.
>
> So, I subclass Model (so-to-speak) and add data that is domain-specific
> to create my domain-specific database. Why access it from applications
> using the same domain-ignorant language? Instead, I construct
> procedures that create a domain-specific interface. Instead of the
> lower-level
>
> select * from account, user where user.userId=X and account.userId =
> user.userId
>
> when instead I can use
>
> exec getAccountsFor {}userId=X
>
> ?
>
> Besides its brevity, the procedure name clearly communicates the intent
> of the operation (stbpp pattern: intention revealing message), makes
> obvious its parameters, and provides a layer of indirection behind which
> its implementation can change without affecting the procedure's users.
>
> From SQL I've constructed procedures to provide a higher-level,
> domain-specific, language-and-paradigm-neutral interface to a
> domain-specific database.
>
> To find all the places in my application source code that get account
> information with user IDs it is much easier to find senders (callers) of
> getAccountsFor than it would be to find all the SQL referencing both the
> account and user tables. Could the latter be done? Sure, but when a
> more efficient and accurate alternative exists why would you?
>
> --
> Visit <http://blogs.instreamfinancial.com/anything.php>
> to read my rants on technology and the finance industry.

Stefan's point is very interesting as well, though? To use your same
example,

select * from account, user where user.userId=X and account.userId =
user.userId

could also be seen as a message send, something like:

(Table join: account and: user on: [ :a :u | a id = u id ])
select: #(#field1, #field2) where: [ each user id = X ]

NB. The above is for illustrative purposes, I am not saying that SQL
should be mapped to Smalltalk in that way.

It is true that this is a low-level interaction, and
application-ignorant, but so are all the methods of String, or Integer,
or Array, Socket, SystemDictionary... that doesn't prevent them from
being OO.

Mike

On reflection, you've actually covered this off in your blog post (as I
see it, anyway); the database is a very large Facade, covering all of
the tables, which are lower-level objects. Do you agree?

Mike Anderson wrote:
> On reflection, you've actually covered this off in your blog post (as I
> see it, anyway); the database is a very large Facade, covering all of
> the tables, which are lower-level objects. Do you agree?
>
I've tried, but I've been made aware of some weaknesses in the
description. Not in the premise, but there's confusion in the words
I've chosen--particularly the words transaction and database. After
I've created a database uniquely suited to my application domain's
specific needs it is not longer a 'database' in the generic form, but
something else. After discussing it a bit with a coworker educated in
ancient Greek, we believe hypostasis may be a better term to describe a
customized database.

From <http://www.webster.com/dictionary/hypostasis>

*3 a* *:* the substance or essential nature of an individual *b* *:*
something that is hypostatized
<http://www.webster.com/dictionary/hypostatized>

Once customized for its purpose, the hypostasis is "the substance or
essential nature.." of my system. Plumbers and carpenters are both
skilled tradesmen, but have unique skills peculiar to their specific
trades. We wouldn't confuse a plumber's (deliberately or accidentally)
a plumber's skillbase with a carpenter's, but yet we don't have a word
that adequately differentiates the skills of either, just as we don't
have a word that differentiates a plumber's apparel manufacturer's
database from an auto dealer's database. We just use the word
'database' in different contexts and hope our readers follow us.

Or at least, I do.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Thomas Gagne wrote:
> Mike Anderson wrote:
> > On reflection, you've actually covered this off in your blog post (as I
> > see it, anyway); the database is a very large Facade, covering all of
> > the tables, which are lower-level objects. Do you agree?
> >
> I've tried, but I've been made aware of some weaknesses in the
> description. Not in the premise, but there's confusion in the words
> I've chosen--particularly the words transaction and database. After
> I've created a database uniquely suited to my application domain's
> specific needs it is not longer a 'database' in the generic form, but
> something else. After discussing it a bit with a coworker educated in
> ancient Greek, we believe hypostasis may be a better term to describe a
> customized database.
>
> From <http://www.webster.com/dictionary/hypostasis>
>
> *3 a* *:* the substance or essential nature of an individual *b* *:*
> something that is hypostatized
> <http://www.webster.com/dictionary/hypostatized>
>
> Once customized for its purpose, the hypostasis is "the substance or
> essential nature.." of my system. Plumbers and carpenters are both
> skilled tradesmen, but have unique skills peculiar to their specific
> trades. We wouldn't confuse a plumber's (deliberately or accidentally)
> a plumber's skillbase with a carpenter's, but yet we don't have a word
> that adequately differentiates the skills of either, just as we don't
> have a word that differentiates a plumber's apparel manufacturer's
> database from an auto dealer's database. We just use the word
> 'database' in different contexts and hope our readers follow us.
>
> Or at least, I do.

Well, let me see if I am following you

Before your addition of procedures to the database, you can see it as a
large object with poor data hiding. Specifically, it has no methods, so
the only way to interact with it is to send messages directly to its
instance variables (the tables within it).

Once you have added procedures to the database, you have your
hypostasis, and now you can interact with it instead of its contained
objects. In fact, now you can enforce the encapsulation by revoking
permissions on the tables and only granting them on the procedures.

I don't think that's too controversial, actually; many people would
regard this as a Best Practice for updates. I've seen it advocated for
selects too. However, I haven't seen anyone talking about it in OO
terms.

I find this very interesting, because it seems to me that databases
have a strong similarity to images, but whereas images are mostly an
unknown concept in mainstream programming, databases are commonplace.

Frans Bouma wrote:
> topmind wrote:
>
> > Thomas Gagne wrote:
> > > An unexpected thing happened while debating topmind: I had an
> > > epiphany. Instead of responding to the news group I thought about
> > > it for a short bit (very short) and posted an article to my blog
> > > titled, "The RDB is the biggest object in my system."
> > >
> > > <http://blogs.in-streamco.com/anythin...db_is_the_bigg
> > > est_object_in_my_syst>
> >
> > > From the link:
> >
> > "Why shouldn't applications have embedded SQL? Because it's the same
> > as accessing the private data members of an object. It shouldn't be
> > done. OO programmers know the correct way to interface with an
> > object is to use its method interface--not attempt direct
> > manipulation of the object's data. OO programmer's attempts to
> > violate that rule is what causes so much frustration mapping the
> > application's data graph into a relational database's tables, rows,
> > and columns. Those things belong to the DB--not to the application."
> >
> > (end quote)
> >
> > You OO'ers keep forgetting: SQL is an interface. I repeat, SQL is
> > an interface. It is not "low level hardware".
>
> SQL is a set-oriented language, it's not an interface as a language
> doesn't do anything without context (in this case a parser-interpreter
> combi)

Perhaps we need to clear up our working semantics with regard to
"language" and "interface". Are methods interfaces or a language? I am
not sure it really matters and I don't want to get tangled in a
definition battle.

>
> > You OO'ers keep
> > viewing it as low-level stuff because you don't seem to like it, and
> > you wrap anything you don't like behind OO and call it "low level" so
> > that it fits your personal subjective preference and world view. OO
> > may fit your mind better for whatever reason, but you cannot assume
> > your head is God's template for every other individual.
>
> of course it's not low level stuff, SQL is a set-oriented language and
> therefore doesn't match object-oriented languages, so a 'translation'
> has to be made as you can't project one onto another in a 1:1 fashion.

An option is to not use OO.

>
> > BTW, Microsoft has ADO, DAO, etc. which are OO wrappers around RDBMS.
>
> no they're not. ADO and DAO aren't OO, as they're COM based so they're
> actually procedural (library interfaces implemented on a live object).

Being an OO wrapper on top of procedural calls does not necessarily
turn something into non-OO. Please clarify your labelling criteria.

> Furthermore, they provide the interface you talked about to the DB,
> which is often referred to as 'the client interface' or 'provider' when
> it comes to database access.

This does not contradict anything I've said.

>
> > Further, even if OO was the best way to access RDBMS thru an app,
> > that does not necessarily extrapolate to all domains. OO being good
> > for X does not automatically imply it is good for Y also.
>
> you don't get the point: in an OO application, which works on data IN
> the application, you want to do that in an OO fashion.

Why? Is OO proven objectively better?

> To obtain the
> data from the outside is initiated INSIDE the application, thus also in
> an OO fashion. As an RDBMS doesn't understand OO in most cases, but it
> works with SQL as it has a SQL interpreter in place to let you program
> its internal relational algebra statements in a more readable way,
> you've to map statements from OO to SQL and set oriented results (the
> sets) from the DB back to OO objects.

Are you suggesting methods such as "Add_AND_Clause(column,
comparisonOperator, Value)"?

Those are bloaty and ugly in my opinion, but let's save that value
judgement for a later debate on clause/criteria wrappers.

>
> > I have
> > already agreed that OO may be good for writing device drivers and
> > device-driver-like things; but it has not been shown useful to view
> > everything as a device driver. I am more interested in seeing how OO
> > models biz objects rather than how it wraps system services and the
> > like. Biz modeling has been OO's toughest evidence cookie to crack
> > (but perhaps not the only).
>
> huh? walls full of books have been written about this topic and you
> declare it the toughest cookie to crack...

Such as? I've seen biz examples in OOP books, but they did not show how
they were better than the alternative. Showing how to make an Employee
class does not by itself tell you why an Employee class is better than
not using OO.

>
> > And finally, just because one can view everything as objects does not
> > necessarily mean one should. One can also view everything as Lisp or
> > assembler or that Brainf*ck language.
>
> sure, but that doesn't mean the language necessarily fits the purpose
> you want to use it for. data oriented operations on sets is best suited
> with SQL, as it is designed for that. other languages are designed for
> other purposes. Mixing the two is often not that successful, though
> that's not a problem per se as processing data is more or less a 3 step
> process:
> - move data from data producer to data consumer
> - process data in data consumer
> - move data from original data consumer to original data producer
>
> so you can easily chop up this process in 3 parts and implement the
> parts in the language best fit for the job.
>
> > > I realized
> > > this is exactly what data-hiding is all about and why expert object
> > > oriented designers and programmers emphasize the importance of
> > > interfaces to direct data manipulation.
> >
> > "Data hiding"? I am working on "OO hiding". Relational is a high-level
> > modeling technique which tends to use "declarative interfaces".
> > Declarative interfaces are not necessarily worse than "behavioral
> > interfaces", which OO relies on. This sounds like yet another battle
> > between declarative interfaces versus behavioral interfaces.
>
> Could you define 'interface' for me, as it gets more and more abiguous
> definitions in this post alone.

If "language" suits you better, that is fine by me. My main point is
that it is not "physical implementation" to be wrapped away. The use
of "direct data manipulation" was what I was responding to.

>
> > Note that
> > one could potentially mix them in RDBMS, but so far it does not appeal
> > very practical. And this is largely because the tight association
> > between data and behavior that OO likes simply does not work well in
> > biz apps. Thus, heavy behavioraltizing of RDBMS is not useful. I am
> > just pointing out it could be done and probably would be done if it
> > proved useful. OO forces an overly tight view of data and behavior.
> > Relational provides a consistency to declarative interfaces, but OO
> > does not provide any real structure and consistency to behavioral
> > interfaces. It creates shanty-town biz models.
>
> you declare a lot of IMHO rubbish as 'truth' here. E.g.: why wouldn't
> biz apps be helped with OO?

(For the record, the use of "rubbish" is a sign of rudeness. Thus, I
did not start the rudeness between us.)

I've never seen it happen. I am not claiming it can't or doesn't, only
that there is no public objective inspectable evidence that it does.
Yet, many push it thru as if it already "passed". I don't claim that
unicorns don't exist, only that I have not seen any captured for
analysis.

>
> > GOF patterns are supposed to be a solution, but GOF patterns have no
> > clear rules about when to use what and force a kind of IS-A view on
> > modeling instead of HAS-A.
>
> You also fall into the 'use pattern first, find problem for it
> later'-antipattern.
>
> a pattern is a (not the) solution for a well defined recognizable
> problem. So if you recognize the problem in your application, you can
> use the pattern which solves THAT problem to solve THAT problem in your
> application. THat's IT. The GoF book names a set of patterns and also
> the problems they solve. If you don't have the problems they solve, you
> don't need the patterns.

Well, a look-up table is usually simpler and more inspectable than
Visitor. Thus, if usefulness is our guide, then GOF patterns are often
not the best.

>
> Btw, the GoF book discourages inheritance a lot, just read it. It says
> don't use inheritance if you don't have to.

If you take away inheritence, you get "network structures" (AKA tangled
pasta). Dr. Codd sought to escape those by applying set theory, and
network structures thankfully fell out of favor, until the OO crowd
tried to bring them back from the dead.

>
> > GOF patterns are like an attempt to
> > catalog GO TO patterns instead of rid GO TO's. Relational is
> > comparable to the move from structured programming from GO TO's: it
> > provides more consistency and factors common activities into a single
> > interface convention (relational operators). OO lets people re-invent
> > their own just like there are a jillion ways to do the equivalent of
> > IF blocks with GO TO's.
>
> I've read a lot of nonsense in your post,

No, the nonsense comes from the OO zealots. They have no proof for biz
apps. Two paradigms are equal or unknown until proven otherwise. I want
to see science, not brochures.

> but this is one of the most
> striking examples. WHat on earth have GO TO's to do with the topic at
> hand?

It is an analogy.

>
> > OO has simply failed to factor and standardize common relationship and
> > collection idioms!!!!
> > OO has simply failed to factor and standardize common relationship and
> > collection idioms!!!!
>
> take your pills, you apparently forgot them

And you took your LSD: you hallucinate evidence that ain't there.

>
> FB
>

-T-
oop.ismad.com

Thomas Gagne wrote:
> Let me try to clear something up, and thanks to Topmind, Frans, and
> Stefan for helping me get there.
>
> In OO, objects are subclassed to make them more specific, not more
> general. I consider SQL to be a low level language, as far as RDBs are
> concerned, because it is application-ignorant.

So you are defining "low level" as application-ignorant? I find that a
stretch, but let's continue with it as a working/local definition.

> It's like C for
> relational operations. SQL doesn't know anything about my application.
>
> So, I subclass Model (so-to-speak) and add data that is domain-specific
> to create my domain-specific database.

In the app? Please clarify. Do you mean create the database, or an OO
*view* of the database?

> Why access it from applications
> using the same domain-ignorant language? Instead, I construct
> procedures that create a domain-specific interface. Instead of the
> lower-level
>
> select * from account, user where user.userId=X and account.userId =
> user.userId
>
> when instead I can use
>
> exec getAccountsFor {}userId=X

A side notes here before I continue. First, some versions of SQL can do
a "natural join" such that you don't have to explicity declare the
common/default joins between two or more tables. Thus, there are
shorter possibilities. (SQL is hardly the pinnacle of relational
languages IMO, but it is still better than being without a RDBMS.)

Now, the advantage of embedded SQL is that one can add to or change it
as needed without having to hop around. If we need an additional
criteria or columns, we just add it in ONE module. If you have a
separate place for SQL and another for app code, then you have visit
and modify two different modules. That is more work because 2 is
greater than 1. Hopping around slows down development and
modifications.

>
> ?
>
> Besides its brevity, the procedure name clearly communicates the intent
> of the operation (stbpp pattern: intention revealing message), makes
> obvious its parameters, and provides a layer of indirection behind which
> its implementation can change without affecting the procedure's users.

Use comments. And, "getFoo" is hardly an improvement over
"select...from Foo".

>
> From SQL I've constructed procedures to provide a higher-level,
> domain-specific, language-and-paradigm-neutral interface to a
> domain-specific database.

How is it more "neutral" than SQL? A stored procedure still has its own
syntax and rules. What common scenarios are you saving us from?

>
> To find all the places in my application source code that get account
> information with user IDs it is much easier to find senders (callers) of
> getAccountsFor than it would be to find all the SQL referencing both the
> account and user tables. Could the latter be done? Sure, but when a
> more efficient and accurate alternative exists why would you?

Again, this gets back to the change effort cost and frequency analysis
that was part of the last topic. I weigh the costs of all the kinds
changes when I decide to embed or separate SQL. Most changes that I
encounter in the field favor embedding. If your experience or shop
pattern is different, then we will just have to agree to disagree.

It again comes down to frequencies, and I dissagree with your frequency
assessment. We are back to where we ended on the last topic. One should
look at the human effort and frequency involved, not just use
(disputed) labels such as "low level" etc. to shape our decision.

It is a kind of Frederick Winslow Taylor (time and motion studies)
style of decision making. In my years of experience, embedding reduces
the *net* hopping-around effort. Yes, there are times where isolation
of all the SQL would save time, but not enough to make up for the
others.

>
> --
> Visit <http://blogs.instreamfinancial.com/anything.php>
> to read my rants on technology and the finance industry.

-T-