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. Received on Tue May 25 2004 - 13:36:46 CDT