Skip down for TL:DR version
Currently designing a Horse-riding class booking function for a Club's website.
Designing the SQL database from scratch using phpMyAdmin. Members join the club as per family basis - Meaning each unique "Family_ID" would contain multiple members within each one.
The club only wants users to login with their Family_ID and through that one login the user would be able to book a riding class for any of the members within the family. was wondering if it's possible to give each member a unique ID by referencing the Foreign Key (Family_ID). So each member would have a unique ID based on their Family_ID. Example Listed below.
When a new family registers for the club - they fill in paper forms which an admin will enter their details into the existing database, currently the members don't have an ID, just details kept within each Family_ID. Was thinking of a work-around where when a new member is being added the form would have an auto-fill input box that adds '01'/'02'/etc to the ends of family_id.
TL:DR
SQL - phpMyAdmin
Multiple Members within a "Family_ID"
Multiple Members share a "Family_ID" (Foreign Key from "Family" Table)
Each Member to have a Unique ID - "Member_ID" (That uses the Family_ID as a prefix)
Example
Family_ID = 0024
Member_ID = 002401 (Unique Member_ID Auto_increment using last two digits)
My first post so I apologize if I left out any necessary information, Thank you for your answers.
Related
I created 3 tables for store users, students and examiners.
Users table contain login details
id
name
email
password
user_type (3 user types: 1 - administrators, 2 - students, 3 - examiners)
user_type_id
If user_type == 2 or 3, then based on that value, user_type_id field get
student id or examiner id, if user_type == 1 then value == 0.
students table contain student details
id
name
age
birthday
examiners table contain examiners details
id
name
age
qualifications
my question is, is it ok to use above way to link users, students and examiners?
If not please suggest a way. Thank you.
First of all: your data model needs some improvements.
You put age attribute and birthday attribute in Student. Adding age in database is incorrect. You should use only birthday. Same problem in Examiners.
The best practice for designing data model for Information Systems with Authentication (and Authorization) is to separate them into 2 modules in Data Model. AA module and Other parts of Information System. This separation has som advantages like extendability of your whole system and usabilty of AA in other systems and etc.
Another improvement is to define a new Entity named UserType and use the foreign key in Users entity.
When you use both Student ID and Examiner ID in one attribute in Users entity, your model is not Normal and you can not set foreign keys.
Secondly: To provide a data model
we have relationships between Users and two other entities (Student and Examiners). Maybe in future other entities added to this list.
We have 2 relationships:
one relation between Users and Student and another relation between User and Examiner
These relationships are one-to-one. For example each Student has one User and each User can be set for only one Student. And similar statement between User and Examine.
In one-to-one relationships we have 2 solutions:
1- pass primary key of Entity at side 1 in 1-1 relationship as foreign key to
Entity of side 2.
2- pass primary key of Entity at side 2 in 1-1 relationship as foreign key to
Entity of side 1.
Both solutions are true and Normal. So we have 2 solutions for this case:
Solution 1: transfer User ID as foreign key to both Student and Examiner. In this solution we can easily find each User ID of specific Student or specific Examiner. But the hard part of this solution is finding a Student or Examiner based on User ID. Answer is: Notice that we have User Type for each User ID. So based on User Type of User ID, we know which table to be search (Student or Examiner).
Solution 2: transfer both Student and Examiner IDs as foreign keys into Users. Meaning that User Entity have 2 foreign key. First for Student ID and Second for Examiner ID. This solution seams so effective. But it conflict Modularity of AA Module (Authentication and Authorization Module). Another problem emerge when the number of other tables (Student, Examiner,...) that have relation with User is HIGH. Anyway, in small Information Systems we can use this solution.
I am working on a group management page with a variable number of tabs from which the admin(s) of each group on the site can choose for their page. Admins shall also be able to create group member roles, assign privileges on the tabs to those roles, and assign roles to the members. Any member can also belong to one or more groups.
I have sketched out some tables for the database to this. Here are the three of interest:
groups
----------------
GroupID <- PRIMARY KEY
GroupName
GroupDescription
group_member_records
--------------------
GroupMemberRecordID <- PRIMARY KEY
GroupID <- FOREIGN KEY: references groups.GroupID
GroupMemberID <-FOREIGN KEY: references group_members.GroupMemberID
GroupMemberRoleID <- FOREIGN KEY: references group_member_roles.GroupMemberRoleID
group_member_roles
-----------------------
GroupMemberRoleID <- PRIMARY KEY
GroupID <- FOREIGN KEY: references groups.GroupID
GroupMemberRoleName
// NOTE: GroupID,GroupMemberRoleName UNIQUE
I initially decided to just give group_members a GroupMemberRoleID foreign key, but the problem with that is that it would be possible for a member to belong to multiple groups, and have a group member role, and that group member role would be different for at least two of the groups of which that member belongs to! Thus, I moved the GroupMemberRoleID foreign key to group_member_records.
Before I finally implement that table that records all the tab privileges for the groups, I would like to know a couple of things:
Is there any risk of circular reference? I have seen closely related question answered here, but am unsure what they mean by:
This is not a circular reference.
It would be if emails would have a strong integrity relationship to
invitations and invitations an independent strong integrity
relationship back to emails (for example).
(my bold on what was unclear to me)
Is this, at all, bad design or bad practice?
I'm running for office and have created a web app for tracking my door knocks to voters at their homes. The database contains a table called voters that contains all the necessary information about voters in my community.
I'd like to add a new feature to track donors to my campaign. Not all of these donors live in the community and do not vote in the district where I'm running for office. I do not need to track the same kind of info for these individuals as I do for the voters so I'm going to place these individuals into a table called nonvoters.
Now, the individuals in my "voters" table can also make donations, and I want to track those as well.
To track the donations from both voters and nonvoters, I'd like to set up a new table called "donations." This table would contain the appropriate details about the donation.
But I'm uncertain as to what the best structure is for linking the donations table to the "voters" and "nonvoters" table. If I create a column called voter_id in the table to key it to the donors information, there's no way to know which table that ID refers to. So do I set up two columns, nonvoter_id and voter_id and insert the ID into the applicable column depending on whether the donor is a voter? This seems weird.
Or maybe I create a column in both the voters and nonvoters table called donor_id that I can use to link my data in the donations table. If I went this route, it seems like I'd have to do a some behind the scenes work to ensure the donor_id was unique and was keyed to the data inside the donations table.
Or maybe there are other approaches I'm not familiar with. Any guidance is appreciated.
I would use a single table for voters and non-voters, let's say persons. You can have a flag in the persons table that indicates if the person is a voter or you may even derive this from their address (if that's possible).
I would create a donations table and link each donation to a person (or persons) in the persons table using the id in the persons table. If a donation can be given by multiple people, then you will need a 3rd connection table with person id and donation id as 2 fields. These 2 fields would be the primary key for the connection table.
Im new to building databases and have seen both examples of using and ID field or changing the field to a related name such as user_id is this just preference?
I guess it's a matter of personal taste. What I've come to find useful is to name the ID column id, but in tables where this is a foreign key, name it table_id.
For example, the ID column in the users table could be named id, but the foreign key in the table that assigns user rights to users it would be users_id to make clear that this is a reference to the users table.
I had to implement the following into my database:
The activities that users engage in. Each activity can have a name with up to 80 characters, and only distinct activities should be stored. That is, if two different users like “Swimming”, then the activity “Swimming” should only be stored once as a string.
Which activities each individual user engages in. Note that a user can have more than one hobby!
So I have to implement tables for this purpose and I must also make any modifications to existing tables if and as required and implement any keys and foreign key relationships needed.
All this must be stored with minimal amount of storage, i.e., you must choose the appropriate data types from the MySQL manual. You may assume that new activities will be added frequently, that activities will almost never be removed, and that the total number of distinct activities may reach 100,000.
So I already have a 'User' table with 'user_id' as my primary key.
MY SOLUTION TO THIS:
Create a table called 'Activities' and have 'activity_id' as PK (mediumint(5) ) and 'activity' as storing hobbies (varchar(80)) then I can create another table called 'Link' and use the 'user_id' FK from user table and the 'activity_id' FK from the 'Activities' table to show user with the activities that they like to do.
Is my approach to this question right? Is there another way I can do this to make it more efficient?
How would I show if one user pursues more than one activity in the foreign key table 'Link'?
Your idea is the correct, and only(?) way.. it's called a many to many relationship.
Just to reiterate what you're proposing is that you'll have a user table, and this will have a userid, then an activity table with an activityid.
To form the relationship you'll have a 3rd table, which for performance sake doesn't require a primary key however you should index both columns (userid and activityid)
In your logic when someone enters an activity name, pull all records from the activity table, check whether entered value exists, if not add to table and get back the new activityid and then add an entry to the user_activity table linking the activityid to the userid.
If it already exists just add an entry linking that activity id to the userid.
So your approach is right, the final question just indicates you should google for 'many to many' relationships for some more info if needed.