v3 - Db Backends?

[etones]

Hows the backend db plugin system coming along?

Will we or will we not have the choice of different DBS... im itching to get a postgre convert,

Cheers

[Wayne Luke]

A DB Plugin system has not been announced and as far as I am aware not in development. We do hope to support other RDBMS in the future and Postgre is one of the ones talked about but nothing is definate at this time.

[eva2000]

TBA ;)

i'm not a developer but i believe vB 3 will be out before there is a port not sure :o

[etones]

:(

groan.. ok

well, db ports, are you gonna wait until someone else gets this feature in before you pull the finger out or are we gonna see some action?

Regards

[eva2000]

Originally posted by etones
:(

groan.. ok

well, db ports, are you gonna wait until someone else gets this feature in before you pull the finger out or are we gonna see some action?

Regards did i mention the ports for sybase/postgresql have already been underway but they will be no where near ready for even any type of testing yet... you'll get vB 3 way before the ports from my understanding

[etones]

Originally posted by eva2000
did i mention the ports for sybase/postgresql have already been underway but they will be no where near ready for even any type of testing yet... you'll get vB 3 way before the ports from my understanding

Me thinks you forgot to memtion that george :D

What approx min time scale we looking at here? 3-4 months for a workign product?

Cheers

[eva2000]

Originally posted by etones


Me thinks you forgot to memtion that george :D

What approx min time scale we looking at here? 3-4 months for a workign product?

Cheers probably much longer but i have no idea the specifics etc

[JamesUS]

While they are being worked on, they are not our main focus or priority at the moment so as such won't be done anytime soon unfortunately. We may change the way things work a bit in vB 3 which could make this easier to do anyway.

[etones]

ok, cheers

still holding out for the postgre release :)

you'll get a huge influx of orders from large commercial sites with huge user bases

[Floris]

MySQL is good enough, I have a small site, and do not want any other database to be supported... but that is just me.

[etones]

Originally posted by xiphoid
MySQL is good enough, I have a small site, and do not want any other database to be supported... but that is just me.

im still fumbling around lauging on the floor at that statement... would you also like some gas for the lamps you use to light your house and some chicken feed for the chucks outside?

For a site with 1 user at a time, mysql cuts it.. for decent bigger sites.. mysql does not cut it! think! And for exactly what reason would you not want better database developement?!? or do you enjoy living in the stone age? want me to book you a ticket out into the african bush land.. you'll love it there... no moderen facilaties or developements at ALL! wow!!

Regards

[tubedogg]

While I don't agree with his sentiment, MySQL is stable and cuts it for larger sites, up to about 1100 concurrent users, 50,000 registered users.

[Mas*Mind]

Originally posted by etones
want me to book you a ticket out into the african bush land.. you'll love it there... no moderen facilaties or developements at ALL! wow!!

:rolleyes:

[etones]

maybe I did explode slightly :p

Sorry all, was having a bad day..

Regards

[Mas*Mind]

I recommend you to visit Africa someday though... You'd be surprised...

[etones]

oh, i wasnt making a persnaol 'dig' at africa :) I know parts of it are very well devloped and its a helluva nice country (may dad is african), I was talking about the 'great planes' with the lions roaming :) Get dumped there and your the native's food in a few short days :)


Regards

[CoreOne]

I had one small question. I took a quick look at the mysql code and wondered why it would be so difficult to transfer it to (at the very least) PostGRE. I replaced all the code and references to mysql_xxxx to the corresponding pg_xxxxx PHP code and the only function I couldn't figure out was the function "insert_id". This is the only function that cannot be directly translated into a PostGRE equivalent. I'm not very experienced with vBulletin's code and haven't looked into playing with it too much, but I wanted to know where the major hang-ups were. Is the actual SQL code used in the inner workings of the system (like joins) the problem? I wanted to know because I am trying to re-write a db_postgre.php file so that I can connect it to my PostGRE backend. Any hints/comments would be greatly appreciated since I would love to convert this over as soon as possible. Thank you.

P.S.> I have the db_postgre.php file that I converted (save the insert_id function) if anyone would like to look at it. Just drop me a message.

[JamesUS]

The DB file is not the main issue...the query syntax used throughout vB is largely incompatible with Postgres and other engines. Some of the queries will work, but most of the more complicated queries will need rewriting. This takes a huge amount of time, and becomes a nightmare to maintain when new versions are released.

[ml1]

