Database

5-Jan-03 7:39

I'm creating a login system and I am wondering about the design i have chosen because it seems to be counter productive. Basically I have 2 tables as it stands:

BTW - MEID is members id, AUTHID is auth_users id

1) auth_users

PKID
MEID
USER
PASS

2) members

PKID
AUTHID
EMAIL
FNAME
LNAME
NLOGINS
OPTIONS
LASTLOGIN
EXPIRES

Anyways, initially the login required me querying only the auth_users table, but that changed when features were added. Like account expiration, number of logins, last login time and date, account privileges, etc. So my question is this, should I sticj with the current design and basically run two queries at login (login permission is cached in a cookie, so once you've logged in the system won't bother you again, nor will it run the query to authenticate users)?

Should I maybe add the required fields to the auth_users table instead of keeping them in the members table so I only have to run one query at login or should I keep it as is so I have to run 2 queries at login?

Thanks

"Two wrongs don't make a right, but three lefts do!" - Alex Barylski Smile | :)

Matt Gullett5-Jan-03 9:54

5-Jan-03 9:54

May I suggest a 3rd option?

Use 2 tables. Combine the auth_users and members table. Add a new table called user_props. user_props will need 3 columns.

pkid (ref auth_users)
prop_nm (char 50?)
prop_vl (text)

In the first table, plan on just keeping the absolute minimum # of fields you will need for about any system. (PKID, USERID, PSWRD, ACTV) may be enough.

Define your own prop_nm values and place all other user related details here, stored vertically. (Ideall you will have a 3rd table which has at least 2 columns and defines the prop_nm values you create.)

You will only ever need 2 queries and these should be encapsulated into a single ASP module, C# class or whatever. You will be able to add new properties whenever you want (there will be more, count on it.)

I use this tecnique for user definition and it has payed off many, many times. I don't recommend using this tecnique for just any data but for user login info, it is great.

Just my 2 cents.

alex.barylski5-Jan-03 12:54

5-Jan-03 12:54

Could I not store all account information inside a members table (access privileges, account expires, etc..) and only username and password inside auth_users. I'm thinking if I could then use an index on auth_users MemberID to quickly select the member information, this would be quite the optimization would it not?

i'm a total newbie with mySQL, so please forgive me if my terms are off.

]Thanks Smile | :)

"Two wrongs don't make a right, but three lefts do!" - Alex Barylski Smile | :)

Matt Gullett5-Jan-03 13:11

5-Jan-03 13:11

Sure you could do it this way. The easiest way if you want a 1:1 relationship between auth_users and members is to either use the same PK or add a column to one or both tables mapping to the other tables PK. The downside to using the additional column in only one table is that you will not be able to do a reverse lookup from the other table. The downside to using an extra column in both tables is that you will have to keep their values in-sync.

If this is the method you are looking at, I would recommend that you set it up so that their PK fields are the same. This way there is only 1 field to keep in sync and since it is the PK of the table you won't ever have to worry about it.

The method that I recommended was intended to make the user-solution easier to adapt to new requirements (account expiration, lockouts, limit to IP address, require SSL, log all activity, admin privilidges, etc). My experience has been that user authentication and user management is always a moving target. As a system becomes more complex, accessible or just management changes its mind, there tends to be more and more requirement for access control, authentication and logging mechanisms. It is virtually impossible to predict those requirements in the beginning.

The solution I recommend coped with this by proving a flexible property assignment mechanism that would make the DB schema and related code relatively imune to requirement changes. You still have to deal with the code that actually implements user-rights, logging, expiration, etc.

alex.barylski5-Jan-03 14:27

5-Jan-03 14:27

Matt Gullett wrote:
The easiest way if you want a 1:1 relationship between auth_users and members is to either use the same PK

I didn't even think of that...thats a great idea...because there will always be that one to one relationship. The solution I was looking for was more optimization than anything, not ease of implementation. Using the above one to one relationship model, is it possible to query only the authentication table ('auth_users') initially using something like:

SELECT * FROM auth_user WHERE user='Test' AND pass='Test'

