Or, you could write your business rules as a middleware application
in C or Python (etc.) and access that middleware to do the rest of
your application.
A good idea.
Or Perl. :-) I think it's a good idea as well and in fact our website is built
that way. Having all database specific code
Consider sending queries to your middleware and having it respond in
XML for a great way to do better-than-SQL responses in some cases
(such as making 'group by' return every result, grouped into XML
sub-sections by the relevant field).
Unless you care about performance.
We've
MySQL is pretty fast and very reliable. It's also simple to use. It
supports standard ANSI-92 SQL, as far as I can tell, and the standard
distribution does not have certain features such as:
- triggers
- stored procedures
- referential integrity
- transaction support (this may have been
- transaction support (this may have been implemented through Gemini, but
the legal status of this contribution appears to be in question now)
Transactions are also supported with BDB and InnoDB tables afaik ...
If you want to embed a lot of the business logic in stored or needb other
of
On Wed, Aug 15, 2001 at 04:59:03PM -0400, Michael T. Babcock wrote:
Or, you could write your business rules as a middleware application
in C or Python (etc.) and access that middleware to do the rest of
your application.
A good idea.
Consider sending queries to your middleware and having
