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)?
Related
i'm Developing a large Website, and adding many functionalities on it. I want to know if there's any problem with making all the tables in the database InnoDB type, cuz there are so many foreign key connection within all the tables
I have like 20 tables in the database, and all the tables in the database are all connected together somehow, is there any problem with this, or it's okay, thanks.
InnoDB is preferred over MyISAM and if you have foreign key constraints then you should use InnoDB anyway since MyISAM doesn't support foreign keys.
Also, if you want to use InnoDB, its usually recommended that all tables use InnoDB. It provides a number of advantages anyway so I'd say yes, make all tables InnoDB unless you have a good reason not to (i.e. you need MyISAM Geospatial extensions or Fulltext and your InnoDB version doesn't support those features).
Nothing wrong with it at all, you should use whatever functionality is available to you such as the INNODB engine.
Problems, no. But what dbm are you using?
(InnoDB is the default storage engine for MySQL)
So there should be no problems, assuming you are using MySQL or any others that support InnoDB. but what are you doing with the tables and what would cause a problems, or that you think would cause problems ...
As far as I am aware the only non-trivial reason to choose MyISAM over InnoDB is for Full-Text indexing. Apart from that, InnoDB's support for transactions and foreign key constraints make it a much better choice for the vast majority of applications.
That said, there's nothing stopping you from using a few MyISAM tables alongside InnoDB tables if you require some functionality from MyISAM.
If MyISAM doesn't have FK integrity, how does a django app that uses MyISAM tables enforce the integrity of the FK constaints?
Poorly. It does its level best to issue updates and deletes when the referant changes, based on information it has already loaded from prior interactions, but there's just nothing protecting your data from becoming inconsistent.
The ForeignKey construct exists less to declare the integrity constraints as it does to tell django how the different tables link together, so you can traverse in python through the attributes to other model instances of other types. The orm-driven cascading is at best a band-aid over the shortcomings of databases like MyISAM. If this is important to you (and it should be), you should migrate away from the MyISAM engine to InnoDB or PostgreSQL.
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.
I read the following article yesterday (http://blogs.sitepoint.com/2010/11/19/mysql-mistakes-php-developers/) and it wrote the following:
MySQL has a number of database engines but you’re most likely to encounter MyISAM and InnoDB.
MyISAM is used by default. However, unless you’re creating a very simple or experimental database, it’s almost certainly the wrong choice! MyISAM doesn’t support foreign key constraints or transactions which are essential for data integrity. In addition, the whole table is locked whenever a record is inserted or updated: it causes a detrimental effect on performance as usage grows.
The solution is simple: use InnoDB.
I've always used MyISAM because it was the default. What do you think?
If I were to upgrade to InnoDB, in phpMyAdmin, can I just edit each table and change it to innoDB or is there a more complex process to perform?
Thanks!
Yes, you can swap in and out engines like used underwear, if you like, without much trouble. Just change it in phpmyadmin.
But I wouldn't change it for the sake of changing it. Do you need to use foreign keys? Change it. Do you need row-level-locking instead of table-locking? Change it.
It's worth noting that there are good reasons to use MyISAM, too. Take a look at FULLTEXT indexing. You can't do that with InnoDB.
UPDATE
As of MySQL 5.6 FULLTEXT has been implemented for InnoDB tables as well. Here is the manual.
Sorry for bumping an old question, but this also helped me a lot to choose which engine, especially since MyISAM is faster for reads and my database tables had more read the write:
http://www.rackspace.com/knowledge_center/article/mysql-engines-myisam-vs-innodb