I understand some basics about relational database. But I don't get the point of making relation through phpmyadmin designer. What is the benefit there when I have to query any related table with another table's content ID?
When I make any query to select post where user_id=1, is there any way to make it like that, I will select from user_list where id=1, and I don't have to make another query to table posts?
To answer the first question: It documents the relationships for reference, and most designer applications will generate constraints enforcing those relationships.
To your answer your second question, no. If you only want information from posts, there would be no reason to involve users_list unless it relied on information from there, such as wanting to know "posts made by any users with the first name 'bob'"; in which case you would use a join. But if you already know the id for the user, there is no reason to involve users_list.
Related
Right now I'm trying to query a table that holds the id of two tables that holds the id to two other tables (where one of these holds the id to other tables)
Hell, I know.
As I am a beginner in SQL, how do I go about efficiently querying this to get all the details of each table? As of now i only see a very long set of Select statements. Here is how the tables are set up below
I am not sure what you are asking.
If you need a SELECT command it would have 2 INNER joins. But, if you are asking to get all the info (and children) then it would need more INNER joins. OR if you are using a persistent client for your application.... I just don't know. Because it is incomplete data to do it.
This may be a simple and silly question for some, but i'm trying to figure what would be the best way to tackle the next problem. I have the following database in MySQL:
As you can see, there is a "general table" called resources, and a table that contains each type of resource (blog entries, images, videos, etc ... ), i would like to know if its worth it to create a view for each type of resource (blog view, video view ...) that i can then query to get the information an populate each webpage, or if its better to just query the table directly, as well as the "associated" tables (say, query resources table, and select the type of resource where the id = id of the resource table, and then query tag table to get the tags where the id = id of resource, and so on).
Also, i would like to know what the best way to update this tables would be, is there some sort of "cascade update" so i can update/input information into the tables at the same time, or should i do it by using several queries, say, "insrte X into resources, get the of that insert, then insert the tags on tag table, get the ids, then fill resurces tag table, and so on).
Some additional information, i'm using PHP, would it be better to create objects for each on of this "views"/"queries" that would represent each type of resource ?.
Views:
Practically speaking, you should be totally fine without implementing views. You can use joins in order to select associated relationships.
Updating:
You will have to use multiple inserts in order to update tables. If you're worried about information integrity, you can do this via a transaction which would guarantee all inserts succeeding, or getting rolled back.
On a side note:
Given the current schema, you can put the create_time/update_time columns on the resources table to simplify things.
Good luck.
I have 2 tables users and comments.
In term of performance, should i use a join (with user id) to get the username from users table or should i add a column username to the comments, so i won't need join for only 1 data (username) but i will need to add one more data for each comment (username).
Is join slow if there's a lot of comments in the table ?
Wich one should i do ? Join or add column username to comments.
Thank you.
Join is probably the best so you're not storing data in two places. What if a user name is changed? It won't change the user name for the comments. Also, joining two tables is not very time consuming.
It depends on the number of users and comments. Having a denormalized db, which is what you ask, can be faster but then you need to take care yourself to update username in both tables. Don't forget to add index for userid in comments table if you go the join way.
So the correct answer I believe is go with the join, and denormalize later if needed.
If you're using InnoDB, you can add the column and add foreign key restrictions. This will allow you to increase efficiency and worry less about updating indexes.
The one reason why you would store the user name in the comments table is if you wanted to know the user name when the comment was created. If the user name is subsequently changed, you'll still have the name at the time of the comment.
In general, though, you want to use join. You want to have the primary key on a table defined, probably as an auto-incremented (identity) integer value.
If you are concerned about performance for getting all comments for a single user, then you should build an index on the comments table on the user id field.
Personally I would rather user two simple separate queries. I do not like joins all that much. Joins just produce duplicated data by definition. You might want to check http://www.notorm.com/ that is a simple php db access layer going joinless way.
I am trying to create a site where users can register and create a profile, therefore I am using two MySQL tables within a database e.g. users and user_profile.
The users table has an auto increment primary key called user_id.
The user_profile table has the same primary key called user_id however it is not auto increment.
*see note for why I have multiple tables.
When a user signs up, data from the registration form is inserted into users, then the last_insert_id() is input into the user_id field of the user_profile table. I use transactions to ensure this always happens.
My question is, is this bad practice?
Should I have a unique auto increment primary key for the user_profile table, even though one user can only ever have one profile?
Maybe there are other downsides to creating a database like this?
I'd appreciate if anyone can explain why this is a problem or if it's fine, I'd like to make sure my database is as efficient as possible.
Note: I am using seperate tables for user and user_profile because user_profile contains fields that are potentially null and also will be requested much more than the user table, due to the data being displayed on a public profile.
Maybe this is also bad practice and they should be lumped in one table?
I find this a good approach, I'd give bonus point if you use a foreign key relation and preferably cascade when deleting the user from the user table.
As too separated the core user data in one table, and the option profile data in another - good job. Nothing more annoying then a 50 field dragonish entry with 90% empty values.
It is generally frowned upon, but as long as you can provide the reasoning for the 1 to 1 relationship I'm sure it is fine.
I have used them when I have hundreds of columns (and it would be more logical to split them out into separate tables)
or I need a thinner table to speed up fullscans
In your case I would use a single table and create a couple of views.
see: http://dev.mysql.com/doc/refman/5.0/en/create-view.html
In general a single table approach is more logical, quicker, simpiler, and uses less space.
I don't think it's a bad practice. Sometimes it's quite useful, especially if you want one class to deal with authentication, and not load all profile data. You can then modify how your authentication works, build web services and so on, with little care about maintaining data structures about profiles information which is likely to change as your project evolves.
This is very good practice.
It's right at the core of writing good, modular, normalised relational database structures.
I'm working on a basic php/mysql CMS and have a few questions regarding performance.
When viewing a blog page (or other sortable data) from the front-end, I want to allow a simple 'sort' variable to be added to the querystring, allowing posts to be sorted by any column. Obviously I can't accept anything from the querystring, and need to make sure the column exists on the table.
At the moment I'm using
SHOW TABLES;
to get a list of all of the tables in the database, then looping the array of table names and performing
SHOW COLUMNS;
on each.
My worry is that my CMS might take a performance hit here. I thought about using a static array of the table names but need to keep this flexible as I'm implementing a plugin system.
Does anybody have any suggestions on how I can keep this more concise?
Thankyou
If you using mysql 5+ then you'll find database information_schema usefull for your task. In this database you can access information of tables, columns, references by simple SQL queries. For example you can find if there is specific column at the table:
SELECT count(*) from COLUMNS
WHERE
TABLE_SCHEMA='your_database_name' AND
TABLE_NAME='your_table' AND
COLUMN_NAME='your_column';
Here is list of tables with specific column exists:
SELECT TABLE_SCHEMA, TABLE_NAME from COLUMNS WHERE COLUMN_NAME='your_column';
Since you're currently hitting the db twice before you do your actual query, you might want to consider just wrapping the actual query in a try{} block. Then if the query works you've only done one operation instead of 3. And if the query fails, you've still only wasted one query instead of potentially two.
The important caveat (as usual!) is that any user input be cleaned before doing this.
You could query the table up front and store the columns in a cache layer (i.e. memcache or APC). You could then set the expire time on the file to infinite and only delete and re-create the cache file when a plugin has been newly added, updated, etc.
I guess the best bet is to put all that stuff ur getting from Show tables etc in a file already and just include it, instead of running that every time. Or implement some sort of caching if the project is still in development and u think the fields will change.