I just have a small beginners question of MySQL containing relations and joins.
What is the difference between them? In my phpmyadmin in the designer section I can make relationships between tables. So that the tables are linked with each other through for example "id"
But if I in my php code do a join / left join...
for example:
$stmt = $db->prepare ("SELECT * FROM visitor
LEFT JOIN host ON visitor.host_id=host.id
LEFT JOIN reason ON visitor.reason_id=reason.id
WHERE visitor.id = ?");
$stmt->bindParam(1, $lastid);
$stmt->execute();
Isn't that just the same I have done? I am asking now why do you need to set the relations into phpmyadmin? What is the benefit of doing that?
I suspect what you're referring to are foreign keys. You're technically using foreign keys in your join (the reason_id field) already, but by formally defining them it creates an integrity constraint. The advantage of this is that it'd be impossible to accidentally insert a visitor which has an invalid reason_id, it's also possible to specify the delete behaviour to ensure that all related records are cleaned up appropriately. Note that not all storage engines support foreign keys.
See here: https://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
Related
I do something like this:
SET foreign_key_checks = 0;
//many different operations on several tables
SET foreign_key_checks = 1;
How can I verify that my entire base is consistent? I want to be sure that all relationships are properly maintained. For example, if I delete a "country" with id: 20, I want to make sure that no "city" has a non-existent relationship "country_id" = 20.
It's easier if you do not SET foreign_key_checks = 0. If you keep the constraint enforcement on, then you can't make inconsistencies or broken references. You get an error if you try. So you should consider not turning off the FK checks if referential integrity is important.
If you do think you have inconsistencies, you must do a query like the following to verify there are no "orphans" that reference a parent that no longer exists:
SELECT cities.city_id
FROM cities
LEFT OUTER JOIN countries
ON cities.country_id = countries.country_id
WHERE countries.country_id IS NULL;
If the JOIN condition was based on equality of country_id, this means country_id must not be NULL. The left outer join returns NULL for all columns when there is no match. So if you search in the WHERE clause for cases where country_id IS NULL this will only return cities that have no match in the other table.
You must do a separate query for each relationship in your database. This can be quite a chore, and if the tables are very large, it can take a long time.
I once had to do this many years ago in a buggy application that had no foreign key constraints (it used MyISAM tables). I ran a script to do all these orphan-checks every night, and eventually it grew to dozens of queries, and took hours to run.
Then comes the part that is even harder: once you do find some orphaned records, what do you do about them? Do you delete the orphans? Do you change their foreign key column to reference a parent record that does still exist? Do you restore the parent record? It could be any of these options, and you must have the orphaned records reviewed case by case, by someone with the knowledge and authority to choose how to resolve the issue.
It's far better to keep the constraints enforced so you don't have to do that work.
Hi, Can the Accounts table get its values from the SA & CA tables the fields SA and CA being the FK's constraints in the Accounts table?
The logic requires that I go like this and not the other way round. i.e. not build Accounts first as a supertable and then create the other two from there.
Thank you.
There is no concept of inheritance and supertable as you suggest. It is not an OOP. So, create your tables with Foreign Key constraints and insert your data manually.
A Foreign Key value can be NULL. Though typically not a great idea. You might want to collapse your table from 3 down to 2 or 1 with a type column.
You may want to not have an Accounts table. What is even the purpose of it other than replication of information. Granted, it can handle more granularity, but don't over-populate your design with unnecessary tables.
If you are insistent on having separate Savings and Checking tables, and an Accounts table, the only way to pull off the Accounts table with FK's is with the use of NULLS. And, as mentioned, that is not recommended. The reason why? It is like saying It must be one of these ... except in the case that I don't care. And we should care about our data.
Resist the urge to have FK's NULL. One way to accomplish that is to have an accounts table, and join on other tables knowing only some will succeed. A Conditional Join. Achieved via LEFT JOIN.
We have a database with a couple hundred tables. Tables using foreign_keys use INNODB.
Sometimes we transfer data (individual tables using mysqldump) between our development, stage, and production databases. mysqldump disables all foreign key checking to make importing the data easy.
So over time some of our non-production databases ends up with a few orphaned records.
I was about to write a script that would find and detect any invalid (keys pointing to missing records) foreign keys for an entire MySQL database.
I know I can write a query to check each table and fkey one by one, but was thinking there may be a tool to do this already.
I would check before writing such a script to see if there is one out there already.
Searched google a bit... surprisingly I found nothing.
If the data is already in and you haven't set up fk constraints or cascades for deleting the parent then you just want:
SELECT * FROM children WHERE my_fk_id NOT IN (select id from parents);
these other answers are fine for small tables but i think they run in O(n^2) which probably isn't ideal for a large db. Instead i used a left join:
SELECT * FROM children c LEFT JOIN parents p ON p.id=c.parent_id WHERE p.id IS NULL AND c.parent_id IS NOT NULL;
Note you may not need that very last not null condition, i did because i wanted to exclude children that didn't have parents (a valid case in my particular scenario)
I have a table named USERS with user_id as primary key and user_name.
I have another table USERS_ACT with user_act_id primary key, user_act_user_id and another 2 columns.
I need user_act_user_id to be foreign key in USERS? How can I achieve this?
This is my first day in SQL so please be kind to explain if what I ask is wrong.
let's assume you are not the DB admin and you just want to get all the active users' names ;))
select users.user_name
from users
join users_act on users.user_id = users_act.user_act_user_id
Without referencial integrity it's up to you to make it work, there's no "magic" around it.
Populate your user_act_user_id with a pk-value from USERS and there you have it.
You may want to add constraints, but that may not be what you're asking for,
http://msdn.microsoft.com/en-us/library/ms175464.aspx
In short, they keep the keys between tables in good shape.
Assuming you are using InnoDB (which is the only engine that supports foreign keys):
ALTER TABLE users_act
ADD CONSTRAINT fk_users_act_users
FOREIGN KEY (user_act_user_id)
REFERENCES users (user_id);
It depends on your DB Type if MySql even supports foreign keys. For example you can use foreign keys with InnoDB format but not with MyIsam format.
When working with MySql i personally prefer working with MyIsam and do most of the checking about integrity while programming.
In general you can just add user_act_user_id in your table USERS but not mark it as any key. After that you can simple use a JOIN, but ofc the referencial integrity is not given so have to write your own "trigger" on programming site if you want f.e. to automaticly delete data belonging to a user in the other table. Otherwise you have to use constraints or triggers, but this might be not that easy when just started with SQL.
I am an MySQL novice and am looking for the solution to the following problem:
I would like to create a CMS with cppcms which shall be capable to have modules. Since I want to reduce the chance of (accidental) access to private data, I want a module which handles data access and rights. Since this module is supposed to be unaware of data structures created by other modules I would like it to deduce the data owner through foreign key relations. My idea would be to search for a path (over foreign keys) which links a row to a user id.
Sum up:
What I am trying to do
Taking a random query, determine the affected rows
for the affected rows determine a relationship/path (via foreign keys) to a user/userid (a column in an existing table)
return only the rows for which a relationship could be determined and a condition holds (e.g. the userid found in the related query matches a fixed user id, such as the user currently accessing the system)
(As far as I know foreign keys only enforce the existence of a key in another table, however the precondition I assume is, that every row is linked to a user over a path of foreign key relations)
My Problem/Question:
Is there an existing solution/Better approach to the problem? Prepared statements wont do the trick since I don't know all datastructures/queries in advance.
How do I get the foreign key relations? Is there another way besides "SHOW CREATE TABLE" and then parsing the result string?
How can I determine the rows that would be affected, without modifing them? I would like to filter this set afterwards by determining if I can link it to the current user (not the mysql user but system user).
Could I try executing the query, and then select the affect rows, and if I determine an access violation simply do a rollback? Problem with this: how to do the changes to the subset of rows for which it is legal (e.g. I attempt to change 5 rows, may only change 2, how to only change those 2). One idea was to search a way to create a temporary table with the result set; this solution has several drawbacks: foreign key relations are not possilbe for temporary tables, they are 'lost'.
P.S.: I am coding in c++, therfore I would prefer cpp-compatible library recommendations, however I am open to other suggestions. While googling I stumbled over doctrine and Iam currently researching it.
P.P.S.: Database engine is InnoDB (has to because of the foreign keys)
UPDATE: Explanation Attempt of Part 2:
I am trying to filter which collumns a user is allowed to see of tables. To do so I would like to find a connection in the database over foreign keys (By foreign keys I ensure that I can get to all data over joins, and they are a hint on which columns I have to join). Since I plan on a complexer system (e.g. forum) I don't want to join all data in a temporary table and run a user query on those. I would rather evaluate the userquery and check for the result if I can map it with a join to the users id. For example I could use this to enforce that an edit button is only enabled for the posts created by the user. (I know there are easier ways to do this, but I basically want to allow programmers to write their own queries without giving them the chance to edit or view data that they are not allowed to see. My assumption is that the programmer is not an evildoer but simply forgetting constraints, thus I want to enforce them in software).
Getting here would be pretty good, but I have a little more complex need.
First a basic example. Let's say its like facebook and all the friends of a person are allowed to see his pictures.
pictures = id **userid** file (bool)visibleForFriends album
friendship = **userid1** **userid2**
users = userid
What I want to happen is:
Programmer input "SELECT * FROM pictures WHERE album=2"
System gets all matching records (e.g. set of ids)
System sees foreign key userid, tries to match current userid against the pictures userid, adds all matching to the returned result part
System notices special column visibleForFriends
System tries to determin all Friends (SELECT userid1 FROM friendship WHERE userid2=currentUserID join (have to read up on joins) SELECT userid2 FROM friendship WHERE userid1 =currentUserID)
System adds all rows where visibleForFriends is true and pictures.userid=Result from 5.
While the Friendship part is some extra code (I think doable if igot started on the first bit), I still need to figure out how to automatically follow the foreign keys to see the connection. Ignoring the special Friendship case (special case), I would like the system to work on this as well:
pictures = id **albumid** file (bool)visibleForFriends album
albums = id **userid**
users = userid
Now the system should go pictures.albumid ==> albums.id -> albums.userid ==> users.userid.
I hope the examples clarified the question a bit. One problem is, that in point one from the example (programmer query input) I dont want to let "DELETE *" take effect on anything not owned by the user. So I have to filter which rows to actually delete.
In response to part of your answer (part 1), providing the Mysql user you access the database with has access rights to information_schema then you can use the following query to understand existing foreign key relations within a specific database:
SELECT
TABLE_NAME,
COLUMN_NAME,
REFERENCED_TABLE_NAME,
REFERENCED_COLUMN_NAME
FROM
information_schema.KEY_COLUMN_USAGE
WHERE
TABLE_SCHEMA = 'dbname' AND REFERENCED_COLUMN_NAME IS NOT NULL;
I am slightly confused by the part 2 and am unsure how to give an appropriate response to this section. I hope you find the above query helpful though in your project!
Is there an existing solution/Better approach to the problem?
Yes, I think so. You're describing a multi-tenant database. In a multi-tenant database in which the users share tables (also known as "shared everything"), each table should have a column for the user id. In effect, each row knows its owner.
This will vastly simplify your SQL, since you need no joins to determine who a row belongs to. it will probably speed up your SQL a lot, too.
This SO answer has a decent summary of the issues and alternatives.