Jeanne Boyarsky wrote:
Suleman zia wrote:I My question to you is how much database space do you think should be appropriate for JForums ?.
It's impossible to say. It depends on how much content you will have. I realize you don't know this either, so you'll have to guess. I agree with Ulf that it's better to have more space than less.
Suleman zia wrote:Any issues which you encountered while merging the software will be very helpful.
The links Jaikiran provided contain most of my thoughts on this topic. One big thing - we decided to fork from JForum 2.1.8 and are not merging our changes into the main stream. This means we own our fork forever. If you ever want to pull in JForum again, I recommend donating as many of your changes back to JForum 3 as possible.
That said, we make more changes that you'll need to. Partly because we needed backward compatibility with our old forum software.
Ulf Dittmer wrote:
I think i will go with 20GB for the start.
Even for a company where every penny counts, that doesn't make sense. The price differential between a 20GB disk and a 200GB disk is so small these days, that this will turn into a loss if you even have to move the DB once in the app's lifetime because of limited disk space. While 20GB is plenty for a stock JForum installation, DBs have a tendency to acquire new tables and new attributes over time, in addition to the growing amount of data. It may seem penny-wise to save on hard disk space, but it's pound-foolish.
Jaikiran Pai wrote:
Suleman zia wrote:Any issues which you encountered while merging the software will be very helpful. As of now i have made alot of changes and has been testing thoroughly on my local machine. Found couple of bugs with SSO and the forum software itself but was able to fix it also.
I don't know the answers to your other questions, but you might find this journal article by Jeanne useful. Jeanne played a major part in the forum migration and has blogged about some of it here
Ulf Dittmer wrote:Asking about DB size is a bit odd. Hard disk space is so cheap these days that it rarely makes sense to worry about it, certainly not for a DB that mostly contains human-created text (the amount of which is likely not to grow all that fast). Why are you concerned about that?