I have a DB table that is myISAM, used for fulltext searching. I also have a table that is InnoDB. I have a column in my myISAM table that I want to match with a column in my InnoDB table. Can that be done? I cant seem to work it out!
http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html
Foreign keys definitions are subject to the following conditions:
Both tables must be InnoDB tables and they must not be TEMPORARY tables.
So, I'm afraid you wont be able to achieve what you want done.
I would recommend altering your DB architecture such that you have one set of tables designed with data integrity for writing (all InnoDB), and a second set designed for search - possibly on a different box, and possibly not even using MySQL, but maybe a search server like Solr or Sphinx, which should outperform a fulltext MySQL table. You could then populate your search DB periodically from your write DB.
Related
I was trying to make a full-text search for a simple engine and i have realized i can not do it with InnoDB.
Now, i was wondering if I can convert only that table to MyISAM and still working with the others ones at the same time. This table has a foreign key with another table which is at the same time related with many others.
Thanks.
So, in the process of creating our tables, we weren't paying close enough attention to our system and all of the tables were created with the InnoDB engine. This is really only bad because we want to have a FULLTEXT index on a few of the columns.
So, now I want to convert. And while I'm at it, I just want to convert all the tables to MyISAM so that if we ever add columns in the future that we want to index, we have that option. So I've got my .sql file with the following:
ALTER TABLE tableName1 Engine = MyISAM;
ALTER TABLE tableName2 Engine = MyISAM;
However, when I try to run it, I get the following error:
Error Code: 1217 Cannot delete or update a parent row: a foreign key constraint fails
As you might have guessed, we have foreign keys in our tables. Not my style, but also not my department, nor my creation script.
My question boils down to, is there anyway for me to change the engine on these tables without having to wipe the DB?
Edit: Note that this will need to be done on multiple development and test copies of the database, so something I can script would definitely be preferred.
Well, to my knowledge, sort of but not really. mysqldump the database and edit out the foreign key constraints in the dumped sql file. And of course change the engine in the CREATE TABLE script.
InnoDB unlike MyISAM support foreign keys and has lots of great features like transactional system that ensures integrity across all tables. MyISAM tables tend to fail now and then when you have large data in tables or for many other reasons.
In the near future InnoDB will implement FullText search. I recommend not to change tables' engine but have something like Sphinx in place. Sphinx is much more powerful and much more flexible than Fulltext Search which works for InnoDB.
More about fulltext search in InnoDB:
InnoDB Fulltext search
I'm really lost on which type of database engine should I pick for my table.
+-----------------------+
| id | userid | content |
+-----------------------+
Imagine this table. userid is holding user ids which are stored in another table. Also, some other tables are using the id field of this table. Therefore, I thought that setting id as primary key and userid as a foreign key would speed up the join processes. However, if I select my table as InnoDB to set foreign keys, then I cannot conduct a FULLTEXT search on content (which is a TEXT field).
So basically, if I switch back to MyISAM to use the FULLTEXT searches, will I have problems when joining, say, 3-4 tables of hundreds of millions of rows?
PS: If there is another liable way to create tables to handle both joins and fulltexts, please tell me so, I can change the tables structure as well.
Take a look at the answer for this question: Fulltext Search with InnoDB
In short, MyISAM locks an entire table when you write to it, so that will be bad for performance when you have a lot of writes to the table. The solution is to go for the InnoDB tables for the referential integrity, and use a dedicated search engine for the indexing/searchfing of the content (for example Lucene).
InnoDB scales better than MyISAM. If you're talking about hundreds of millions of row then go for InnoDB and adapt a search engine. AFAIK, FULLTEXT becomes really slow after a certain point. Therefore, go for InnoDB + a search engine of your choice.
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.
Is it bad practice to create a mirrored table (MyISAM) of the records in an InnoDB table for the purposes of doing full-text searches? I figure this way I'm just searching a copy of the data and if anything happens to that data it's not as big of a deal because it can always be re-created. But, it just feels awkward.
(MyISAM is the only engine that supports full-text searching, but I need to use the foreign key constraints offered by InnoDB)
Should I avoid this?
first of all, have you considered using a good search indexer? for example lucene : http://lucene.apache.org/java/docs/ will speed up searches a lot as it builds its own index tables.
if you definitely want to use the inbuilt mysql full-text search, you could cut down the myisam table so that it just contains the text data you want to search and the primary key - and then retrieve the proper data from the normal innodb tables once you know the pkey. that would avoid duplication of the other data in the table.