New answers tagged normalization
1
So it's actually pretty easy to normalize when there's multiple fields, some with varying amounts of data points in a single field of the same row. Just follow this rule: Any column that has multiple data points within the column of the same row should become it's own table. So in your example that could be Cast and Genre. It's immediately apparent that ...
1
Normalisation is to remove information from tables, that are repe4ated by many times and ids as int are smaller than any text.
The bridge Tables you need, because you have a m:n relationship between film and users(cast, director, musician...)
Occupation is in my opionion a attributs of the relationship between film and user
Film (idfilm,Titel, plot,Wiki_Page,...
0
This might sound a bit crazy, but as noted by ypercube in the answer linked in the comments, it is best to consider this a separate relation: for which we need a new table Question_CorrectAnswer, and it's PK is QuestionID.
This means that we only need to update a single row to change the correct answer.
Our only issue is that to prevent update anomalies, ...
-1
As you seem to prefer a 1:1 relationship between questions and answers and you also don't want to reuse answers, add the CorrectAnswer to the answer, so you can have multiple correct answers per question and a re so more flexible.
CorrectAnswer is more a Attribute for answers than for questions, so it makes more sense to put it there
Question ...
0
If you add CorrectAnswerId to your question table, you don't have to update all the answer rows, assuming only 1 question is correct.
That being said, you probably may want to have multiple choice questions, right? Is not a big deal to have to update multiple rows in a transaction.
Your design will normalized enough with either option.
0
you need the supplier id in the card, if there are multiple suppliers for one product and the customer selects a specific supplier. but you also save ot in the card_item.
a card table you only needed, if there are multiple cards per user.
Usually you have only one card per customer, which you can save in such a table for later use. so i can't see ,why you ...
0
In modeling, it is important to understand why a particular design is chosen beyond doing what has been done before.
So going from what you have shown alone, suppliers can figure out which of their products are in carts so do not need to be linked directly to carts. From the same data, without a supplier, there’s no need to have a cart table because there ...
1
What you are describing is called slowly changing dimensions (SCD), with each configuration item being essentially a dimension for the measurements (facts). If you don't want to switch to a database that supports temporal queries, you can still implement one of the SCD approaches in MySQL (which temporal tables still do under the hood anyway). You don't need ...
2
Here are some random thoughts. I guess the configuration could change without the existence of a datapoint at that particular point. First I would have a table for the sites:
CREATE TABLE sites
( site_id ... NOT NULL PRIMARY KEY
, <other attributes>
);
Now, you can have your table relate to that
CREATE TABLE measurements
( site_id ... NOT NULL ...
Top 50 recent answers are included
