sql in a single php library, so a database could be instantiated via lib changes?

[buro9]

I would like to see future vB become more flexible and offer multiple database options rather than just MySql.

Specifically I think this could be managed by having all SQL and database access conceptually removed from the core script and included into a single PHP file which will act as a Database Abstraction/Access Layer Library (DAL Lib).

This way, if a user wishes to use Oracle, or SQL Server, then the changing of which DAL Lib to use could be swapped in the config file.

It also allows other people to develop more database options, since a single highly commented DAL Lib could be used as the template for the creation of other DAL Lib's for alternate databases.

Having a single file hold all of the SQL, would allow people to hand over their DAL Lib to a DBA with no knowledge of PHP... so that they can model new queries and stored procs without needing a mind shift to get around the PHP.

Anyone doing this?

Cheers

David K

[JamesUS]

This is definitely planned, though not sure when for :)

vBulletin already uses a database abstraction layer - the problem with switching would be the different query syntax. Currently there is no mysql specific info in the files except for query syntax.

[buro9]

ah, but the point is that i can't give the PHP code to a db developer with the instruction 'change all of the sql to fit an oracle db' as the dba is just that, and wouldn't be able to understand where the sql was and would be afraid that the modifications would be problematic to the PHP.

so by having a single file (or even a couple, one for selecting data, one for inserting data) with minimal PHP acting just as wrappers to the SQL, it would simplify the task.

also, the PHP code lacks any useful level of commenting (has no-one at JelSoft read 'Code Complete'?) so knowing what the inputs are and their respective datatypes takes a debug trawl to find out where the hell it gets called, rather than the optimal thing of having queries act standalone and take x parameters and return x data (more OO).

looking at the code, it's easy to see how it's grown. there is a need for a code rewrite now, to allow for future growth. it should be structured in a more OO way with obvious objects performing very specific tasks very well. this would allow for a pathway to having multiple databases supported, as well as the possibility for multiple front end scripting languages (JSP?, ASP?).

if you want to move forward, if you want a larger sales potential, if you want corporate customers, this is the way you need to be going. and it should start sooner rather than later.

david k