I'm putting together a question and answers application - the answers are only going to exist as long as there is a question that relates to it.
So I've decided not to give the answers table it's own id column and have made the primary key a foreign key that relates to the question_id.
Questions table:
id | title
Answers table:
question_id | title
Should I keep it this way or give the answers table it's own id column?
If there is possibility of multiple answers for a single question then it will be better to have a primary key on answer table too to identify each row uniquely if we get duplicate answers as follows
id | question_id | title
1 1 5
2 1 5
3 2 true
But, in case you are anticipating only a single answer for each question then it is better to merge it to the question table as both question and answer are directly dependent on a single primary key.
id | question | answer
1 quest 1 ? 5
2 quest 2 ? 5
3 quest 3 ? true
4 quest 4 ? null
I hope, this clarifies your doubt.
To expound a bit on the two valuable comments that have been made, in my experience, the following is the most effective set of rules to follow when defining a database schema (I will give reasons after):
Create a Primary Key for each table
Create a surrogate key to be that Primary Key
When you have a one to many relationship (as you do in your questions & answers tables) include the PK from the one table (your questions table) in the many table (your answers table) NOTE: this is exactly as you have done it... except the answers table doesn't have it's own PK & surrogate key
When there is a many to many relationship between two tables create a linkage/join/relationship table which has a one to many relationship to your two tables (meaning you put the Primary Key of each table into the relationship table as a foreign key to the two tables, respectively)
REASONS (in the same order):
Primary key columns guarantee uniqueness for each row within the scope of the table itself (no other database object has to be involved & every row will be required to be unique). They also provide a default index in most databases, which speeds up table scans/queries. As, mentioned this effectively meets first normal form.
I've found surrogate keys to be a powerful & effective way to simplify both database design & relationships between tables. If you aren't familiar please read here: http://en.wikipedia.org/wiki/Surrogate_key
You have done this already, so I'm assuming you understand the benefits.
This is here simply to provide an example of how using surrogate keys as primary keys in every table can help you as a database schema grows. If you need to add other tables in the future you won't have to spend as much time & effort figuring out how to join them you already have all the keys you need to easily create a join table (for instance, if you later add users to the mix... users can be the author of either a question or answer OR both... this could get a little harry if you attempt to associate the SAME value to both the question & answers tables independently... in fact it won't work)
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 3 years ago.
Improve this question
When creating a new index it seems that people try to avoid holes inside it, and usually use auto-incrementation. But why? What the reasons behind that? Maintenance? Security? Or simply not beautifull?
Because in my case, I'm suppose to create a book catalog database and for consistency reasons I would like to make sure that the index of the "book" table matches the fragment of the ISBN number corresponding to the publication number of the 1st edition of the book at this publisher.
However some reissues have their own ISBN but won't be counted as a book entity in itself and so will create holes (data of reissues will be merged with 1st edition data).
I use MySQL 5.7.23 with phpMyAdmin.
Here the view from the junction of the tables "Book" and "ISBN" I aim
num_book | ISBN
--------------------------------
1 | XXX-X-XXXXXX-1-X
| XXX-X-XXXXXX-5-X
| XXX-X-XXXXXX-9-X
| XXX-X-XXXXXX-14-X
2 | XXX-X-XXXXXX-2-X
3 | XXX-X-XXXXXX-3-X
| XXX-X-XXXXXX-6-X
| XXX-X-XXXXXX-8-X
4 | XXX-X-XXXXXX-4-X
7 | XXX-X-XXXXXX-7-X
| XXX-X-XXXXXX-13-X
10 | XXX-X-XXXXXX-10-X
11 | XXX-X-XXXXXX-11-X
12 | XXX-X-XXXXXX-12-X
15 | XXX-X-XXXXXX-15-X
I intend to use "num_block" with these intentional holes as primary key of the table book and then join with ISBN table.
The index numbers will remain increasing but wouldn't necessarily be successive (i.e. 1, 2, 3, 4, 7, 10, 11, 12, 15)
Should I worry about that and why ?
Thanks by advance for your attention.
Edit : Oups as scaisEdge said, forgot can't start index with 0, corrected.
More clarifications & disambiguations about explanations and the sketch (add legend) : it's not the same table a but a view from the join of two tables (books and ISBN), so "num_book" value are unique but can be bind to severals "ISBN".
I think you are referring to a few different concepts all at the same time.
There is a difference between a primary key and an index.
A primary key is a logical concept - it provides the unique, unchanging reference to a row in your table. As other entities refer to the primary key, it may not be null.
An index is a physical concept - it's a way for the database to look up entries in that column. You can specify that an index is not null, and unique.
The usual way to physically implement the logical concept of primary key is through a unique, not-null index.
The next question is how to assign the primary key; there are two candidates: natural keys reflect an entity in the problem domain, and surrogate keys are assigned automagically by the database.
In practice, there are very few natural keys (guaranteed unique, not null, unchanging) - I don't know enough about how ISBNs are assigned to have an opinion whether they are suitable. But I've seen problems with social security numbers (they get entered incorrectly into the system), phone numbers (people change their phone number), etc.
Surrogate keys are assigned by the database engine. They are often auto-incrementing integers, but they can also be UUIDs - as long as they are guaranteed unique and not null. The reason auto-incrementing integers are popular is for a couple of reasons.
Many primary keys are implemented using clustered indexes. A clustered index affects the order in which data is stored on disk, so if you have a clustered index, inserting record with ID 1 after you've written record with ID 1000 means re-ordering the data on disk, which is expensive.
Gaps are not really a problem - as long as you're inserting sequentially.
However...this logic is from the 1980s. Back then, a clustered index was notably faster than a non-clustered index. On modern hardware, that's not true in most circumstances.
So, there is no obvious reason why your scheme for assigning primary keys would be a problem as long as you are confident about the way ISBNs are assigned.
How do I setup fields to be dependent on what foreign key is input?
I have googled and searched stack overflow, using similar questions to that, but couldn't find anything that fitted what I was looking for. There are pictures and an example below to better describe what I am asking.
Here's my table (that I want fields to be dependant on there foreign keys):
jo_route is a foreign key for this table:
and jo_type is a foreign key for this table:
When I go to insert a record into the journeys table, and select the route id. How do I get the corresponding information from that foreign keys table to appear in the respective fields in this table.
For example, jo_type as 3 records (as shown in the picture). The foreign key jo_type is linked with this table. Say I select the ID for air (2) in the journeys table. How do I get the related fields (jo_seats_total) to be automatically chosen from the travel types table? So it should appear as 100.
Hopefully I have explained my problem well enough.
Thanks in advance for any help!
Sorry for the long post.
I hope this is something that you looking for...
SELECT t.tt_max_seat, t.tt_name, r.ro_origin, r.ro_destination,
j.jo_seats_total, j.jo_seats_take, j.jo_seats_available
FROM journey j
JOIN route r ON j.jo_route = r.ro_id
JOIN type t ON j.jo_type = t.tt_id
WHERE j.jo_type = 2
This question already has answers here:
How to design a product table for many kinds of product where each product has many parameters
(4 answers)
Closed 7 years ago.
I'm creating a structure of DB by E/R Diagram, but I'm stuck since some days on this problem. Probably I'm wrong in the way I'm doing it, so if you think I can do it in a better way, would be lovely :)
The scenario is:
I have N users who owns N sensors, not all the sensors (in the future could increase to 300 kinds of sensors) have the same features(columns), so I suppose I need a table for each sensor and then list the inside the values collected.
I have some doubts regarding how to referentiate the tabless for "kind sensor"-"Sensors" wich columns should I put on the "sensor" table, also in this way I will get many tables. Do yo have any hint?
Simplest and easiest way to do it is to make all specific columns in your table "sensors" and have one foreign key to another table "sensor_type" which is consisted of 2 columns
table "sensor_type"
id_type - identifier (primary key)
description - description of your sensor (heat, temperature sensor ... )
Your table sensor then looks like
table "sensor"
id_sensor identifier (primary key)
id_type foreign key references sensor_type table
size default null, if type 2 or 3 then something
weight default null, if type 1 and 3 then something
etc...
You need to understand this is probably one of many solutions which can solve your problem. I hope it helps.
May be it's better to introduce Many to many relationship between sensors and features they have? For example like this:
Sensors
sensor_id (pk)
type
Features
feature_id (pk)
name
SensorsFeatures (Ownership table)
sensor_id (foreign key to Sensors.sensor_id)
feature_id (foreign key to Features.feature_id)
If you need to store values of these features (weight, height, width,...) , you can do it in SensorsFeatures table.
You should add new table e.g. sensor_type for all sensors, where each row will be the sensor with uniq id which can be added to user.
The idea is to separate sensors with type or something else which is the most common thing beaten sensors.
I am in a situation where i have to store key -> value pairs in a table which signifies users who have voted certain products.
UserId ProductID
1 2345
1 1786
6 657
2 1254
1 2187
As you can see that userId keeps on repeating and so can productId. I wanted to know what can be the best way to represent this data. Also is there a necessity of using primary key in here. I've searched a lot but am not able to find the exact specification about my problem. Any help would be appreciated. Thank you.
If you want to enforce that a given user can vote for a given product at most once, create a unique constraint over both columns:
ALTER TABLE mytable ADD UNIQUE INDEX (UserId, ProductID);
Although you can use these two columns together as a key, your app code is often simpler if you define a separate, typically auto increment, key column, but the decision to do this depends on which app code language/library you use.
If you have any tables that hold a foreign key reference to this table, and you intend to use referential integrity, those tables and the SQL used to define the relationship will also be simpler if you create a separate key column - you just end up carting multiple columns around instead of just one.
Take the following database tables
|========|
|user |
|========|
|id |
|username|
|password|
|========|
|=========|
|blog |
|=========|
|id |
|date |
|content |
|author_id|
|=========|
blog.author_id is supposed to connected to a particular user.id, whichever user who wrote the blog entry obviously.
My question is with regards to 1:1, 1:n identifying and non-identifying relationships... I don't really understand them very much. Should this relationship be one of these types of relationships or not? And if so, which one? And what is the advantage of this?
In this example, there's a 1:1 relationship between a blog record and an author. The reason they exist as separate entities/tables is the grouping of information -- user related stuff doesn't belong with a blog record, and it could be duplicated if someone writes more than one blog.
The reason you want that implemented as a foreign key constraint is because the constraint ensures that the author for the blog record exists in the user table. Otherwise, it could be nonsense/bad data. The foreign key doesn't stop duplicates -- you'd need a primary or unique key for that -- the foreign key only validates data.
Now that Nanne clarified the identifying/non-identifying terminology for me, the blog.author_id would be the identifying relationship. Because it's identifying who (what user record) the author is.
The id column in both tables can be assumed to be be the primary key, because an artificial/surrogate key is the most common primary key. Which makes these columns the non-identifying relationship...
As a blog and a user are seperate things, and not defined by eachother, these are non-identifying relationships. One can be something without the other, evne though the author-id might be mandatory.
Also see this link for more explanation about the two terms: What's the difference between identifying and non-identifying relationships?