Ideally I would like to use the PKID of the resultset returned from the above query and somehow use another query to return the associated ('members') table record. It's to my understanding that my default SQL(mySQL) automatically uses indexes on primary keys??? So really whats happeneing when I call the above select statement the record is being being indexed, rather then being located sequentially? I don't know if i'm accurate in thinking this or not.

I wouldn't care so much if the ('auth_users') table was sequentially searched becuz it's small in size. However the members table will be quite large so to have a query sequentially search each record here would be quite redundant. I could just make one query if I stored all this data in one table. Basically I would like to know if the following:

SELECT * FROM auth_users WHERE user='Test' and pass='Test'

and then

pkid = auth_id; // Copy the id from the above result

SELECT * FROM members WHERE pkid = auth_id

would cause the second select statement to use indexing by default so to avoid sequentially iterating records in the members table again. This to me seemed like the optimized approach, seeing how auth_users is a small table, so using it to index the equivilent record in the members table made sense. However i'm rather new at mySQL/SQL so i'm not sure.

I was hoping you could shed some light on this subject for me?

I appreciate all the help so far. Smile | :)

Cheers!

"Two wrongs don't make a right, but three lefts do!" - Alex Barylski Smile | :)

Matt Gullett5-Jan-03 15:26

5-Jan-03 15:26

Hockey wrote:
is it possible to query only the authentication table ('auth_users') initially using something like:

YES.

Hockey wrote:
Ideally I would like to use the PKID of the resultset returned from the above query and somehow use another query to return the associated ('members') table record.

You could do it this way, but typically you would just want to use a single SQL statement with a JOIN to get both the data from the auth_users and members table all in one statement.

SELECT A.PKID, A.USER, A.PASS, A.WHATEVERELSE, B.WHATEVER FROM auth_user A, members B WHERE A.user='Test' AND A.pass='Test' AND B.PKID = A.PKID

I don't know much about MySQL but every DB I have every worked with supports at least limited JOINS.

As far as the indexes go, every DB I have ever worked with maintains an index on PK fields. Leveraging the indexes a DB uses is the best way to insure performance. (Understanding how indexes work, what to index, etc is also pretty important, but for our discussion, this is enough.)

alex.barylski5-Jan-03 16:24

5-Jan-03 16:24

I just want to make sure I understand this correctly then (I really appreciate your help BTW).

With the code you provided above, the implicit JOIN, does the query use an index for both tables? I wanna make sure I don't sequentially iterate each record (especially on the members tables) if not nessecary. That is of course assuming my understanding of indexes is correct, but I think it's basically like a pointer.

So long as the above query uses an index on atleast the member table i'm happy.

Thanks Smile | :)

"Two wrongs don't make a right, but three lefts do!" - Alex Barylski Smile | :)

Matt Gullett5-Jan-03 16:50

5-Jan-03 16:50

I can't say that I'm 100% sure how MySQL will deal with this, but every DB I know of can handle at least 1 index per table involved in an SQL statement (with certain rules). Assuming MySQL at least provides for this (many DB's support many more indexes per table in SQL statment), YES it will use the indexes.

I know it sounds like I'm hedging my bet here, but the answer to your question should be YES unless MySQL really, really sucks. (From what I do know about MySQL it is designed for performance and this kind of optimization would be pretty important to performance.)

I have written an optimizing SQL parser/analyzer and I can say from experience that the most likely thing to happen is that the parser/analyzer will see that your SQL statement is using a PK (unique index) as part of the where clause (B.PKID = A.PKID) and will be smart enough to know to use th index. I'd be really surprised it it did not.

alex.barylski5-Jan-03 17:19

Re: ADO connection object

5-Jan-03 17:19

All i needed to hear. Atleast now I know the question would probably mysql specific and will ask if mysql supports multiple indexes in a single statement.

Thanks again!

"Two wrongs don't make a right, but three lefts do!" - Alex Barylski Smile | :)

ADO connection object

Shamoon5-Jan-03 7:38

Shamoon

5-Jan-03 7:38

How long will an ADO connection object remains connected to SQL server if there is no communication at all from the client side??

Matt Gullett5-Jan-03 9:56