I'm using MySQL Workbench to model my database. In it, I have the option to create relationships by identifying foreign keys, etc. What's the point of this? I am able to run my queries just fine without these relationships.
My tables do have an actual column for foreign keys, I just didn't define them in MySQL Workbench. Meaning, I don't have those lines connecting the tables.
Foreign keys do a few things. Most obviously, they provide you with built in data integrity, as Macy Abbey mentioned.
Interestingly, the query optimizer of your favorite RDBMS can also use constraints like foreign keys to do additional optimizations. Basically, the database can determine if it can do a better job of writing a query than you. The presence of foreign keys lets the database make these assumptions. You can find a great example at Do Foreign Key Constraints Help Performance?. While that link is SQL Server specific, the principle is the same regardless of database engine.
Foreign keys are useful for ensuring data integrity. If you define them, the database itself will make sure that an invalid foreign key value will not be allowed to be inserted into the table.
If you do not have Foreign Keys, you do not have Relations. Therefore you do not have a Relational database; it is a bucket of fish, with no integrity, and you won't have the power of a Relational database (Jeremiah's answer is just one item of many).
Here are some benefits you gain from using foreign key relationships:
Referential integrity (of course)
The optimizer can in some cases generate better execution plans
Tool support (metadata, migration, analysis etc)
I use every type of constraint available, at first.
Then if it is shown to hurt performance, I start removing stuff. It is a good strategy that makes you sleep well at night.
If you aren't aware of data integrity constraints and the important role they play in database design then I recommend you take a course or study some books before you go about designing databases. It might be a good idea to hire some expertise to help with your current project.
you can work without Foreign Keys to model your database.. however, it is always advisable to Foreign Keys to maintain data consistency.. If you are not using Foreign Keys in your database, you will have to alter your queries manually and keep track of the foreign id's. however, if you do specify the foreign keys' it's become easier not only for you but for sql also to map your data..
Related
Please help.
I want to know how to query like Mysql relational tables (which mapped to another table by using foreign key constraint) select query or other queries in Apache Cassandra?
Is there is any way to achieve a foreign key constraint feature in Apache Cassandra?
No. There is no such thing in Cassandra. All joins & checks should be done on the application side. Usually, when people need information from multiple tables, then they are building an aggregating table so it could be queried as one object. And all data modeling in Cassandra is going from queries, not from the logical database schema.
I really recommend to take DS220: Data modeling in Cassandra course on the DataStax Academy (please take DS201 prior to it, to understand why Cassandra works this way).
I am working with a fairly old web app that uses MySQL as the database. 90% of the tables are MyISAM, they have no indexes on their foreign keys for the most part.
I was considering porting the whole thing over to InnoDB so I can apply foreign key constraints and the like. However as the application is old and a bit gangly it's been relying on code to enforce referential integrity and I fear that making this change in the database could result in multiple code failures. I don't have time to go through the whole code base and ensure that everything does what it is supposed to, I have no reason to suspect that it doesn't I'm just aware of the possibility of adding foreign key constraints causing unforeseen issues.
I was thinking another approach could be to simply add indexes on the foreign key fields without creating constraints. I'm thinking this would improve performance without the risk of damaging existing functionality. Could anyone tell me if there is a reason not to do this? Would I receive the same performance boost doing this as I would adding indexes AND foreign key constraints?
Yes, just adding the indices should give you almost the same performance boost. The foreign key constraints are more for referential integrity than performance.
There may be some cases where adding those constraints help the DB engine construct a more efficient execution plan; but that's a minor consideration, compared with the benefit of adding well-targeted indices to an index-less database.
This question is in the title !
The database i'm using to store datas from my (production) website contains a lot of ON DELETE CASCADE.
I just would know if it's a good thing or if it's a better way to manually code all deletions.
On one hand, it's not very explicit : deletions are made by magic and on a other hand, it make development easier : I don't have to keep the entire schema of my database in my mind.
I think maintaining referential integrity is a good thing to be doing. The last thing you'd want is orphaned rows in your database.
See the MySQL documentation on things to consider when not using referential integrity:
MySQL gives database developers the choice of which approach to use. If you don't need foreign keys and want to avoid the overhead associated with enforcing referential integrity, you can choose another storage engine instead, such as MyISAM. (For example, the MyISAM storage engine offers very fast performance for applications that perform only INSERT and SELECT operations. In this case, the table has no holes in the middle and the inserts can be performed concurrently with retrievals. See Section 8.10.3, “Concurrent Inserts”.)
If you choose not to take advantage of referential integrity checks, keep the following considerations in mind:
In the absence of server-side foreign key relationship checking, the application itself must handle relationship issues. For example, it must take care to insert rows into tables in the proper order, and to avoid creating orphaned child records. It must also be able to recover from errors that occur in the middle of multiple-record insert operations.
If ON DELETE is the only referential integrity capability an application needs, you can achieve a similar effect as of MySQL Server 4.0 by using multiple-table DELETE statements to delete rows from many tables with a single statement. See Section 13.2.2, “DELETE Syntax”.
A workaround for the lack of ON DELETE is to add the appropriate DELETE statements to your application when you delete records from a table that has a foreign key. In practice, this is often as quick as using foreign keys and is more portable.
Be aware that the use of foreign keys can sometimes lead to problems:
Foreign key support addresses many referential integrity issues, but it is still necessary to design key relationships carefully to avoid circular rules or incorrect combinations of cascading deletes.
It is not uncommon for a DBA to create a topology of relationships that makes it difficult to restore individual tables from a backup. (MySQL alleviates this difficulty by enabling you to temporarily disable foreign key checks when reloading a table that depends on other tables. See Section 14.3.5.4, “FOREIGN KEY Constraints”. As of MySQL 4.1.1, mysqldump generates dump files that take advantage of this capability automatically when they are reloaded.)
Source: http://dev.mysql.com/doc/refman/5.5/en/ansi-diff-foreign-keys.html
Cascading deletes are a great tool for you to use provided you make sure only to use them where it makes perfect sense to do so.
The main situation in which you would opt for using a cascading delete is when you have a table that models entities that are "owned" by one (and only one) row in another table. For example, if you have a table that models people and a table that models phone numbers. Here your phone numbers table would have a foreign key to your people table. Now if you decide you no longer want your application to keep track of someone - say "Douglas" - it makes perfect sense that you don't want to keep track of Douglas's phone numbers any more, either. There is no sense in having a phone number floating around in your database and not know whose it is.
But at the same time, when you want to delete a person from the "people" table, you don't want to first have to laboriously check whether you have any phone numbers for that person and delete them. Why do that when you can encode into the database structure the rule that when a person is deleted, their phone numbers can all go as well? That is what a cascading delete will do for you. Just make sure you know what cascading deletes you have, and that they all make sense.
NB. If you use triggers, you need to be more careful. MySQL doesn't fire triggers on cascading deletes.
Is there any point in defining FK constraints in MyISAM? MyISAM doesn't enforce referential integrity, right? So maybe there is no point to FK constraints.
Although MySQL parses and ignores them on MyISAM tables, I think you should write them for three reasons.
Preparation: Your code will be ready when MyISAM gets there.
Documentation: Everybody will know what you intended. Much better than trying to figure out where foreign keys are supposed to go a year from now.
Insurance: If MyISAM fails you, you can move directly to InnoDB tables.
http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-foreign-keys.html
At the end of second column:
At a later stage, foreign key constraints will be implemented for
MyISAM tables as well.
apparently in mysql 5.0 'latter stage' has not come yet
constraints are needed as an additional validation
I'm doing a venue/events database and I've created my tables and would like some confirmation from someone if I did everything right :)
I have 2 tables:
Venues
Events
The primary key of Venues is VENUE_ID, which is set to auto_increment. I have the same column in Events, which will contain the number of the Venue ID. This should connect them, right?
Also, the table engine is MyISAM.
It does not automatically link the tables to each others, and the referenced columns don't necessarily have to have the same name (in fact, there are situations where this is impossible: e.g. when a table has two columns that both reference the same column in another table).
Read up on foreign keys; they're standard SQL and do exactly what you want. Note, however, that the MyISAM storage engine cannot enforce foreign key constraints, so as long as any of the tables involved uses MyISAM, the foreign key declaration doesn't add much (it does, however, document the relationship, at least in your SQL scripts).
I suggest you use InnoDB (or, if that's feasible, switch to PostgreSQL - not only does it provide foreign key constraints, it also has full support for transactions, unlike MySQL, which will silently commit a pending transaction whenever you do something that's not supported in a transaction, with potentially devastating results). If you have to / want to use MySQL, I suggest you use InnoDB for everything, unless you know you need the extra performance you can get out of MyISAM and you can afford the caveats. Also keep in mind that migrating large tables from MyISAM to InnoDB later in production can be painful or even outright impossible.
Your db structure is right.
You can use Innodb for adding foreign key contraints. Also don't forget to add index to the second table for faster joining two tables.
More info about FK http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html
Note to comments:
Innodb allows you to make concurrent select/(insert/update) but MyIsam allows you to do the same things if you don't delete from MyIsam table. Otherwise MyIsam will lock your whole table.
Generally, yes. This is how you indicate a one-to-many relation between two tables. You may also specifically encode the relationship into the database by setting up a Foreign Key constraint. This will allow add'l logic such as cascading.