I have a MySQL table that looks like this:
Table: Designer
id: integer
name: String
gallery: string
The gallery row can contain a string value like 23,36,45
Now I want to do a query similar to this:
SELECT * FROM Designer WHERE gallery = '36'
I know I kan use LIKE, but that is not precices enough. That could return both 36 and 136.
I also know I could create another table which links designer and gallery. But since this is not going to be a huge table, I'm adding the foreign gallery ID Key to the gallery row. And I'm lazy right now ;)
So how can I select a row that has the number 36?
UPDATE
Ok, since I'm getting nailed for poor design (yes I know it was), I See the obvious now.
A designer can have many galleries, but a gallery can only belong to one designer.
Therefore I only need to add designer ID as a foreign key to the gallery table.
Simple. But not always logical when it's 3AM and you've been workign for 15 hours ;)
If you have to do that you have poorly designed your tables.
One designer can have got many galleries and a gallery belong to one designer means you must create a foreign key 'designer' in your 'gallery' table, and your request will be
SELECT *
FROM Designer
INNER JOIN Gallery
ON Gallery.id = 36
AND Designer.id = Gallery.designer
I also agree that this is poorly designed table structure but here is the answer
SELECT * FROM Designer where FIND_IN_SET(36,gallery)
You really shouldn't store your data like that since it makes queries horribly inefficient. For that particular use case, you can (if you don't care about performance) use:
select * from designer
where gallery like '36,%'
or gallery like '%,36'
or gallery like '%,36,%'
or gallery = '36'
This will alleviate your concerns about partial matches since something like 136 will not match any of those conditions but 36 in any position will match.
However, despite your protestations to the contrary, what you should do is re-engineer your schema, something like:
designer:
id integer primary key
name varchar(whatever)
designer_galeries:
designer_id integer foreign key references designer(id)
gallery string
primary key (designer_id,gallery)
Then your queries will be blindingly fast. One of the first things you should loearn is to always design your schema for third normal form. You can revert to other forms for performance once you understand the trade-offs (and know how to mitigate problems) but it's rarely necessary unless you database is horribly convoluted.
You can use regular expressions in your WHERE clause instead.
http://dev.mysql.com/doc/refman/5.1/en/regexp.html
SELECT * FROM Designer WHERE gallery REGEXP "(,|^)(36)(,|$)"
Related
I want to make a ajax post filter. Filtering on wordpress post meta (custom-fields).
My posts have post-meta like actors, genre, duration, ect..
If I make a script using the meta-data from wordpress I expect performance issues. Therefore I want to build a custom database-table containing the post-id, and then a copy of the post-meta.
My structure would be something like this:
post-id
actors
genre
duration
Is this the most efficient way, or should I make separated tables for every post-meta?
Like this:
table 1:
post-id
actors
table 2:
post-id
genre
table 3
post-id
duration
It needs to be optimized for both a large database, and high volume traffic.
I am a bit new to database structure design, I was reading about indexes too, is there a task for them?
Should the values of actors be: Brad Pitt or a integer: 232 related to his name?
Also I am open to better ideas, than the ones above.
Wordpress looks terribly designed, but it does the job and do it well. Strangely it's much more efficient that what we can think by studying at its design.
If you want to use another table you will have to sync its content with the wp database on post updates. May not be easy.
I would take this problem in either one of this directions :
1 do it wp style and optimise
Do your database with custom post type. Create a page called ajax-actors in admin, create a page-ajax-actor.php file that handle the query and send raw results (no header, no footer).
Call www.yoursite.com/ajax-actor with ajax.
This will be "slow", so you have to optimize it.
Make sure you have apc running with enougth ram allocated to it.
Use wordpress supercache or similar plugin / Use a reverse proxy
2 do it using lightweight database
Use wordpress for your editorial content and create a second lightweight database from scratch. This way you can optimize your database for its specific content.
If you are starting a new website, do it using the 1st solution. It will be faster and you'll get your site online sooner. Then you can use the revenue to optimize it or even do a complete reshape.
Should the values of actors be: Brad Pitt or a integer: 232 related to his name?
You should use one table per entity type. Primary key must be an integer. Then you reference this primary key from other tables.
Example :
Table actors
id : integer / primary key
name : varchar / with index
The index on name slows insert but will speedup dramaticaly the search using actor names.
In the movies table you reference the actors by id. Actually, since they are several actors per movie, you'll need a table like this :
Actors_Movie
actor_id : integer
movie_id : integer
role : varchar (what's the name of the character of this actor in this movie)
hope this helps.
The website I'm building has a table which stores all the information of uploaded images on the site. These uploaded images can come from different resources such as a guestbook, news section or an item from an agenda.
Ofcourse I want the image to inherit the rights of the resource it is part of. For example: if user A isn't allowed to view the guestbook I don't want him to be able to view an image posted on the guestbook by going to image/view/id/12 (which would be the image request used it in the guestbook).
What I have now is that the system remembers the resources used (in this case the guestbook) the image-id is coupled to the resource-id. However I don't know to which guestbook post the image is connected (I do ofcourse know it the other way around).
Is there a way in SQL to connect one table field to a field in another table, where which table I connect to can vary based on one of the first table's field values?
In my case I would like to connect an image to a resource this could be a guestbook post in the table gb_posts or an agenda item in the table agenda_items.
Or is this all a stupid way of solving the problem and should I not use one table for the uploaded images but keep the image attached to the resource (as a column in the table for example)? It sounds like using one table is at least a lot slower in use (but I would have a great overview of all the images in one place).
I hope you guys can help me out.
EDIT: extra explanation: db model
I will try to explain how it all works the best I can.
First of all: I use Zend Framework, and therefor I also use Zend_Acl for working with priveleges.
My DB structure:
- Users are connected to roles (directly or by being connected to a group that is connected to a role)
- There is a table resources containing all the resources which is connected to priveleges. For example: guestbook is a resource, view or edit are the priveleges. Next to the controllers/actions there can also be other resources in this table such as a category within the agenda or a file location.
- roles are connected to a privelege
When for example the guestbook is requested for viewing I can check if the user is allowed to.
In short something like:
users -> roles -> priveleges <- resources
When a user adds a guestbook post with an image, the used resources (in this case guestbook is saved):
guestbook_posts -> images -> resources
I hope this explains my DB model for a bit, if it doesn't I will try to create an image of the tables.
I have to admit I'm failing to completely understand the model you wish to implement, but there is an interesting quote...
However I don't know to which
guestbook post the image is connected
(I do ofcourse know it the other way
around).
If you know an association one way, you should be able to use the associaton in both directions? I'm assuming you have a table that includes "post_id, image_id", or something?
It may be that the table is only indexed post_id first, in which case querying that table by image_id may be slow, but then you can just include a new index with image_id first?
If you can give examples of the table structure you have at present, and an example of the query you can't fullfil, we may be able to help you further.
Sounds like you want a foreign key constraint.
Update: Completely misunderstood the question, apparently.
There are two approaches here:
As it currently stands, there is nothing in the schema that would prohibit linking the same image from multiple resources. If that is desired, then a foreign key constraint and an index for the backreference is probably the best solution, although it will not scale well, and requires additional computation (because the rights on the image need to be the union of the rights of the refering resources).
The alternative is to create some kind of inheritance schema, where there is a table listing "resources" (that effectively just contains identifiers) that is referenced as a foreign key from the actual resource tables and the images table; the only constraint that cannot be expressed in plain SQL is that different resources may not share the same identifier.
Create two SELECT clauses, each having the correct joins to the correct tables, and then combine the output of the two SELECT clauses together using a UNION statement.
SELECT field1, field2
FROM table1
JOIN table2 on table1.PK = table2.FK
WHERE table1.selector = 1
UNION SELECT field1, field2
FROM table1
JOIN table3 on table1.PK = table3.FK
WHERE table1.selector = 2
Apologize for the long topic, I didn't intend for it to be this long, but it's a pretty simple issue I've been having. :)
Let's say you have a simple table called tags that has columns tag_id and tag. The tag_id is simply an auto increment column and the tag is the title of the tag. If I need to add a description field, that would be around 1-2 paragraphs on average (max around 3-4 paragraphs probably), should I simply add a description field to the table or should I create a new table called tag_descriptions and store the descriptions with the tag_id?
I remember reading that it is better to do this because if you do a query that doesn't select the description, that description field will still slow down mysql. Is this true? I don't even remember where I read that from, but I've been kind of following it for a couple years now... Finally I question if I need to do this, I have a feeling I don't. You'd also need to inner join whenever you need the description field.
Another question I have is, is it generally bad to create new tables that will only hold very few rows at the max? What if this data doesn't fit anywhere else?
I have a simple case below which relates to these two questions.
I have three tables content, tags, and content_tags that make up a many to many relationship:
content
content_id
region (enum column with
about 6-7 different values and most
likely won't grow later on)
tags
tag_id
tag
content_tags
content_id
tag_id
I want to store a description around 1-2 paragraphs for each tag, but also for each region. I'm wondering what would be the best way to do this?
Option A:
Just add a description column to the
tags table
Create a new table for
region_descriptions
Option B:
Create a new table called
descriptions with fields: id,
description, and type
The id would be id of the content or
id of the enum field
The type would be whether it is a tag
description, or region description
(Would use the enum column for this)
Maybe have a primary key on the id and type?
Option C:
Create a new table for tag_descriptions
Create a new table for region_descriptions
Option A seems to be a good choice if adding the description column doesn't slow down mysql select queries that don't need the description.
Assuming the description column would slow down mysql, option B might be a good choice. It also removes the need for a small table with just 6-7 rows that would hold the region descriptions. Although now that I think of it, would it be slow to connect to this table if originally to get a region description you'd only need to go through very little rows.
Option C would be ideal if the description columns would slow down mysql and if a small table like region descriptions would not matter.
Maybe none of these options are the best, feel free to offer another option. Thanks.
P.S. What would be an ideal column type to use to hold data that usually 1-2 paragraphs, but might be a little more sometimes?
I don't think it really matters if you don't handle thousands of queries per minute. If you are going to have a zillion queries per minute, then I would implement the various options and perform benchmarks for all these options. Based on the results, you can make a decision.
In my (admittedly somewhat uninformed) opinion, it really depends on how much you'll be using both of them.
If properly indexed, that JOIN should not be very expensive. Also, a larger table will be slower. It inhibits caching, and takes longer to access stuff, although indexing seriously mitigates this problem.
If you'll be joining tag names to tag IDs a LOT, and only rarely will be using the descriptions, I'd say go with separate tables. If you'll be using the descriptions more often, go with one table.
For the first part of your question: if you have a tag with an id, a name and a description, you should save it in 1 table.
Now, this query
SELECT name FROM tags WHERE id = 1;
will NOT slow down if you have 1, 2 or 20 extra fields in there.
i am currently writing a webapp in rails where users can mark items as favorites and also block them. I came up two ways and wondered which one is more common/better way.
1. Separate join tables
Would it be wise to have 2 tables for this? Like:
users_favorites
- user_id
- item_id
users_blocked
- user_id
- item_id
2. single table
users_marks (or so)
- users_id
- item_id
- type (["fav", "blk"])
Both ways seem to have advantages. Which one would you use and why?
The second one has at least the advantage (if the primary key is users_id + item_id) to make sure that no user will have an item both as favorited and blocked.
I suppose I would got with that second solution -- especially considering the two tables, in the first solution, would have the same structure, which seems strange ; and it also allows you to have all the information in the same place, which might help, in some cases (reporting, for instance ? ).
I would go with #2.
It leaves all the appropriate data in a single table.
Otherwise you might have to resort to a union or distinct joins to get a full list of details.
It's just a different status of an item, so #2 will do the job. What would you do if it would be colors? Two different tables? I don't think so ;)
Edit: You might want the status in a different table and link it with a foreign key, but that's up to you. It depend on how many different status you expect to have. Just these two or many others as well?
I've got a question to which I've had opposing pieces of advice, would appreciate additional views.
My site has users, each with a user_id. These users can view products, and I need to keep track of the unique instances of users viewing specific products. To record a view in a separate views table, I've currently got two options:
OPTION 1:
view_id (INT,PK) | user_id (INT,FK) | product_id (INT,FK) | view_date
... and create a unique constraint over the two middle columns for easy updating with ON DUPLICATE KEY. If the same view already exists, I just update view_date. If not, I write a new row.
OPTION 2:
user_product (VARCHAR20,PK) | view_date
... merge the two ids into a VARCHAR with a separator in the middle, and use the primary key column for easy updating with ON DUPLICATE KEY in the same way as above.
The structure should accommodate up to approx. million unique views. Any thoughts on which option might be better or worse, and why? Big thanks in advance.
EDIT:
Thanks for the answers, seems like there's a consensus. Was leaning to the same side but just needed the reassurance.
I like the first option better - in general, its good to maintain as much atomicity as possible. If you ever want to query for all of a user's views, or something like that, it would be more difficult to do after merging two columns into one (you would need to use LIKE with a wildcard match, which will never be as fast as an indexed single-valued column). You also lose the ability to index on different fields.
Also, there is no reason why you couldnt have a primary or unique key that involved multiple columns, so I see no advantage to option 2. To perform your update, just use REPLACE (documentation) instead of INSERT - this will allow you to easily maintain your invariant of having only one row per user/product combination.
I think that the first option is your better choice. Later down the line I think it will make querying for different things a bit easier. Queries will likely be faster as well since there won't be string manipulation involved. Further, you can have a primary key over multiple columns if you need.
Definitely go for the first option. The second option will mean many queries from hell if you need to make reports to look for particular groups of users (get me all users that often view product X and product Y so we can offer them a discount), same for looking for specific groups of products (which products are often viewed by the same users, so we can launch a discount promotion)
I understand that it is not a requirement to remember all individual views. But I would certainly capture the number of times they visited the product - this is almost free, as you can keep a running total (insert 1 , on duplicate key update view_count = view_count + 1)