This may be something the vb developers could benefit from:
http://www.phpclasses.org/browse.html/package/20.html
You may have to register, but there are some pretty nice classes here.

[JamesUS]

Unfortunately we can't use public classes as they would violate copyrights. As I said above the classes are not the problem; we could convert our DB_MySQL class to any other db in a matter of minutes. The problem is rewriting the hundreds/thousands of queries in vBulletin to be compatible with the new database engine's syntax (and make use of non-MySQL features like subqueries, stored proceudures, foreign keys etc).

[Mas*Mind]

I don't really understand what's the problem on this matter; If you create a proper 3-tier design (gui layer, business layer, database layer) then it's not really a problem to create a application that can run on different database systems. You can even make it file-based if you want.

some pseudo-code:

gui layer:

showForum(forumID)
{ $forumDetails = $system->returnForum(forumID)
//process to show and convert to HTML
}


business layer


returnForum(forumID)
{ // all kinds of checks
return $mysqlLayer->selectForumDetails(forumID)
}


mysql database layer


selectForumDetails(forumID)
{ $query = "SELECT * FROM forum WHERE forumID = $forumID";
//your mysql dependent code here
}

[Wayne Luke]

3-Tier designs are expensive to implement, maintain and test. That is the problem. The 3-Tier design is why Web Crossing, Particpate and other large companies charge 10s of thousands of dollars for a community solution.

Now granted vBulletin will probably be heading that way in the future but to implement it all at once will cost all the customers (current and future) a pretty penny. So you can have 3-tier or low cost at this time.

[NetherChris]

Stepping off topic, I am a postGRE newbie and I really don't know anybody about it.. could somebody break down simply what the advantages are and if there is a price? (or a link) :)

[Mr. X]

http://www.us.postgresql.org/

Intro here (http://www.us.postgresql.org/users-lounge/docs/7.1/tutorial/preface.html#INTRO-WHATIS)

You could also look around at dbforums.com :)

From my understanding postgresql can handle huge traffic and high volume boards, and from what I've read on Arstechnica some say its also easier to develop for compared to mySQL for example.

Then again Im a moron so dont take my word for it.

[rylin]

Originally posted by etones


im still fumbling around lauging on the floor at that statement... would you also like some gas for the lamps you use to light your house and some chicken feed for the chucks outside?

For a site with 1 user at a time, mysql cuts it.. for decent bigger sites.. mysql does not cut it! think! And for exactly what reason would you not want better database developement?!? or do you enjoy living in the stone age? want me to book you a ticket out into the african bush land.. you'll love it there... no moderen facilaties or developements at ALL! wow!!

Regards

Not to be annoying, but we have 53'401 registered users right now, 1'400'000+ posts & 140'000+ threads with typically around 200 - 300 users online, and as we speak, "apachectl status" says there's 68 requests currently being processed

loadtime is typically under 2 seconds on a normal connection (256kbps +), and the server loadaverage is 0.57 as we speak

if that's your definition of 1 user at a time, then.. well.. :P
although i don't doubt pgres can (currently) handle a higher rate of transactions etc, i'm very keen on finding out the differences when mysql 4.x goes stable

as to why someone might not want a "better" database environment, it's all in the eye of the beholder

for instance, although there's quite a few good techies around that know postgres, there's possibly even more who know mysql, as it's mentioned quite often (eg. companies are more likely to spend time & money on training their employees)


just my $0.02 in whatever currency they use in africa ;)

[Mas*Mind]

just my $0.02 in whatever currency they use in africa ;)

Rand, South African Rand ;)

[buro9]

Originally posted by wluke
3-Tier designs are expensive to implement, maintain and test. That is the problem. The 3-Tier design is why Web Crossing, Particpate and other large companies charge 10s of thousands of dollars for a community solution.

Now granted vBulletin will probably be heading that way in the future but to implement it all at once will cost all the customers (current and future) a pretty penny. So you can have 3-tier or low cost at this time.

Erm, the Model/View/Controller pattern is the most widely used paradigm in Internet programming. I'm not sure how you've decided that this is expensive in any way.

Model = Database itself.
View = Web Pages, usually the HTML and Templates.
Controller = PHP or another script to stick the above two together.

Take a look at the Java patterns on the Sun site, the recommendations from Apache (especially the struts pattern which is similiar), read any of the books from Addison Wesley on Extreme Programming... MVC is the simplest, most widely used, efficient (from a production/maintenance perspective) pattern on the market.

