I have a new client that is running a Symfony application with 170 or so MySQL tables. He recently updated his MySQL Workbench to the latest revision and is now getting a warning pop-up when he launched the application
FIX INDEX NAMES
Index names identical to FK names were found in the model, which is not allowed for MySQL5.5 and later. Would you like to rename the indexes?
I am not a DBA but I understand that the index and primary key names are clashing. What are the implications of renaming these indexes vs. just ignoring?
The Symfony app he is running uses the Doctrine ORM, would any queries or the model need to be updated should the indexes be renamed?
Using the InnoDB engine
Thanks
MySQL Workbench checks at opening a model if there are any duplicate index names and offers to rename them to be unique. Letting it doing this has not bad side effect. In fact it is even necessary to be able to apply the model to a server. Otherwise the server will refuse to create tables that contain an index with a name that was already taken.
So in short: it's a good idea to let Workbench fix this bug (since duplicate key names are nothing but a bug).
Related
I'd like a snapshot of a live MySQL DB to work with on my development machine. The problem is that the DB is too large, so my thought was to execute:
mysqldump [connection-info-here] --no-autocommit --where="1 limit 1000" mydb > /dump.sql
I think this will give me the first thousand rows of every table in database mydb. I anticipate that the resulting dataset will break a lot of foreign key constraints since some records will be missing. As a result the application I mean to run on the dev machine will fail.
Is there a way to mysqldump a sample of the database while ensuring that all records dumped abide by key constraints? (for instance if a foreign key is dumped, the matching record in the foreign table will also be dumped).
If that isn't possible, how do you guys deal with this problem?
No, there's no option for mysqldump to dump only rows that match in foreign key relationships. You already know about the --where option, and that won't do it.
I've had the same task as you, to dump a subset of data but only data that is related. For example, for creating a test instance.
I've been using MySQL for many years, I've worked as a MySQL consultant and trainer, and I try to keep up with current tools. I have never heard of any MySQL tool that does this operation.
The only solution I can suggest is to write your own script to dump table by table using SELECT...INTO OUTFILE.
It's sometimes easier to write a custom script just for your specific schema, than for someone to write a general-purpose tool that works for everyone's schema.
How I have dealt with this problem in the past is I don't copy data from the live database. I find some other way to create a subset of fake data for testing. It's probably better to create synthetic data anyway, because then you don't risk accidentally using live data in your dev/test environment, in case some of it is private data.
I am trying to setup foreign key for my mysql database using phpmyadmin.
But phpmyadmin only displays internal relation in 'relational view'. Note I have already made sure of following steps.
Setup phpmyadmin database (create_table.sql and config stuff)
Made sure all tables in my database using InnoDb
Made sure my intended foreign keys/reference Keyes are indexed.
After all these steps I can only see internal relations in my relational view.
Am I missing something?
This is not actually a solution, but since I cannot comment on posts yet, I'll add a few comments that might help.
I've faced this same issue and the critical parameters seem to be the following:
Case insensitive operating system (in my case windows)
Mixed-case table names (e.g. "TableName")
I've been using Mixed-case table names successfully in Linux, but in Windows something seems to go really wrong with phpMyAdmin.
I bet your table names are mixed-case. Try creating a test table yourself, with a fully lowercase name, and check if you see the "Foreign Key Relations" options of phpMyAdmin.
If you do, then we've found the source of the problem and we're just left with finding a solution or workaround for it :)
ps: More on case-sensitivity and mysql, without any hints about phpMyAdmins view on all of this, can be found here:
http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
This IS the solution. Renaming table name 'myTable' to 'my_table' solves the problem.
If you have different storage engines on the tables in your database, this would be the case. The only storage engine I know to support foreign keys is InnoDB. MyISAM and the rest don't seem to work.
Change your Storage Engine to: innoDB and then click save.
I'm using MySQL workbench 5.2.35 CE to reverse a Mysql Database and show the diagram of tables with their relationships.
I am able to get every table and its fields but the relations between them is not shown. Why is that? Is there any way it can be fixed?
Most often, the relations between tables are not stored in the DB. How to combine two tables is entirely up to the SQL query and because there are near endless possibilities to name your columns this is not easy to guess. Try to find some SELECT statements or use brute force to find out wich columns match.
If you are using MyISAM as the database engine, your database is not fully relational. Make your database fully relational by using InnoDB engine. Then you will be able to see the relations when you do reverse engineering. But please note that each has pros and cons of its own. Google MyISAM vs InnoDB to find out more about the differences.
I have tested mysql-workbench for both 5.2 and 6.0 latest version. My database got foreign key constraints defined clearly. My database is using mysql-native SQL. But the relationships are shown as line between tables. I have created another test database with only two tables. In this case the InoDb was used as engine. The foreign key constrain clearly defined. Still it only generate two lonely table object in the ER diagram after going through the "reverse engineering" module.
While using another commercial software, I was able to generate the 'lines' between the Entities.
My question is, is this a problem of workbench itself, or some error on my part. My database server is the latest stable version 5.6.12. If I can get an answer, this will be good for everyone. You don't have to waste time trying to get an ER-diagram with this piece of software.
I am having a particularly weird problem putting the data into my production server. My test server runs MySQL 5.1.41. I export the database (tried both via mysqldump and PHPMyAdmin) and then try to import into my production server that runs MySQL 5.0.92.
In one of the tables, I get an error "#1062 - Duplicate entry '1' for key 1". That table has a PRIMARY key and a UNIQUE composite key. When I look into output of phpmyadmin error, I do not see any duplicates.
I already tried:
- exporting with the option "add AUTO INCREMENT"
- checking whether the collations are the same. They are. Besides, the keys in question are numerics.
So if anybody knows what could be causing the error, and how to fix it - I would appreciate it.
Try to remove the index from the table in a dump and then, when all the data will be imported, add it manually.
If everything works fine in the source database, the only thing that I can think of is that the target database doesn't set the appropriate column to AUTO_INCREMENT.
Have you tried creating that table manually in the target database and setting the column in question to AUTO_INCREMENT before importing the source dump?
The the solution was to remove the AUTO_INCREMENT attribute from columns before importing. Still do not understand why, though. The indexes could actually stay. Then the AUTO_INCREMENT could be easily added back. A mixture of what Martin & Silver Light proposed, but I guess none of the answers were exactly right.
I've recently been working with a MySQL database, and using MySQL workbench to design the Database.
When I use the export to SQL function, so I can actually get the layout in to the Database, I get:
"Error 1005: Cannot create table"
This appears to be related to Foreign Keys in the create table statement.
Does anybody have a work around for this that doesn't involve taking the constraints out and putting them back in later? That's a less than ideal solution given the size of the database.
When you get this (and other errors out of the InnoDB engine) issue:
SHOW ENGINE INNODB STATUS;
It will give a more detailed reason why the operation couldn't be completed. Make sure to run that from something that'll allow you to scroll or copy the data, as the response is quite long.
I ran into this situation recently when I attempted (in InnoDB tables) to make a foreign key reference to a column that had a different data type.
MySQL 5.1 Documentation