Modeling Account types and number of tables needed (1 Viewer)

[SkeletorPlus]

I am trying to model some Active Directory account stuff in MS access. I have an “Accounts” table, but I am finding it hard to mode a “user account” vs a “service account”. Is the best way to do it just keep it all in the same accounts table? Or do I need to make stemmed tables? I can’t see stemmed tables flowing well for data input, and I don’t know how to hid irrelevant elements from a form if a different account type is selected. Anything helps!

 

[theDBguy]

Good question. I am not very familiar with the differences in attributes between the two accounts; but if they have any common traits, I might suggest storing those in one table and just split the rest in separate tables. Unless, if the number of different attributes is not a lot, you might also consider just throwing out all the data in one table and accept the consequences of storing null values in some of the columns. As for "hiding" what's not needed based on account type, that's easy once you get into forms for data entry.

 

[arnelgp]

maybe 1 table with "AcctType" to input whether "user" or "service".

 

[Gasman]

maybe 1 table with "AcctType" to input whether "user" or "service".

That would be my first suggestion, which is the simplest.

 

[mike60smart]

I am trying to model some Active Directory account stuff in MS access. I have an “Accounts” table, but I am finding it hard to mode a “user account” vs a “service account”. Is the best way to do it just keep it all in the same accounts table? Or do I need to make stemmed tables? I can’t see stemmed tables flowing well for data input, and I don’t know how to hid irrelevant elements from a form if a different account type is selected. Anything helps!

Are you able to upload what you have currently created in Access?

 

[The_Doc_Man]

A user account in Windows is just an artifice to convey things like privileges and permissions. A user account is exactly the same as a service account until you fill in the specific properties of the account. You can assign permissions. You can grant privileges. You can have account policy actions. Some of the odd permissions include "DENY permission for INTERACTIVE use" - so you can't log in as SYSTEM, for example. Obviously, you don't log in to service accounts. But at the end of the day, a service account is just a particular kind of account, just like a user account is just a particular kind of account.

If you are on a Windows Server system, the account is also the artifice for tracking system usage if it is a pay-for-play timeshare setup.