Using Laravel and MySQL Database
I'm developing a system intended for a doctor-patient management, where there is a parent table 'people' that includes all the general info of a person such as (name, ssn, phone, .......). then there is two tables that inherit this table ('Patient', 'Doctor') each one of them has different additional attributes.
Each person can be either doctor, patient or both.
but will have a different id as doctor and as patient.
What i'm trying to do is
Making Person model that extends eloquent and both
Patient & Doctor Model extends Person.
The output i'm hoping for should be like this
the Patient and all the attributes related to him in patient table and the attributes related to him from person table.
I can't find a way to call for example the patient with ssn = 1 Patient::find('ssn')->Person::find('ssn')to show all the attributes of patient with the related attributes from the parent table 'person' as well such as name, ssn and phone ......etc.
In a simple way i want a way to access the attributes of a person for specific patient.
I tried calling the person first then using the ssn to call the patient with the same ssn. but it felt like a relationship and not inheritance as i put the ssn as foreign key in the patient and doctor table.
Is there a way to do it with class inheritance or am i better using relationships and which type "polymorphic or normal" ? and how to call the person model in the patient model?.
Hope you understand what i'm asking.
Thanks.
Related
i have hit a road bump where i need to list all the current courses for students and instructors and i have 2 tables one of them is called students and the second one is called courses. I was thinking of creating a field for students called courses and then separating entries with a comma so i can use the WHERE IN clause but creating a table for each student is much easier.
As you have a many-to-many mapping, consider using a linking table with student_id and course_id columns.
I was thinking of creating a field for students called courses and then separating entries with a comma
Bad idea, and you're certainly not the first to have it.
creating a table for each student is much easier
Worse idea, and you're certainly not the first to have it.
Don't create database structures that require you to parse information from disorganized blobs. And definitely don't create database structures that require you to change the structure every time data changes.
What you're describing, the relationship between Student and Course, is called a many-to-many relationship. To achieve it, all you need is a "linking table" between the two entities. Consider something like this:
Student
----------
ID (PK)
Name
Course
----------
ID (PK)
Name
Simple enough representation of those two entities. Now all you need is a third table to connect them in a many-to-many relationship:
StudentCourse
----------
ID (PK)
StudentID (FK)
CourseID (FK)
A few things to note:
The name of the table doesn't have to follow this convention, this is just a common practice. You can call it anything you like. Enrollment might be a good name for this as it grows into its own entity.
This doesn't need its own ID (PK), its primary key could be a composite of the two foreign keys (since each pair thereof should also be unique in this domain).
This can quickly grow into its own entity if it has more data than just the relationship. For example, if there is specific information about a student's enrollment in a course which is specific to the combination of the two, but not specific to either entity itself. A registration number of some kind, a date/time of enrollment, etc. This table would become its own entity alongside the other two and be more than just a structural linking table.
I currently am trying to work out how to create a relational database for a University Module Options form. First you enter your student ID, Name, Surname and select your degree programme e.g. Human Resource Management then choose multiple modules through the form using checkboxes until the total credits for each semester for each programme is chosen.
However in choosing multiple modules and in being a relational database design i am unsure of how to store these multiple answers in the Student Options table as shown below.
I currently have the tables of
Table: Student
Field Names:
Student ID (primary key)
Name
Surname
Table: Programme
Programme (primary key)
Semester 1 Credits (different programmes allow different amount of credits )
Semester 2 Credits (different programmes allow different amount of credits )
Table: Module
Module ID (primary key)
Module Name
Credits
Prerequisite
The last table is one i am struggling with as after the modules are chosen from the form they will be stored in this table and currently have this...
Table: Student Options
Student ID (primary key)
Programme (link to programme table)
However i am unsure what fields to have to store them in without being too cluttered and still having a link to the modules table as shown below which are all stored individually.
Does my modules table need to have a relationship link to the student options table to be a relational database ?
How would i store the multiple modules chosen into the student options form?
Thanks
As for your core problem, I think the database design outlined below should be sufficient:
You should not store both, the modules a student selects and the programme he is enrolled in in the same table. Instead do it like outlined above.
The programme a student is enrolled in should just be a foreign key in the student table, therefore giving you a one-to-many-relation (This is a crucial point though, because this means any one student can only be enrolled in one programme! If your database has to be able to have one student be enrolled in more than one programme, you need a many-to-many-relation there too.).
The modules should be related to a student via a middle table (I called it StudentModule in this case), therefore giving you the desired many-to-many-relation. What you now have to do of course is check via code, if the module isn't already selected by the student (as well as all the other small and big details there are...). But this you would have to do with any database design as far as I know.
As you can see, I also inserted a middle table for the module to programme relation. This is because I assume that one module is eligible for multiple programmes. By relating modules to programmes in this way, you can then check for stuff like "can this student elect this module", ...
I have two type of user in my master table Doctor and Hospital both user has common fields like Name,Address,Contacts etc.
But there are some different fields which is connected by foreign key to this table
Like for Doctor it has
one to one relation with specialization and department table
and for Hospital
has one to one with service and one to many with facilities table
Now my question is What should be the database schema for this type of relation, At present I made separate table for both Doctor and Hospital but the fields like Name,Contact and Adreess repeating in both table.
It sounds like Doctor and Hospital are both subclasses of some superclass, and the fields that repeat in both of them are attributes of that superclass. Do some google searches with either of these two search terms: "Generalization/Specialization" or "Class Table Inheritance". That second term will show you some specific designs for implementing subtypes or subclasses in relational tables.
You might want to ask the question of in the Database Administrators area. There is a tag called "subtypes" over there with one question in it. It's asking the same thing you are, in a different case.
I have three tables,
student, studentclass , class
student have sid as primary key, class have cid as primary key.
studentclass ties student and class together and has two columns, sid,cid (no special keys).
Is it possible to get rid of studentclass table and use student and class tables only, without creating duplicate entries in student or in class tables?
(class can have multiple students and student can attend multiple classes)
Thanks.
If the business logic states that, one student can attend multiple classes then it is good to have a linking table, StudentClass.
You can think of this as a Many to Many relationship where one student can attend multiple classes and one class can have multiple students.
The studentclass table is required assuming that students attend more than one class.
If they do not you can simply add a classId field into the students table and get rid of the studentclass table.
Without the explicit columns, and having previously written a college registration system many moons ago, here are some of the tables that I had implemented.
Student - obvious, list of students, primary information, etc
ClassCategory - Generic categories... (ENG)English, (MTH)Math, (SCI)Science, etc, not the specific class level, but the categories
ClassCourse - These are the things that would be found in a syllabus.. ENG-101, MTH-210, etc. This would have the common information describing what the class was about, not who was teaching, credit hours, etc but the material covered, maybe any pre-requisites, basic syllabus for someone to review content.
Semester - List of semesters, such as Winter-2013, Spring-2014, etc.
Facility - List of facility locations that a given class would be taught -- could be buildings, campus, etc
Teacher - list of teachers, there contact information, whatever, regardless of specific classes they might teach.
ClassOffering - Here is where all the courses would be, when offered, etc and would have its own PK ID, but also the ClassCourse, Semester offered, Facility, teacher and specific room and times. You could have the same "ENG-101" course offered 5 times in a day for day and evening classes by different teachers and time slots.
StudentClasses - This is what you are currently at. This would have which student and which specific class OFFERING they enrolled in. Additionally, at this record you could have a drop, withdrawn status, etc and what other settings may be specific, such as credits attempted, earned, final grade, date completion, etc... This table would be the basis of computing GPA for a student.
EACH of these tables would have their own respective "PKID" values and each table SHOULD have their own.
Although this is not an obvious complete database, but it hopefully can lead you to a better consideration of what you may need to consider.
I am creating a database for a university dept(for internal use) and this database tracks issues related to people. I get information of only employees at the university and I am tracking them using their university ID. But the database is also intended for people who are not employees at the university or even sometimes people outside the university. I want to assign an ID to these people but store values within same column as university id. Any ideas how I should tackle this issue? I don't know how to keep the univ id and the no. I am going to give to the others in the same column and yet treat them differently (when needed). How do people usually tackle such issues?
PS: I do not like auto numbers since I cannot delete an ID and get it back into the database
Your best bet here is probably to create a common Person table for all people which simply tracks an Id, then relate separate tables for each of the different kinds of people (ex. Employee, Student, etc.) to it - note that all of these names are just examples. Each of these tables would contain a foreign key to the Person table. In effect, this logically make each of them a different "subclass" of person.
For example, Employee my be related to Person via the foreign key
[Person.PersonId] {PK} <==(1-0)==> {FK:Person.PersonId} Employee.PersonId
This is generic for any Other entity:
[Person.PersonId] {PK} <==(1-0)==> {FK:Person.PersonId} Other.PersonId
Note that any columns common to all types of person may exist directly on the Person table, with each of the "subclasses" of person only recording columns specific to its particular type.
In addition, you may create a view with joins these tables to present a "combined" generic record for people. In some cases, it's useful to include a column in the view that simply indicates which table an individual record came from (ex, class or type.
I personally would not want to mix the two different kind of ids within one field. This is just waiting for trouble when you migrate since you need to keep these apart by convention or through other fields.
You will of course use the uni id to search the person ...
(uni id and an id for people not on uni)
Approach 1 - introduce an additional table
Issue
- id
- person_id
Person
- id
- university_person_id (optional)
University Person (table)
- id
Approach 2 - make the university ref id optional
Issue
- person_id
Person
- id
- university_ref (optional)
What do you think?
But if you really want to go along with mixing the two kind of ids within one field I suggest to use a prefix followed by a generated number.
EXTERNAL-123456
You can also introduce an additional field external_contact (boolean) or contact_type 'Uni' or 'External'. Also add a unique index on the two combined.
Hope this will give you some food for thought :)