[snip] > Let's say that I have users Mary, Joe, Frank, and Dan. I also have > servers panther, cheetah, jaguar and lion. The data for each account that I > want to maintain is UID, GID, home directory, and default shell. > In designing a table or tables to handle this example what can I > make as a primary key? My idea was to have a table named mary, with a row
With the name "mary", are you implying a separate table for each user? If so, that doesn't sound right. I think you should have three tables: (1) A table of users, with properties that depend on the user but not those that might vary with server; (2) A table of servers, with properties that are indepedent of users; (3) A table with primary key formed by a pair of foreign keys, one pointing at the user table, one at the server table. This table would have properties that depend on the user/server combination. (An example would be the shell, since presumably a user could have different shells on different servers.) > for each server, and each column would hold the data such as UID, GID, etc. > This would mean that the primary key for each row would simply be the server > name. > By holding all of the data, including server name, in a single > table, I am not sure how I would define a primary key. I couldn't use the > user name or server name as there would be duplication. I suppose I could > use a dummy numeric field that is auto-incrementing, but I am not sure how > good an idea this is. I think I have read somewhere that you can actually > use a combination of multiple columns as a primary key or index, but this is > something I am obviously not familiar with. > One other concern I have is regarding performance. The database > work I have done so far has been dealing with relatively miniscule amounts > of data. This database table however is going to contain information for > about 80 servers with somewhere around 300 users per server on average. > This is quite a large number of rows from my very limited experience. I Nah, doesn't sound like much data to me. > don't want to come up with a poor table design that ends up causing problems > down the line. [snip] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
