[eluser]skunkbad[/eluser]
[quote author="jedd" date="1245600657"]Note that if you have two tables, where the sets of data in each table are totally reliant on the same PK, then you're doing it wrong. If you're heading down this path, then the point of a 'user prefs' table is pretty much lost. You should simply migrate your preferences into additional columns of your user table and let go of the separate prefs table.
And indeed that's how I do it with my user table - there's a bunch of BOOL columns for things that every user has one and only one choice about, or setting for.
Future changes will necessitate an additional column, but this is no big deal. Compared to the additional code needed to handle the settings and interpretation of a new setting it's pretty trivial. If you want to get smart about how you handle the user configuration page, you could have all your prefs prefixed with pref_ or similar. I forget who, but someone in a recent discussion about table design suggested all their bools start with is_, which might be another approach. This would let you progammatically deal with all is_ or pref_ columns with a loop in your form - but you'd still obviously need more sophisticated code changes to deal with the affects of that setting.[/quote]
I somewhat agree about the choice of having the same PK in two tables being wrong, but the reason why I do this in my own database is so that there is a core table for authentication, and if there are account details per user (which may change from site to site), then they reside in the second table. Sure, the core user table could be modified, but it was just my way of thinking (which is the way I like it!).
