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.
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 6 years ago.
Improve this question
I have two tables in my db:
Marketers:
Id, Username, Password, Email
Stores:
Marketer Id, 1 Store, 2 Store, 3 Store, 4 Store, ...., 10 store
there is the names of 10 stores for every marketer in Stores table.
So there is a one to one relationship between these two tables. right?
I'm wondering if it would be better to just combine these two tables or not.
I wan't to send a lot of query for the second table (Stores tables). so I though this would be better if I separate these two cause I rarely need the information stored in 'Marketers table'.
From a good design perspective, you should keep these tables as separate.
for your current requirements,
if you do not need data from Marketers so often, why do you need to include that in Stores. you would just end up fetching extra data each time.
say if tomorrow if some new info and the mapping changes to one to many or vice versa, your current design will work perfectly fine.
and of course from future maintainence view, it is easier to update current design.
although, i would also, suggest you to add an independent primary to Stores table also.
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 like to use tables as it will allow me to organize the data in a better manner. But now inside my application I am using tables to represents different data which can give misleading meaning. for example I am displaying the list of all record in a table such as:-
Then I am also displaying the details of each record in a table where rows will have different context:-
For me the tables seems clear ,, but am I using tables in the right context?. Or usually table rows should represents the same type of objects (for example different organizations, not different properties about an organization )? ?
Well. Most systems show information using tables. Look at any forum software, for instance. In terms of user-friendliness, you could emphasize your header rows on your top table. On your bottom table, you could emphasize the left row (a darker background or stronger font).
In my opinion using tables in this scenery is ok. All data is exhibited in simple and clear way.
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
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I have several databases represents the companies we work.
In every database there are fields which we work on.
And in the fields area, there are field infos and our engineer who worked at that field.
I need to search all databases and filter with engineer names, to get a list of fields he worked.
I hope I could explain.
Any simple solution?
Nope. You're going to have to manually write queries to search each table in each database. The whole idea of database schemas and tables is that they are distinct wrappers for data, which can't be implicitly joined.