Only if you want it to be user editable with the profile. Otherwise, the user table is the correct table to modify.

Well, we shall have to agree to disagree. The user profile fields are not just for editable fields - they are for custom user table fields. Otherwise they would just simply append the user table whenever an extra field was required.

Me? I prefer to avoid using any of vbs tables if I can help it which so far has been every time. For those options that would require an optional field, I use the profile fields for the job and it works just fine.

When I hear the purists that shout 'dont mod the file' and happily alter the tables... I have to pleasently chuckle.

Remember though, that adding to the table structure does not invalidate support - Altering existing vBulletin files does ;)

In this respect, their attitude makes more sense :p

Satan

At the very least it will require one or more joins, otherwise you wouldn't be storing the data. Joins can and often are as resource intensive as additional queries, especially if the table is not fully optimized and in sync with the table you are joining it to.

it may not count for the upgrade discussion, but it counts for the database changes discussion

it doesnt? where can I find that info

https://vborg.vbsupport.ru/showthread.php?t=91582

In particular this post by me:
https://vborg.vbsupport.ru/showpost....9&postcount=25

and here on the vBulletin.com forum:
http://www.vbulletin.com/forum/showthread.php?t=145472

However if you alter an existing vBulletin field, or add your own field that happens to conflict with a future vBulletin field you will be told to revert your database first.

well that's not general.

if you change original tables, the supportteam will ask you to revert them, exactly as they do with templates, or when they ask you to upload an original file again..

bahh, i get too slow....

alright, so by "adding to the database" you mean adding tables or adding columns to a vB table?

Yes.