-> tiny POLL about Multiple Database Support

Hi there,

I need you opinion for the future.

For the moment, TBS supports several databases in native such as MySql, Sql-server, Odbc and Adodb. It also gonna suport PostgreeSql and Oracle.

All those suports are coded in one file. This does not dramatically slow down treatments. Using benchs, we measured that all-in-one database support is 'only' 10% slower than only-one database support.

For the future, the is the possibility to make the multiple-database support using external files. For example, named 'tbs_mysql.php', 'tbs_sqlserver.php',... and so on.

So my question is : which solution to you prefere ?
or

Thanks for you opinion.

I prefer separate files for different databases, if possible.

Should you support ADOdb, it would be swell.

I wish external files for database support. 10% is ever good to win !

OK, here's my take at it. This is what I actually meant in <a href=javascript:parent.m_Thr_Sel(window,123,474)>my first post</a>.

One of the greatest features I've found in TBS is it's database "awareness": It just understands that we, as webdevelopers, just want to output some database query rows to a template, in 90% of the cases. Thus, integrating this function to the template class itsef is a killer feature, if you ask me. It's just such a time saver. No more assigning query results to an array first (like Smarty) before parsing it. I honestly can't belive any of the other templating systems I've seen as noticed this issue so far... Congratulations to TBS for this. You're my #1 choice now.

Back to the topic. IMHO, "Native" support for multiple databases **inside** TBS is WRONG. Why?

1. It adds a bunch of useless code if you use a **real** DB abstraction class with TBS, as any abled webdeveloper should be doing now.

2. As good as it is, native TBS support for databases will never be as good as a "just-for-that-purpose" PHP class.

3. Don't reinvent the wheel. Rather than working in creating TBS own code to deal with other databases, use a well stablished, probed and open DB abstraction class. But don't create your own fork of any of them to integrate it with TBS, it'll consume your time and efforts and make TBS developing linger.

Instead, work to get a better way for TBS to interface with the selected DB abstraction class. It'll make you concentrate on making TBS a better templating system, **and just that**.

For example, wouldn't it be great if TBS caching functions could work with ADOdb query caching functions ?? ADOdb (php.weblogs.com) not only supports much more databases (also, much better) than TBS could dream of, but it also lets you cache the SQL query results to the filesystem, so that you don't send the same query to the server on each page load.

But that's the point, TBS should never try to do that. **It has already been done** TBS should try to be the best templating system around, and a better integration with a great DB abstraction class would be a step into that direction.

Skrol29: Make code reuse work for you. You've done some exceptionally good things with TBS, but don't overload yourself, don't reinvent the wheel. 

My final suggestions:

1. Strip all "Native" TBS database support.

2. Work on a better integration with ADOdb for all the database realated stuff. It'll make you start with many more supported databases servers for the next version of TBS, just to name one instant advantage. ezSQL class (ezsql.jvmultimedia.com) could be a second choice. Just don't choose PEAR::DB, please.

Greetings from Argentina, home of Tango, Maradona & Dulce de Leche!

I use TBS with ezSQL on a private web server everyday.
IMHO, TBS should not bother with database connectivity.
It's developper's job to bring the data to a template engine.
The data sources can be multiple, i can't even imagine how I would include, for instance, the files 'tbs_mysql.php' or 'tbs_odbc.php' if my template makes use of two different data sources.
I prefer the current solution.

As I already told u Skrol, i'd rather not use the database functions in TBS since i want to do more with the data before i parse it to the template.

Therefor I would love to see the external file function (so i could use NONE) to speed up things a little :)