Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Joe Van Dyk wrote:

> Alfredo Novoa wrote:

>> Robert Martin wrote:

I use PostgreSQL, a free database. It supports "everything that matters". It is a little weak IMHO on admin tools, but the 3rd party admin tool pgAdmin3 is coming along (looks like Microsoft SQL Server's enterprise mgr and query analyzer).

Postgres delivers everything that SQL Server and DB/2 did, though sometimes there is a different word for it, or it requires a different approach.

>
> The credit card supplied with the order needs to be verified against an
> external encrypted web service. If the order goes through, then it
> needs to notify another web service that fulfills the order. Once UPS
> ships, I need to get that information from UPS. If all the rules for
> the sytem are in the dmbs, can the dbms do all that external stuff?
> Perhaps through stored procs?

Yes. Postgres in particular supports stored procedures in perl, with one particular mode that allows unlimited access to the system. Myself I prefer to use PHP, and you can also code triggers and sprocs in that, though it is not as mature as the perl system.

Once you can code routines that can "see" outside of the database, you can more or less do anything.

>
> If so, is anyone aware of any open source web applications that do have
> all the rules for the system in the database?

<shameless self-promotion>
How about ours?

http://docs.secdat.com.

Our project, Andromeda, is now very mature in the area of derivations of many sorts inside a database. We have found that nearly all common "business logic" can be resolved into a handful of common repeating patterns. The product allows you to specify column and table automations of various forms so that the server takes over most (and in many cases all) of the processing.

The motto of the project is "The server implements all business rules at all times".

W/respect to making calls to outside services, we are still doing that in code because we haven't settled on an architecture for it yet that will likely run on multiple server platforms. We've seen several cases in work that comes our way, but not enough yet to generalize.

</shameless self-promotion>

>
> And to you same people, do you think there's room for "application
> databases", where applications (who may or may not use databases for
> storing information) talk to each other through well-defined interfaces?
>

SQL is a well-defined interface. Using triggers and sprocs you can have a database make a query to any other database anywhere in the world.

The limitations tend to be political, not technical. If you are working with a 3rd party that is big and powerful, then you accomodate them and whatever interface they've chosen.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)