On Tue, March 20, 2007 2:05 pm, Dan Shirah wrote:
> Each account is unique. It is possible that the same user could be on
> multiple accounts, therefore the account will be tied to the user each
> time.

If each account can have multiple users, AND each user can have
multiple accounts, then you have a "many to many" relationship.

A link_table of just account_id and user_id to tie the two together is
DEFINITELY the way to go for this.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

On Tue, March 20, 2007 3:31 pm, Dan Shirah wrote:
> Because in my application it is VERY VERY VERY important that I track
> the
> specific details for any given user in any given account. The user
> data
> changes frequently and I need to be able to track user information
> changes,
> numbers of accounts they are ***igned to etc.
>
> So rather than updating the user information or keeping one user and
> tying
> them to multiple accounts it is easier to maintain a specific user per
> account for our strict tracking needs.
>
> This way I can view all accounts the user is ***ociated with, track
> user
> information changes over months/years and provide detailed statsical
> reports
> to auditors.

You're making a pig's breakfast of things here...

If there is stuff about a "user" that changes from "account" to
"account" then that stuff is not REALLY about the "user" at all.

It's about that user's relationship to that account.

And it doesn't belong in the user table at all.

It belongs in the user_account_table -- the link table we are
recommending you use.

I guarantee you that you will be extremely frustrated with your system
if you go down the path you are thinking of now...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Richard Lynch wrote:
> On Tue, March 20, 2007 3:31 pm, Dan Shirah wrote:
>> Because in my application it is VERY VERY VERY important that I track
>> the
>> specific details for any given user in any given account. The user
>> data
>> changes frequently and I need to be able to track user information
>> changes,
>> numbers of accounts they are ***igned to etc.
>>
>> So rather than updating the user information or keeping one user and
>> tying
>> them to multiple accounts it is easier to maintain a specific user per
>> account for our strict tracking needs.
>>
>> This way I can view all accounts the user is ***ociated with, track
>> user
>> information changes over months/years and provide detailed statsical
>> reports
>> to auditors.
>
> You're making a pig's breakfast of things here...
>
> If there is stuff about a "user" that changes from "account" to
> "account" then that stuff is not REALLY about the "user" at all.
>
> It's about that user's relationship to that account.
>
> And it doesn't belong in the user table at all.
>
> It belongs in the user_account_table -- the link table we are
> recommending you use.
>
> I guarantee you that you will be extremely frustrated with your system
> if you go down the path you are thinking of now...
>
He might be fine with it even in the end, but I can bet that the users
are going to wonder, 'Well, I changed my p***word the last time I logged
into Account #1, but when I try and log in now, it says my p***word is
invalid..."

That they may not realize, is that they have different logins for each
account that they log into. Now they have to login to each account and
change there p***word.

Or even better, they call you and ask you to update their p***word
because they forgot it.

This is just one piece of your pie that might not taste to good once you
start eating it...