An application that I’m beginning to work on requires two different tables. The first table has “members” while the other has “users”. Both have a field called “ID”.
MEMBER TABLE:
ID – VARIOUS FIELDS…
USER TABLE:
ID – VARIOUS FIELDS…
The ID in MEMBER TABLE is set to auto-increment. This is to support continual registration of various members, however, I’m not sure I need to set auto-increment to ID in USER TABLE because the two users in both are not entirely exclusive from each other. In other words, a USER can very well be a MEMBER.
Should I just make 1 single MEMBER table and create fields inside it to represent user capacities or should I continue to create 2 separate tables?
That should be two tables. To save the same id in both tables you save in tha autoincrement one first then retrieve the last id to use in the insert to the second table.
This website / pseudo-application is going to be meant for a senate of an organization, so when I refer to “member”, I’m actually referring to “senate member”. I fear this probably helps in understanding what I’m trying to do here.
So with that being said, I thought it would be preferable to have a table for “senate members” and then another for “users” in that the user is someone who manages the members–equivalent to your basic admin, etc. After thinking this over, I began to believe that I should just have 1 single table for everyone and simply include the respective fields for authentication or admin-like capabilities. It made me second-guess myself, though, because of the other fields that would be in this same table, such as “office phone number”, “room number”, “department”, and other profile-like information. Is it okay to have that sort of information all in 1 table like this??? Does it break any pertinent MySQL laws?
