In MySQL, I need to know which tables depend on other tables. Is it possible to get the relations?
In SQL Server it's possible to see dependent tables. I hope MySQL can do this too.
If it's in pictorical form then that's even better.
Perhaps you want the SHOW CREATE TABLE command?
If there are foreign keys defined, the above command will show you what they are.
Take a look at the information_schema, especially to key_column_usage table.
http://dev.mysql.com/doc/refman/5.0/en/key-column-usage-table.html
Have a look at Database Explorer (object dependency tree) - a unique feature in dbForge Studio for MySQL.
Easily explore object's references and dependants in Database Explorer. Compilation of dependants for debugging is now also available through the object's context menu.
Also, Database Designer can show foreign key relations between tables.
maybe you'd want a graphical front-end to mysql since you're so used to SQL Server. if the foreign keys are defined, it will show up as a link between entities when you reverse engineer the database.
Related
I haven't managed to find a specific answer to this question which works for me, but maybe i'm misunderstanding one or two key points.
I am trying to create a data migration policy for a project where 3 systems (2 X MySQL, 1 X MS SQL) are being consolidated into 1 new system (MS SQL).
To help visualize this problem i want to create Entity Relationship Diagrams for each database. I know how to reverse engineer each database to a sql script, and i know that programs like MySQL Workbench and SQL server management studio have tools which allow you to create diagrams.
My question is: Is there any way to create the diagrams automatically? I.e. somehow analyse foreign keys and detect which field(s) in table A link to table B and insert links in the diagram between the correct fields?
SQL Server Management Studio comes with a diagramming tool. In the Object Explorer, expand your database, then right click on Database Diagrams. You can view and create new FK relationships in there.
I have just realised that the databases i am testing with do not have foreign key constraints set up properly. So i guess the answer is yes, there are ways you can create these diagrams automatically but the foreign keys must be configured.
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.
Does a database relationship need to be established before you can impliment a INNERJOIN In a PHP Query?
Furthermore, when I export my Database via PMA; My already created relationships to not get exported. So I'm having to re-create my relationships apun every import.
Is it possible to export with the relationships?
No. The relationship is preferred when being optimized, but a relationship is not required to use a JOIN.
When exporting your database, make sure you use the Custom - display all possible options method. You may missing an option that is not including those constraints. Another possible reason is if you're not using InnoDb as the table engine, otherwise those constraints are discarded with MyISAM. See this question for more info.
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 support users who use MS Access as a front-end for viewing some Oracle tables at our intstitution. Their typical use is to write ad-hoc queries with the Access querybuilder, and also they LOVE Access because it lets them build printable reports without having to submit to the lengthy & expensive programming-request process through our tech support department.
When creating a link to an external table, they are sometimes asked to identify the primary key of the table. Of course, how can they possibly have any idea what the primary key field(s) would be?
My question is this: Why does Access want to know what the linked table's primary key field(s) is? Indexing should be happening in the source db, shouldn't it?
We had an issue recently when users started moving to Access 2007 that was finally "fixable" in two ways: 1) new ODBC connection, or 2) identifying a different primary key column for the linked table. My tech support tried to insist that I would have to modify my practice by telling my users to select the correct primary key field. I contended that it shouldn't matter. But I can't dismiss the thought that MS Access wouldn't be asking if it didn't matter for something. Just not sure what that might be.
Note: the "issue" is described in this post: Access 2007 to Oracle 10g linked table -- query with flawed results, but no errors thrown
If your users just need read-only access, for querying and reporting, have them click cancel in response to Access' question about which field(s) to use as primary key. They should still be able to create a link but it will be read-only.
If your users need to modify data in the linked Oracle tables, give them copies of an Access database file which you create for them. You set up the linked tables, and the connection properties are stored in the link's TableDef ... Access doesn't need to refer back to your DSN for that link afterward. So the users won't need the DSN, either.
How will the users know what the table means or how to join it to other tables unless they know what the keys are? Knowing what keys exist is pretty essential to get useful results out of a SQL database.
Not only uses the pk for update. Also when making an heterogeneous join, ie. between odbc table and local table or tables from different odbc sources, the access need to get all the data to local to do the join. Having the pk can loop doing multiples querys to the external source using the pk. This is really good for small local tables and long-long odbc tables.