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.
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.
First of all, my apologies if this question is a duplicate - but I find it difficult, putting short, precise words on my problem.
I've got these entities.
The left contains several groups (like in Unix, in order to make data available to a whole group at once) and at the moment, it's always 1. The right one contains projects - and the middle one makes sure, that one group can gain access to several projects.
As you can see, there are foreign key relationships among them. Now, I want to create a new project in nmd__tree. When doing that, it returns an error:
Cannot add or update a child row: a foreign key constraint fails
(nmd.nmd__tree, CONSTRAINT FK_nmd__tree FOREIGN KEY (treeid)
REFERENCES nmd__helperusergrouphierarchy (treeidfk))
This makes sense, since the nmd_tree relies on a valid foreign key in the helper entity - but at the same time, it presents the problem, that the treeidfk isn't yet known, since it is autogenerated in nmd__tree
A solution could be to remove the relations, insert the record in nmd__tree, extract the newly written primary key (treeid) and create a record in the middle helper entity with the new id. It will work, but is really not very elegant. Also, removed relations presents other, potential problems.
My intentions are to create a query, that deals with this problem by creating both records at once. I know, it isn't possible to make a double insert and found this suggestion (my version doesn't write any records), as well as an article, suggesting stored procedures, which I don't see should make a difference
I would really appreciate a push in the right direction, please.
It seems you've got your constraints defined in the wrong direction; The middle table should have two foreign key constraints not the two end tables. That way, you can insert records in the two end tables and then link them up using the middle table.
My question is that can I use cascade with composite Primary key?
I have a table FbUser and a table FbFriends. FbFriends table has UID and FID as composite primary key, In other tables it is represented as foreign key(UID,FID)
If I make statement delete from FbFriends where UID="10" and FID="2" CASCADE, Will that delete the child rows as well?
ON DELETE CASCADE is an attribute of the foreign key. It is not a clause that you add to your DELETE statement. If the foreign key is defined to delete child rows when the parent is deleted, it doesn't matter whether the foreign key is defined on a single column or on multiple columns, the delete will cascade.
Personally, though, I'm not a big fan of cascading deletes or any other "magic" that happens outside of the logic in a piece of code. I've seen way too many cases where an ORM is misconfigured to do a DELETE followed by an INSERT rather than an UPDATE or where a developer builds a script that deletes and reloads some number of rows in a table inadvertently create a mess when a cascading foreign key or a trigger that wasn't looked at caused modifications to some number of other tables. If the original developer fails to realize that those tables are potentially impacted by his change, he'll certainly fail to test the data in those tables and the change can rather easily get promoted to production before users start seeing the problem and crying. Sure, it's more verbose to explicitly delete from the child table before the parent table. But doing so generally makes it much more likely that someone can read and follow your code in its entirety.
In the Oracle realm, for example, Tom Kyte is against cascade deletes. You can also find various cases where cascading constraints caused unexpected behavior because the developers maintaining a system didn't remember that someone long ago had configured the constraints in a particular way. Personally, I'd much rather get an error telling me that the database can't delete a row because there are child rows rather than potentially losing data that I didn't intend to lose.
I have a system that has categories that are joined to events. All of these categories are simple, they have an id, and name. One thing that worries me is that when I am creating these categories, the ids should always remain the same, be static. If I deleted one, let's say "Politics" at id=1, all of those events would have an orphaned category. One solution I thought of is to just assign string ids to them, so if they do happen to get deleted, it wouldn't really matter. What kind of solution do you recommend?
From my perspective it seems like you could keep the ids and just put a constraint that doesn't allow you to delete the record, only edit them. Another, is to use string ids, but that seems like a pain, although it seems to solve the problem of worrying about the ids being messed with.
Yes, this is what foreign key constraints are for. They also allow for rules on how to handle deletes -- for example, allowing a delete to cascade through dependent records, which is of course very dangerous and not what you would want in this situation. A simple basic constraint will do.
HOWEVER!!!! This is the important thing to understand about mysql. The default mysql engine (myisam) has absolutely no support for foreign key constraints. You need to use an engine that supports them -- most commonly innodb.
If you specify a constraint when you're generating your DDL, a myisam table will accept the constraint but simply ignore it, so make sure all your related tables are setup/altered to be innodb tables before you add your constraint(s).
How do you add a constraint?
ALTER TABLE `event` ADD CONSTRAINT `category_event`
FOREIGN KEY (`category_id`) REFERENCES `category` (`category_id`);
In this example, it assumes your event table has the foreign key category_id in it, to create your linkage. After adding this constraint, if you attempt to delete a row from the category table, and an existing event row contains that key, mysql will disallow the DELETE and return an error. This is discussed in great detail here: http://dev.mysql.com/doc/refman/5.6/en/innodb-foreign-key-constraints.html
I have a website which I have been working on creating very rapidly, and now am paying back some technical debt. I have a complicated issue:
My site deals with scheduling hikes. Once you create a hike, it has many things associated with it:
a message board, list of attendees, the group it belongs to, the carpool, route, trailhead, etc.
Here is an example so you can see what I am talking about:
http://www.comehike.com/hikes/scheduled_hike.php?hike_id=172
The technical debt I am talking about is that I never made foreign keys in the DB, and now need to do a cascade delete, and I am not sure how to go about it so that I don't introduce a million bugs :)
Should I make foreign keys for all the tables now? How should I do this?
Thanks,
Alex
Check out the MySQL docs on FOREIGN KEY Constraints. Note that you'll need to be using innoDB tables.
ALTER TABLE <tablename>
ADD CONSTRAINT <fkname> FOREIGN KEY <index name>(<columns>)
REFERENCES <othertable> (<columns>)
ON DELETE CASCADE
I would suggest creating foreign keys for the tables in your DB. This will be a more robust way of dealing with the problem you are facing. You obviously understand what a foreign key imposes on the database, and how to deal with the keys.
If I was faced with this problem, I would use a graphical interface for the database if I had one (e.g. PhpMyAdmin), otherwise a quick google brings up some tutorials.
EDIT: From the linked tutorial, in a many-to-one relationship, you pace the key on the "many" table, indicating that a certain column in that table can only have values that are present in a certain column in the "one" table. Hi the link for a worked example.
When adding keys to a table that already has data, you may not be able to add the foreign key if some of the data is malformed. For example, if you have a phone number table referencing a person table (many phone numbers to one person) and you have any phone numbers with an invalid person_id (maybe person 5 was deleted and there is still a phone number with a person_id of 5) you will be unable to create the foreign key until you remove the offending phone number.
if you have not made formal foreign keys, the have you made the keys some other way that permits linking the tables or are all tables unrelated ?
If there is anyway to relate the tables then you will simply have to write a Cascading Delete code.
Otherwise its probabely a redesign or add in foreignkey fun. =))
If you have not already get yourself a copy of MySQL Workbench and redesign it from there adding in the foreign keys. This will generate the SQL code for you too.
I would go with creating foreign keys as well but if there is any reason that stops you from doing so there is another solution which is creating Triggers. You can tell triggers to basically do anything you want when an update,delete or insertion occurs to a table in the database including changing other tuples in other tables. Here are a couple of tutorials on how to create triggers:
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_7004.htm
http://msdn.microsoft.com/en-us/library/ms189799.aspx
the first one seems more direct and clearer but if none of them helps just search google for DB triggers and you're all set!
I hope this helps :)