On Fri, 2004-01-23 at 17:08, Richard van Paasen wrote: > Consider this just a incentive to keep the database related code > separated from the freevo code so that e.g. mysql or postgresql can > replace sqlite. I've seen projects that incorporate sql statements > directly into the program code...
Having gone through in my professional service the transition from one database to another I would advise against this. I was going to bring this up with dischi, but will state my piece here. I would suggest the plugin stategy, we have used successfully elsewhere. Failing that I would rather see a rpcxml (or some other web service API) or at the very least the judicious use of the Business Delegate design pattern to keep the SQL as far away as possible from real code and just use abstract methods and objects from our software rather than some class from the database interaction layer. This we can define the interface and not have to conform to some individual piece of SQL softwares view of what the standard is. And believe me they widely vary. And can use the best thing available. Also someone may even what to use an object database too (right now it maybe a stretch but one rarely gets a straight answer from the magic eightball). /me steps off soapbox. -- Mike Ruelle [EMAIL PROTECTED] http://world.std.com/~mruelle/ ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
