I want to make namecon of table "paper" as a foreign key reference to table "journal" to its primary key jname. I am getting confused with this view and not finding any tutorial or link which is explaining to set foreign key with this schema of phpMyAdmin. (Is it new or what)
Please someone let me to figure this out.
First, you need to create an index on the namecon column, click on the Structure tab ("Table structure" sub-heading on newer phpMyAdmin versions), then the Index text for the namecon column. You also need an index on the jname column in your journal table; in most of my databases this is an auto incrementing primary key but all that MySQL requires is that it's an index.
Next, go back to the Relation View (which is a sub-heading of Structure under newer versions). Note that this is in the area for "Foreign key constraints" not "Internal relations." Now you'll be able to select namecon from the "Column" dropdown:
If you want you can give it a name, otherwise MySQL generates one for you.
While making the foreign key, it is also advisable to mark the index key option available int Structure view of the table.
That will make the primary key thing to visible in the relational view of that particular table which can be used for making foreign key.
Related
I've searched a bit for this, but I actually haven't found what is the style conception in MySQL for creating a foreign key - in the create table definition or in an alter statement. Thank you.
When to create foreign key:
If at the time of table creation it is clear you that you need foreign key then do at the time of creation, but if you realize later then do it in alter.
Best practices: you can follow below practice, it is not must but you can get benefits-
constraint fk_tableName_colName foreign key (colName) references parent_table(referenced_col_Name) cascading if required
Note: As foreign key name must be unique, so it will help to maintain it.
Points Need to remember:
referenced table in parent table must be indexed (if primary key then no need as it will be indexed).
column in both tables (parent/child) must have same schema.
Have a look at the docs on how to create foreign keys...
http://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html
When a foreign key gets added can be during the initial architecture of the application being built or it can be added later as the application evolves.
So im trying to add an primary key and a foreign key to my table, but i just can't seem to get it to work. i've checked the forums already and other places but it didn't answer my problem. So here is my table:
http://puu.sh/mVW7D/5986e08daa.png
im trying to get VeiederID as my foreing key and keep studentnr as primary
but ive tryied to "alter table" and add the foreing key as constraint, but i might be doing it wrong, im very new to mysql. any help is appirciated
Steffen
Two points:
You do not identify the second table. A foreign key works between two tables and you are only showing one.
You do not specify which mysql version you are using.
Regardless: You should read the manual, reference: v 5.7 Foreign Keys
Update
I see from your updated example you are creating 3 tables and you want the rows in Veileder to reference studentinfo. So, the statement in the Veiled table should be
FOREIGN KEY (VeilederID)
REFERENCES studentinfo(VeiederID)
ON DELETE CASCADE
Apologies if the spelling is wrong. One other note, it appears you are trying to make the primary key (VeilederID) map to the foreign key. If I am wrong please comment but I don't know if that would be allow. Typically a table HAS it's own primary and a reference constrain (a.k.a. FOREIGN KEY) as a different column.
think i found it now i dont get an error while im running it this way, but if its right im not sure..
http://puu.sh/mW1Ze/ae333a40d6.png
A friend of mine just sent me an image of his new api database design.
When I saw it, I noticed that his user table had three primary ids.
I actually thought this wouldn't be possible.
It got me thinking... Is it okay to do this? As long as each column is unique?
I can't seem to find a reason not to do this, except the id is not primary if there are more than one.
Is this a bad database design? And why?
There should be only one column(s) designated as the PRIMARY KEY per table and most DB's will disallow usage of multiple PRIMARY KEYS. Note that a PRIMARY KEY can span multiple columns. Use UNIQUE for other column(s) that require unique values. UNIQUE keys can also be used in foreign key relationships.
I went over a legacy database and found a couple of foreign keys that reference a column to itself. The referenced column is the primary key column.
ALTER TABLE [SchemaName].[TableName] WITH CHECK ADD
CONSTRAINT [FK_TableName_TableName] FOREIGN KEY([Id])
REFERENCES [SchemaName].[TableName] ([Id])
What is the meaning of it?
ALTER TABLE [SchemaName].[TableName] WITH CHECK ADD
CONSTRAINT [FK_TableName_TableName] FOREIGN KEY([Id])
REFERENCES [SchemaName].[TableName] ([Id])
This foreign key is completely redundant and pointless just delete it. It can never be violated as a row matches itself validating the constraint.
In a hierarchical table the relationship would be between two different columns (e.g. Id and ParentId)
As for why it may have been created quite likely through use of the visual designer if you right click the "Keys" node in object explorer and choose "New Foreign Key" then close the dialogue box without deleting the created foreign key and then make some other changes in the opened table designer and save it will create this sort of redundant constraint.
In some cases this is a preferred way to reduce redundancy in your model. In using the self referencing foreign key (as shown in you example) you create a hierarchical relationship between rows in your table. Pay attention to what happens when you delete a row from the table, cascading on delete might remove rows you still want.
Using these sort of keys moves some of the data validation to the DB model as opposed to making this a responsibility of the program/programmer. Some outfits prefer this way of doing things. I prefer to make sure programs and programmers are responsible - data models can be hard to refactor and upgrade in production environments.
Note to Mod: I read through about a dozen posts that seemed to pertain to this issue, but none of them answered my question. Please do not flag this post for deletion; this is not a duplicate question.
I am building a database for a web-gallery that will contain many-to-many relationships. For example, tags and images. Obviously, to accomplish this a third, link, table will be created. I can see a use for having a primary key column in the tags table and the images table, but I can't imagine a use for it in the links table. It would just take up server space. So, I'm thinking of just not having a primary key column in the links table. Does MySQL allow this? Or, would there be any compelling reason to have a primary key in the links table? Thanks.
Link Table:
+--------------+---------+-----------+
| primary key? | tag ids | image ids |
+--------------+---------+-----------+
Clarification
Will not having a primary key in a table break the database?
There is no requirement that you have a primary key.
However, there is also no requirement that a primary key be only one field. In this case you might declare your primary key to be (tag_id, image_id).
You've got a question in reply to another post that gives me the idea that maybe you're thinking you should concatenate the two fields to make the primary key. Don't. Define the key as
alter table link add primary key (tag_id, image_id);
Do NOT say
alter table link add primary key (tag_id + image_id);
(I think "+" is the concatenation operator in MySQL. It's been a while. The SQL standard is "&" but MySQL uses that for something else.)
There's a big difference between the two, namely, in the first case, 25,34 and 253,4 are two different values, while in the second case they both get turned into 2534.
Will you always go from tag to image, or will you also want to go from image to tag? If you need to go in both directions, then you should create two indexes, or a primary key and an index, with the fields in both directions. Like:
create index link_tag_image on link(tag_id, image_id);
create index link_image_tag on link(image_id, tag_id);
If you make only the first (for example), then consider this query:
select tag.name
from image
join link on image.image_id=link.imagae_id
join tag on tag.tag_id=link.tag_id
where image.foo='bar'
This seems plausbile enough: find all the tags that match images that meet a certain condition. But without the second index, this query could take a very long time, because the db will have to read the entire link table sequentially to find all the records with a given image_id.
There is no need for primary key in the link table. Although a compound key is a good idea. Uniqueness can be achieved by using UNIQUE ( tag_ids, image_ids)
Yes, your primary key should be a compound/composite key of tag_id and image_id, i.e. PRIMARY KEY (tag_id, image_id). There's no need for an extra autoincrement column in this case.
When working with MySQL Workbench it's highly advisable because without a primary key it won't allow any access to your tables other than read only, which is a pain when trying to test your database. Although it does seem wasteful to have a PK that is never going to be referenced in a relationship.