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
Related
I am creating a MySQL DB with MyISAM engine. I believe it is not possible to use foreign key with MyISAM. All the tables in DB have primary key, but all of them also need at least 1 FK.
1)Can any of the other options available (apart from PK): such as: UNIQUE, INDEX FULLTEXT or SPATIAL be used instead of FK that serves the same purpose?
2)If the answer to 1) is <0, what else can be done (except changing to InnoDB)?
It smells like you don't understand the purpose of a FOREIGN KEY. It is for one thing:
Referential integrity. But this is not a requirement, it is a feature that you can live without if you write good code.
A FK has a side effect: It builds an INDEX. But the only purpose of an index is:
Faster lookups. This includes WHERE clauses and JOINs between tables.
It is a somewhat common misconception that you need a FK to JOIN two tables. That is totally false. Nor is an INDEX required.
Bottom line...
Get the schema written and your queries written.
When you hit performance problems (which might happen when you have a few thousand rows in a table), look into adding INDEX(es).
Regardless, move to InnoDB.
The answer to your question is no, there is no real alternative in MyISAM.
Depending on your version of MySQL. You could look at before triggers but you would have to write a trigger in place of each foreign key that you would normally create under Innodb. This isn't recommended though, you're reinventing the wheel by doing this and could encounter problems if the logic in the trigger is incorrect. Defeating the purpose.
Unless there's a feature of MyISAM that you can't get with Innodb, I would highly recommend using Innodb and optimizing where necessary.
Hope that helps.
No, MyISAM does not support FK constraints. You can't enforce referential integrity in MyISAM. You could code it yourself using triggers, but this is not recommended.
You can create an index, either unique or non-unique, to provide query optimization for searching or sorting. But this does not provide referential integrity.
ALTER TABLE MyTable ADD INDEX (column1, column2);
or
ALTER TABLE MyTable ADD UNIQUE INDEX (column1, column2);
Don't use a UNIQUE index unless you want the columns to have a unique constraint in addition to the index.
Don't use FULLTEXT or SPATIAL index unless you mean to do fulltext or spatial queries. Those indexes are for those special purposes, and in general they are not interchangeable with ordinary indexes.
And for the record, you should be using InnoDB.
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.
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.
In phpMyAdmin v2.8.2.4 for MyISAM tables, the "Relation View" appears under the Structure tab. It shows a list of Internal Relations. But what do these do, given that MyISAM does not support foreign key constraints or relational integrity?
By phpMyAdmin version 3.2.0.1 this page ("Relation View") no longer appears for MyISAM tables. So does this mean that it wasn't doing anything in the first place?
Any explanations much appreciated.
Justin
Foreign keys in MyISAM are for advisory purposes only. You can look at them to see where the referential integrity would be, if there were any. It's easier to understand the schema that way than to guess relations by looking at the indexes created as a side-effect.
I don't know why it'd disappear in phpMyAdmin, unless it's a config issue (I believe the view can be disabled)?
It's not explicitly mentioned in the documentation (http://dev.mysql.com/doc/refman/6.0/en/drop-table.html). I ask because I just saw a curious database migration in a Rails project where the developer was removing all the indexes before dropping the table, and that seemed unnecessary.
Yes, it does.
However, if you have foreign key constraints such as RESTRICT that ensure referential integrity with other tables, you'll want to drop those keys prior to dropping or truncating a table.
Yes it would drop the index. There's no reason to keep the index if the underlying table isn't there. I suspect that the downward migration is just doing the opposite of the upward migration on a one-to-one basis.
It is unneccessary. Your DROP TABLE might however be prevented when the table is part of foreign key relationships and dropping your table would break the dependencies.