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
Related
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 1 year ago.
Improve this question
I want to design a database which is going to consists of really lot of columns, since it's a web game's inventory but there is going to be really lot of things.
It would probably call for names like "item_1", "item_2" but is that even ideal?
When I plan it to be extended over 1 000 items?
I need to SELECT later if the user has them, every single one.
I plan to use MariaDB and Laravel framework with Jetstream, Livewire and Tailwind.css.
Before you do anything, read about
NF
1NF
2NF
3NF
BCNF
Bearing in mind the knowledge you thusly accumulate, you should reach to a conclusion similar to having some tables like these:
item_types(id, name, ...)
user(username, password, ...)
inventory(user_id, item_type_id, amount)
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 3 years ago.
Improve this question
I have multiple products/environment, like Google has drive, docs etc.
One common Auth server is there which will contain users table.
But I have roles table related to each product, which contains roles for user for respective product.
Now how to manage this roles table?
I have following ways to do this, which one is better and why?
Create common table roles in main schema, and have product ID to link the records in table.
Have different table in same schema with prefix product_name. Eg. prod1_roles, prod2_roles.
Have different schema in same database, for Eg. product1 schema contains product1 roles table and so on.
Which of the above approach should I go with? Creating different database for 1 table is not feasible for me. So I want to go with any one of above or any other better approach will be appreciated.
If all your tables could have the same columns, is better to have just one, in a central schema, using an product_id. You will use the same pattern for login all your users at different products. This make your security layer easyer to control. And this is an important feature.
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.
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.
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
This is not technical question, anyway it's related to good and clean code.
If I had tables articles and tags, I know the taggings can be good choice for middle table name.
What about other names? Like many-to-many in articles and cateogories. What's the best name for table between these two?
Is there any good approach? Or is it a question of English grammar? Please let me know.
Best approach in my opinion would be to combine the two model names into one: ArticleTag (TagArticle makes less sense here). If you call it Taggings, then you (or someone maintaining your code / database) won't realise the relationship right away.
Same for ArticleCategory (CategoryArticle makes less sense).