Database design need better solution many to many [closed] - mysql

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a table like:
classes:id,time_instructor_id
instructors:id,name
I want each instructors to have one or many classes which is fine with my current design...
What for ex in the future one instructors leaves the job and another one can substitute that instructor, how do I assign the class to the new Instructor?
I was thinking in this case if I could have a N:N table?
What is your opinion?

You have no problem. If an instructor leaves and another instructor is added and takes over the first instructor's classes you can simply UPDATE the instructor_id value for those classes with the new instructor's id.
You do not need a many-to-many table unless you want to be able to assign more than one instructor per class.
Is there more to your requirement than stated in your question?

Yes, you can create third table called classes_instructors (this might depend on the framework conventions) which will have two attributes, maybe 3rd one to show whether is it active.
id
class_id
instructor_id
active
This is pretty common schema and pattern to use a many-to-many relationship through a join table. Some people tend to call it associative table or entity many-to-many relation.

Related

Partial Dependency in DBMS [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have an EER diagram of the hospital database. I am currently working on the normalization process.
As I understand the partial dependency is when an attribute is dependent on only the part of the composite primary key. And this should be removed.
I've applied the rules on my database but still want to make sure that these tables doesn't include partial dependency.
In examinationo table the composite key consists of inpatient_no, doct_no and lab_no. In my opinion diagnosis and conducted_test attributes depend on all three of them. Is this correct?
This table has composite key of inpatient_no, doct_no and surgery_no. The attributes date and time convey information when the inpatient will undergo the surgery. Is this a partial dependncy?
I'm very new to databases, so my quesitions can be quite easy.
It looks to me like your table called inpatient_undergoes_surgery represents an entity, in this case an event. The table has one row for each surgical appointment. It has date and time as attributes. It also has one-to-one relationships to an inpatient, doctor, and surgery.
This table appears to be normalized to me. The others might not be. In particular, it's possible that your surgery table duplicates the information in this table.
Pro tip It's best to use a DATETIME or TIMESTAMP data type to represent the kind of date and time in your table. There's no need to use separate columns for date and time. Understanding that the date and time taken together are actually a single attribute of your entity helps clarify your design process.

MySQL user data storage [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have two tables that should somehow be associated. Let's call them table_a and
table_b. A row in table_a can be associated with multiple rows in table_b, and the same goes the other way around. How could I achieve this? Should I use a pivot table?
Both tables have an auto-incrementing id-column.
What you're looking for is called a many-to-many relationship (a given user has zero or more games, a given game has zero or more users). This is typically handled with a "mapping table", e.g. USER_GAMES which has a user_id and a game_id, uniqueness is on the combination of these. http://www.joinfu.com/2005/12/managing-many-to-many-relationships-in-mysql-part-1/ has some good details.
As it is a many to many relationship, an intersection table with the user ID & game ID would be the best. Otherwise you would have to parse the list of game ID's stored in the user table and that would cause performance issues.

Database schema for activity related to many entities [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
How to build a nice schema for activities in a database?
One activity can relate to one of 50 different entities.
For now i see only 3 solutions:
Table "activity" contains 50 columns with foreignkeys to the other entities.
This results in a very big table, which i do not like.
Each entity has its own "activity"-Table.
This solution results in nearly doubling the tables in my database, but its clearer. Still not the best solution.
Dirty one: "activity"-table contains one "entityType"-column with the entity-table-name and a other "entityId"-columns with the id to the entity.
But this solution break all foreign-keys and allows to store crap data in my activity table.
Perhaps somebody of you build a CRM and had to face with the same problem.
Does anyone have a better and clean solution?
Like i see, there is only a decission to make. First and second possibility are good because the keep the consistency of the db. In my case i decided to use 1. possibility.

Mysql database structure for realestate directory [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I really need help to make a decision.
I'm working on a real estate online directory.
People can add their property in several categories like apartment, land, shop ... and each category has its features that some of them are shared between categories like City but some others are unique or shared between 2 or 3 categories like "number of rooms".
So i have three solution :
keep shared features in one table and put others in an other table in meta_key - meta_value format like tagging system.(seem reasonable)
Put all features in one table.(dirty)
Put each category in separate table (this is worst idea).
The site will serve too many searches. but most of them are based on shared features.
which solution looks better?
Why wouldn't you just create a table of the properties and then tie them together in a table like so:
Categoryid | PropertyID
Also making both columns a composite unique identifier will prevent from duplicate occuring with the table. This allows you to create unlimited properties and assign them to any category.

Should this be an identifying relationship or not? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
well I've posted this question originally on StackExchange for database adminsitrators:
https://dba.stackexchange.com/questions/28356/should-this-be-an-identifying-relationship-or-not
But it seems to lack users I guess. So can anyone help me with this?
Edit:
Alright, I chose to have a non-identifying relationship, this way the User can be Patient, SpiProfessional or both. Seems to work better, even though it's more work when writing queries. Thanks for everybody's answers, they all contributed to my understanding of databases.
Need to know more information in order to answer your question.
Can a user be Patient?
Can a user be a SpiProfessional?
Can a user be a Patient and a SpiProfessioanl?
What additional data/attributes need to be stored for the patient?
What additional data/attributes need to be stored for the SpiProfessional?
OK, here is what I think based on your design.
The User table and Patient table, it shouldn't be 1 to 1 relationship, as the user may not be a patient, so it should be 1 to 0..1 relationship.
The same goes with SpiProessional. The user may not be a SpiProfessioanl, so the User table to Spiprofessional, should be 1 to 0..1 relationship.
I think it's worth to have a look at these two post.
1. Any example of a necessary nullable foreign key?
2. Implementing one-to-zero-or-one relation in SQL Server