Is it good idea to have database structure like this? Where in manager table id_item is like foregn key from school or company based on the type of the profile (id_item is school.id or company.id based on type field) Like dynamic variable in programming languages where it don't have a type.
Well why don't you create an organization table and reference it to the manager. Do you need this level of detail, having two separate entities?
A manager manages one or more organization.
An organization is managed by only one manager.
An organization can be a company or school.
A school has a location as addition.
Related
Currently, a hotel is managed by a single manager only. A manager can manage 0 to many hotels, as shown in the below diagram (unfortunately I can't post pictures yet, however I have provided the links:
https://postimg.cc/nXJtL2n5
Now there is a change such that some hotels will be managed by multiple managers, and others will still be managed by a single manager. For example, a hotel used to have a single manager, now it has a bookings manager, a cleaning manager, and a maintenance manager. I want all of these manager roles to appear in the HOTEL entity.
The below image is what I have so far.
https://postimg.cc/mzDP5RqQ
Is there a way to link the hotel with the new manager roles?
Any help is appreciated.
Cheers.
You need to create a separate entity for each of the managers e.g booking, cleaning and maintenance manager as a seperate entity; and then depict the 1:M relationships with the manager and hotels that they are managing. As a PK you need to have a unique key for each of those entitys so you can show the FK in the table they are referencing.
You want to avoid having M:M relationship so they need to be broken down to achieve redundancy in your final database design.
I am developing a REST API for a university to be used by a website and a mobile app. We want a registration functionality where students choose the courses they want to enroll in and submit the result. The results are reviewed by an admin, and he confirms the registration. From the back-end point of view, the submissions are stored somewhere in a certain form on the server so that the admin can review them later. The question is what is the best way to do this? Should they be stored as documents in the storage? In a database? In what form?
Note that there are other functionalities in the app that are already implemented and I'm using MYSQL as a database.
MySql is fine to do this. Basically, it is a many-to-many problem. The common way to deal with course enrollment service:
A student table with primary key, like student_id
student_id, student_name,.......
A course table with primary key, like course_id
course_id, course_name, course_context,.....
And key things here, a mapping table for course and student with status
student_id,
course_id, //these two colunms are used for mapping
status, // as you menthond, it maybe a temporary submit. And it could be permitted or ..
It is the basic construct, and you can add your specific requirement in these tables.
You can keep going with MySql. Everything you described fits perfectly MySql.
I have a Laravel project with a mysql database some constraints like this.
We have people and projects.
Every person is only assigned to exactly one project.
Every project has a manager who is a person.
So we have some foriegn keys project_id in person table and manager_id in project table and these cannot be null.
But now I have a chicken and egg project when saving because I cannot save a project without a manager and I cannot save a manager without a project.
Is there some way to do a single save operation for all of this?
You don't need two way binding. Only 'project_id in person table' is enough.
Then you can define the relationship in your models. In this case, project model should have a 'hasOne' method and the person model should have a 'belongsTo' method. Read this and try to implement.
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", ...
The following screenshot is ERD for one application or one business. If you have used QuickBooks youll know that it has starting form called company so in one application we can create many companies and maintain company accounts
if I add a column companyid to all table then I can add many companies in one application
what is the good practice:
Adding company key and exacting company info with company key
Creating database for each company if thrs 100 companies 100 mysql databases
please advice !
Creating a separate database per company is almost assuredly not what you want to do (unless you have a really good reason to need to do so). Adding a company_id to your tables and ensuring that columns you query against are indexed with company_id along with whatever other column you will typically be querying would be wise.
You'll also need to ensure that your application is designed to correctly inadvertent (or purposeful) access from one company to another company's data.
EDIT - Now that I see your ERD has been added: I would add a "company" table containing a company_id, name, and whatever other data you like, then ensure your other tables have an additional company_id field as well.
Since you want to maintain all companies' businesses and accounts within the same application, then there is no need to create a database for each company, just add a Companies table, then add a foreign key company_id to the other database tables