Re^2: Shopping Cart Project

Indeed: why any particular database product? or server?

The answer is probably somewhere around "that's what hosting companies still offer", which is what a lot of people tell me when this topic comes up, but then they use all sorts of other advanced features that hosting companies usually don't support.

--
brian d foy <bdfoy@cpan.org>

Comment on Re^2: Shopping Cart Project - interested?

Replies are listed 'Best First'.
Re^3: Shopping Cart Project - interested? by Aristotle (Chancellor) on Feb 26, 2005 at 13:25 UTC
Because cross-database portability of SQL is still a myth. There are a lot of very, very similar flavours, and indeed the most basic of functionality is portable across dialects, however if you restrict yourself to factually portable SQL you'll very soon hit on limitations. OTOH, a lot of the differences in the DQL and DML areas which concern the set of features common to all database engines are only superficial, ie syntactical. So assuming the database queries are properly encapsulated away from the application in a module as they should be, it wouldn't be hard to abstract away the differences between databases into several flavours of this module, of which one can then be selected by a configuration parameter. What all that means is that it's preferrable to target a particular database at first and only refactor the business logic module that encapsulates the queries when time comes for that. Makeshifts last the longest.	[reply]

Replies are listed 'Best First'.

Re^3: Shopping Cart Project - interested?
by Aristotle (Chancellor) on Feb 26, 2005 at 13:25 UTC

Because cross-database portability of SQL is still a myth. There are a lot of very, very similar flavours, and indeed the most basic of functionality is portable across dialects, however if you restrict yourself to factually portable SQL you'll very soon hit on limitations.

OTOH, a lot of the differences in the DQL and DML areas which concern the set of features common to all database engines are only superficial, ie syntactical. So assuming the database queries are properly encapsulated away from the application in a module as they should be, it wouldn't be hard to abstract away the differences between databases into several flavours of this module, of which one can then be selected by a configuration parameter.

What all that means is that it's preferrable to target a particular database at first and only refactor the business logic module that encapsulates the queries when time comes for that.

Makeshifts last the longest.

[reply]