The only time any data in the database which is not the original vB database structure will be dropped is if you select to [high]Empty the database[/high], but I think you can only do this via /install/install.php ;)

Satan

I cant ever see much of a reason to append fields to a vb table anyway. In fact, it really annoys me when I see macks that do this when its not needed.

The most common table modified is the user table. Why cant people just use profile fields? Thats essentially what its designed for. That or just include your own table that you can drw information from. Nothing worse than trying to uninstall a mod that has made changes to the underlying vb table structure.

Just my 2 yen (which of course comes to very little at the current exchange rate).

Because it's not very easy. First they have useless names (field6, field7, field8 etc), and secondly there is no way to know what the next one will be on any installation, it could be field6 on one, and field12 on another.

I would rather modify a table "needlessly" when it is the best option. Using a profile field means that you have to find what field it is in, which requires either a setting or a needless datastore row to keep track of. Adding a brand new table means you either add a query needlessly, or you modify queries, which mean needless file edits.

Modifying the user table is much simpler than either of the two alternate methods you mention. Either way, a hack should include an uninstall script.

With an install script it should be easy to fetch the last userfield used and increment that by one??

Or simply have the field be an option in the settings. I do this for GAL and GAB.

An extra table doesnt mean always mean an extra query - all that just depends on your design and (in the end) what youre trying to do.

Although there may be times where its unavoidable, far too many take the lazy way out and simpy append fields to the user table without exploring better and cleaner ways of accomplishing the same thing.

Do tell me how I can create my own table, populate it with EVERY user, then fetch this info as easily as $vbulletin->userinfo WITHOUT any extra queries and WITHOUT file edits.
If you can't do this, then you are full of it :p

Um - Do it with the freaking profile fields thats what they were designed for. Sheesh.

Things would also be made much easier if they would allow hooks into the queries as I mentioned in this post. Then you could accomplish much more (though I am sure people will still rely on appending extra fields on the end of the user table as it was the easier thing to do).

Isnt hacking the Tables about the same thing as hacking the files?

Even worse if you do it wrong.

If you alter any of the existing-default-not-touched vBulletin database structure, yes - If you add to it, no :)

Satan