Re: What so special about PostgreSQL and other RDBMS?

> > When and if you need to migrate your application to another DB,
> > presumably you have chosen db 2 based on your requirements and have
> > already decided on a solution to whatever problem you are facing,
> > having your code issolated means fewer code changes. Again, this holds
> > true for migration, it also holds true for simply making better use
> > (i.e. new features) of the platform you are currently using.

> Instead of abstracting there are much better ways.  Abstrating somethings
> are good.

Seems contradictory, I assume you mean there are _somtimes_ better
ways in the first sentence. In which case, I agree, sometimes there
are.

> Put the business rules and referential integrity in the DB not in
> some middle tier or front end.
> It is much more likely you are going
> to swap out some middle tier or front end or have multiple programs
> accessing the db.  If you give access to the db only through stored procs
> and put the business logic close to the database (in it) then it is just an
> API for storing, retrieving your data.  It is a way to encapsulate that
> functionality.  If you write a C++ or Java or other OOPL functionality the
> concept (among others) is to encapsulate the functionality in that class.
> The class does all the checking and data validation etc.  Think of the db in
> the same way with respect to data and its relationship to itself. (RI,
> business rules)  You can still have edit checks in a GUI, but the ultimate
> RI and business rules should reside in the database.  But if one is only a
> programmer this is a difficult concept to agree with and understand.

Good explanation.

There are still some aspects of abstraction that are relevent here:
Since you can use standard SQL to do what you describe, I would
recommend in this case that you isolate your nonstandard sql to as few
stored procedures as possible to facilitate potential migration down
the road.

Also, putting the execute binding into a wrapper function, as I've
described, is still a good idea.

And, in the case of permenant, long term, or shared data, creating
archives in a self contained, self describing, human readable format,
is also good.

Stored procedures are a really good approach when data security is
extreamly precise, i.e. record and field level security. And also, the
performance advantages make them almost essential for huge table
joins.

It really depends on whether the database is a replacable backend to
highly invested-in application or the application is a replacable
interface to a highly invested-in database.

The former is generaly model good for an application which you provide
to a client, who may have a different DB, The later is sometimes a
good approach for an inhouse application in a large operations center,
with a good DBA.

The number of applications that look more like the former far
outnumber the ones that look most like the latter. Only a tiny
percentage of organisations have a DBA of anykind, let alone a good
one.

If you are a bank, you should follow Jim's advice, however you
probably already know it, since you have a good DBA to keep the pesky
programmers under control.

If you are more like a book store, or a photo shop, or an HVAC repair
firm, or a small Non Profit, you should probably follow mine.

> > As long as you agree to pay whatever Oracle charges for support, a
> > price fixed not by competition, as it would be if you had source and
> > could contract who ever you liked, but by David Ricardo's concept of
> > Economic Rent, meaning that in the long run the price will rise to
> > what it would cost you to migrate away from Oracle. Interestingly, in
> > this way users of closed source software do marginaly benefit from
> > free software, since it lowers this theoretical rent. However, it is
> > clear that Oracle can benefit from ignorance of free options for quite
> > a while yet.

> BS.
>  If you are so niave 

Why the belligerence?

> to believe that Oracle doesn't think it has
> competition they you are from another galaxy.

They do not have any competition in regards to selling _Oracle_.

> I assure you that they know
> there are other companies out there and they price accordingly.  This
> includes support.  I've been at many companies where there was competition
> between Oracle and others and they were fully aware and concerned that they
> would get the business.  They priced accordingly.

Price is determined when the flow of product ENCOUNTERS the flow of
money.

The competetion you speak of is only at ONE ENCOUNTER, the orginal
decision to buy Oracle vs a competitor, so yes, at this encounter, the
price ceiling is determined by competion and to a certain extent,
costs.

Once you have become an Oracle customer, there is no further
competetion unless you chose to migrate away from Oracle, so for EVERY
FURTHER ENCOUNTER the price is determined by what it would cost to
migrate away from Oracle.

In economic theory, I am applying what is known as Economic Rent,
originaly forumulated by David Ricardo.

Since Oracle and their competitors all know this, they all have the
same pricing strategy.

Only vendors of free software face different factors.

With vendors of free software, the potential for competetion exists AT
EVERY ENCOUNTER, and therefore price is more closely driven by cost.

This of course doesn't not mean that you should never use nonfree
software, as sometimes there is no alternative for your needs, so the
price must be born and worked into your own business model, and
therefore passed on to your own customers.

But since your business realty may be more elastic than Oracle's, this
"cost push" can force you into a situation of overdeployment or
piracy, in which case your access to updates and support is
questionable.

In closing, Jim, if you have an inovated new price theory, please
explain it here, perhaps you can take my understanding beyond Ricardo,
Keynes and their descendents, I'm all ears. But calling what I said
BS, and me naive for saying it is just, as I said, Belligerent, or in
technical terms: 'Following in the footsteps of Volker.'

Regards,
Dmytri.