> > 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 in a few files that are independant
from both the database (vs. Stored Procedured) and the user-interface (vs.
having all db-queries in your php-code), allows you to quickly implement
changes to both architectures. Switch the DB? Just change a few lines in one
file and everything works. :-) Create a PDA frontend to your website? Easily
done because all the hard work is done by a module (or whatever your
environment might call it).
> > 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 have two special structures for queries and responses. They can both
be easily converted from/to XML or be passed around as their binary
presentation. That way you have all the options:
- presentation- and business-logic on one system, communicating through normal calls
to the libraries
- presentation-login on one system and business-logic on another system, communicating
through TCP/IP
- offering your service via SOAP etc., converting queries from XML and responses to XML
bye, Paul.
--
Paul Mallach
ARIVA.DE AG
Ostseekai 2
D - 24103 Kiel
Tel.: +(49) 0431/97108-24 E-Mail: [EMAIL PROTECTED]
Fax: +(49) 0431/97108-29 Internet: www.ariva.de
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