n-tier applications can spin out of control (I know I currently work on an app with 11 tiers... but then we have 1 million unique users per hour at peak), but 3-tier is actually the best one out there.

Just my $0.02

Cheers

David K

[Mas*Mind]

I agree with you buro9, I don't really see Wluke's point...

At least you allready have the support for other DB-back-ends when you implement it this way and can members port it to other DB systems themselves easily.

I think it will only save you costs, because in the end it only saves you developing time. Currently the whole system needs to be rewritten in order to achieve multiple DB backends...

[Fusion]

Originally posted by Mas*Mind
I think it will only save you costs, because in the end it only saves you developing time. Currently the whole system needs to be rewritten in order to achieve multiple DB backends... Too true. Unfortunately, this is probably the very reason why we shouldn't hope to expect this anytime soon. Evil circles tend to do that to you.

[Wayne Luke]

$300,000 to test and develop on Oracle
$125,000 or so to test and develop on MS- SQL Server not counting the hardware.
Unknown costs to test and develop on Sybase.

Now I haven't worked with these systems for a couple of years now but those are the costs to install the software on a single server that is publicly accessible.


Or are you suggesting we just code for these databases and hope it works? You could counter that someone would donate the server space. However numerous times in the past, I have offered to develop both Oracle and MS SQL-Server versions of the software if someone provided the server. They always came back that they couldn't afford to do that even for a limited time basis. Makes me wonder why they want to port it over.

We have already stated that a Sybase version is in development. It most likely will not be immediately available at the 3.0 launch but it is in development.

You may think it is cheap but even the table layout we have now for MySQL won't work in some of the database systems available. The SQL standard is adhered to less then the HTML standard if you want to get right down to it. It is much more than the queries and handling of those queries that would need changing.

[alexi]

Not to be annoying, but we have 53'401 registered users right now, 1'400'000+ posts & 140'000+ threads with typically around 200 - 300 users online, and as we speak, "apachectl status" says there's 68 requests currently being processed

Yup, all is well untill about 5-600 users...then it starts to get ugly quick...we have had 1285 online and it was really really ugly! From what I have seen total posts, threads or registered users don't matter a hoot... it's simoultaneous online that will kill you.

My feeling is that VBulletin is excellent software at a great price. If the developers are saying they can't afford to develop a solution to help the larger sites at this time than that's the way it has to be. I know they have been whined at by enough of us that if they had some way to do this they would. In the mean time we try to get by!

[Mas*Mind]

Originally posted by wluke
$300,000 to test and develop on Oracle
$125,000 or so to test and develop on MS- SQL Server not counting the hardware.
Unknown costs to test and develop on Sybase.


Ofcourse this is a problem, but I'm sure there can be found a solution for this?

We have already stated that a Sybase version is in development. It most likely will not be immediately available at the 3.0 launch but it is in development.

Then I'm wondering how you are implementing this if not 3-tier :confused:

[Fusion]

Originally posted by Mas*Mind
Then I'm wondering how you are implementing this if not 3-tier :confused: If I am to hazard a guess, it will probably be the same as today's MySQL-only version, that is, the Sybase-version will be completely separate.

[Mas*Mind]

hmm, but what about all the queries scattered through the code?

[Fusion]

Sorry? What I meant was that the Sybase-version will probably be a separate release, with its own queries etc., and that the two versions (MySQL or Sybase) won't be interchangeable.

[buro9]

ah, now this is where php classes come into their own.

you use them as the data abstraction layer.

the php and templates call classes to supply the data... the classes reside in the db_***.php files... let's say db_mysql.php included as a part of global.php

this way, the top end php would remain the same for both a mysql and sybase version.

you only need change the classes themselves (the raw calls and population of the values of the class) in order to swap databases.

that side is relatively easy, though i can understand wluke's arguments and the mess it would create to try and solve the current system.


on the licensing front, my company (and the one i worked to prior to that) both negotiated free oracle licenses, even publicly available. providing they were development machines as part of a development project only. meaning that there was no license fee providing the code on these machines remained in beta.

why? well in both instances, our successfully using oracle resulted in more sales for oracle. precisely what vbulletin could argue with ease.

an oracle port would interest corporations and would lead those corporations to purchase further licenses to accomodate vb.

and always good for a debate like this with oracle is the, "we may have to resort to using sql server to attract corporate clients, microsoft have been very keen for us to do this"... you'd be surprised just how effective that one line is ;)

cheers

david k