I do not know a lot of mysql. I have two tables on same server:
A.artists
id | artist_name
--------------------
8 | XXXX |
1 | YYYY |
5 | ZZZZ |
A.albums
id | artist_id | album_name
-----------------------------
1 | 5 | Album 1
2 | 1 | Album 2
3 | 8 | Album 3
I want to reorder the artist_id column, accordingly, at the same time I want to change A.artists's id column from reordered artist_id id.
Is it possible such a thing? How can I do that? Thanks!
First, you need to understand that tables in SQL are unordered. So, you cannot specify an ordering for the table. You can specify an ordering for a query.
My guess is that you want to join the two tables to get the name with the albums:
select al.*, ar.name
from albums al join
artists ar
on al.artist_id = ar.id
order by ar.name
The way your question is phrased is that you want to re-assign ids. Normally, this would not be necessary, since the ids exist only to uniquely identify rows. If you have a good reason for reassigning ids, then modify your question or ask a new question, including the reason.
Related
Here is my pivot table project_group:
+-----+----------+------------+----------+---------+
| ids | group_id | project_id | admin_id | user_id |
+-----+----------+------------+----------+---------+
| 4 | 115 | 1 | 1 | [3,4,5] |
| 5 | 115 | 2 | 1 | [5,2,1] |
| 6 | 115 | 3 | 1 | [1,3,6] |
This table represent group linked to the projects....user_id is which users can see projects/group... Is there any way to display correct projects/group only to the users defined in user_id?
Also content in user_id field can be changed....
The best way to handle this would be to first normalize your database. Storing comma separated lists in a cell is allowed, but generally bad practice, as explained in this question.
If you can have multiple users per project, you should have a linking table with a column for project and a column for user, like this:
project_users:
| project_id | user_id |
and you can make (project_id, user_id) a composite primary key.
That way, you can select the users for a project (say, project 1) like this:
SELECT user_id
FROM project_users
WHERE project_id = 1;
Once you have these, you can display the project data only to users whose id is returned in the above list.
I have built an SQL Fiddle that helps demonstrate this visually, if it helps.
It is good to note that this proper normalization gives the opportunity to a lot of useful data as well, as it becomes easier to search for users by project, but also you can search for project information based on a user.
I have run into a problem that I'm sure is easy to achieve. I have a table for some merchandise. It holds all the information including the id for the manufacturer. The information about the manufacturer is in a separate table. When users are searching they have filter options. The one I'm having trouble with is filtering by manufacturer.
Products Table: cs_products
id | name | manufacturer_id
---------------------------
1 | mic | 3
2 | cable | 2
3 | speaker | 1
Manufacturer Table: cs_manufacturer
id | name
------------------
1 | JBL
2 | Rapco
3 | Shure
When the query is ran I need to ORDER BY cs_manufacturer.name:
mysql_query("SELECT * FROM cs_products ORDER BY cs_manufacturer.name")
What is the proper syntax for this?
SELECT * FROM cs_products JOIN cs_manufacturer
ON cs_product.manufacturer_id = cs_manufacturer.id
ORDER BY cs_manufacturer.name
You are missing your join.
SELECT * FROM cs_products
JOIN cs_manufacturer on cs_products.manufacturer_id = cs_manufacturer.id
ORDER BY cs_manufacturer.name
I know that this title is overused, but it seems that my kind of question is not answered yet.
So, the problem is like this:
I have a table structure made of four tables (tables, rows, cols, values) that I use to recreate the behavior of the information_schema (in a way).
In php I am generating queries to retrieve the data, and the result would still look like a normal table:
SELECT
(SELECT value FROM `values` WHERE `col` = "3" and row = rows.id) as "col1",
(SELECT value FROM `values` WHERE `col` = "4" and row = rows.id) as "col2"
FROM rows WHERE `table` = (SELECT id FROM tables WHERE name = 'table1')
HAVING (col2 LIKE "%4%")
OR
SELECT * FROM
(SELECT
(SELECT value FROM `values` WHERE `col` = "3" and row = rows.id) as "col1",
(SELECT value FROM `values` WHERE `col` = "4" and row = rows.id) as "col2"
FROM rows WHERE `table` = (SELECT id FROM tables WHERE name = 'table1')) d
WHERE col2 LIKE "%4%"
note that the part where I define the columns of the result is generated by a php script. It is less important why I am doing this, but I want to extend this algorithm that generates the queries for a broader use.
And we got to the core problem, I have to decide if I will generate a where or a having part for the query, and I know when to use them both, the problem is my algorithm doesn't and I have to make a few extra checks for this. But the two above queries are equivalent, I can always put any query in a sub-query, give it an alias, and use where on the new derived table. But I wonder if I will have problems with the performance or not, or if this will turn back on me in an unexpected way.
I know how they both work, and how where is supposed to be faster, but this is why I came here to ask. Hopefully I made myself understood, please excuse my english and the long useless turns of phrases, and all.
EDIT 1
I already know the difference between the two, and all that implies, my only dilemma is that using custom columns from other tables, with variable numbers and size, and trying to achieve the same result as using a normally created table implies that I must use HAVING for filtering the derived tables columns, at the same time having the option to wrap it up in a subquery and use where normally, this probably will create a temporary table that will be filtered afterwards. Will this affect performance for a large database? And unfortunately I cannot test this right now, as I do not afford to fill the database with over 1 billion entries (that will be something like this: 1 billion in rows table, 5 billions in values table, as every row have 5 columns, 5 rows in cols table and 1 row in tables table = 6,000,006 entries in total)
right now my database looks like this:
+----+--------+-----------+------+
| id | name | title | dets |
+----+--------+-----------+------+
| 1 | table1 | Table One | |
+----+--------+-----------+------+
+----+-------+------+
| id | table | name |
+----+-------+------+
| 3 | 1 | col1 |
| 4 | 1 | col2 |
+----+-------+------+
where `table` is a foreign key from table `tables`
+----+-------+-------+
| id | table | extra |
+----+-------+-------+
| 1 | 1 | |
| 2 | 1 | |
+----+-------+-------+
where `table` is a foreign key from table `tables`
+----+-----+-----+----------+
| id | row | col | value |
+----+-----+-----+----------+
| 1 | 1 | 3 | 13 |
| 2 | 1 | 4 | 14 |
| 6 | 2 | 4 | 24 |
| 9 | 2 | 3 | asdfghjk |
+----+-----+-----+----------+
where `row` is a foreign key from table `rows`
where `col` is a foreign key from table `cols`
EDIT 2
The conditions are there just for demonstration purposes!
EDIT 3
For only two rows, it seems there is a difference between the two, the one using having is 0,0008 and the one using where is 0.0014-0.0019. I wonder if this will affect performance for large numbers of rows and columns
EDIT 4
The result of the two queries is identical, and that is:
+----------+------+
| col1 | col2 |
+----------+------+
| 13 | 14 |
| asdfghjk | 24 |
+----------+------+
HAVING is specifically for GROUP BY, WHERE is to provide conditional parameters. See also WHERE vs HAVING
I believe the having clause would be faster in this case, as you're defining specific values, as opposed to reading through the values and looking for a match.
See: http://database-programmer.blogspot.com/2008/04/group-by-having-sum-avg-and-count.html
Basically, WHERE filters out columns before passing them to an aggregate function, but HAVING filters the aggregate function's results.
you could do it like that
WHERE col2 In (14,24)
your code WHERE col2 LIKE "%4%" is bad idea so what about col2 = 34 it will be also selected.
i have a form that has a multiple select drop down. a user can select more than one options in the select. the name of the select is array[]; using php I call implode(",",$array)
in mysql db, it stores the field as a text in this format "places"= "new york, toronto, london" when i want to display these fields i explode the commas.
I am trying to run a report to display the places. here is my select:
"select * from mytable where db.places .. userSelectedPlaces"
how can i check toronto in lists of "places" that user selected? note "places" in the db might be either just "toronto" or it might be comma separated lists of places like "ny, toronto, london, paris, etc".
If it is possible, you would be much better off using another table to hold the places that the user has selected. Call it SelectedPlaces with columns:
mytable_id - To join back to the table in your query
place - EG: "Toronto"
Then you can run a simple query to figure out if Toronto has been selected:
SELECT *
FROM mytable m
INNER JOIN SelectedPlaces sp ON sp.mytable_id = m.id
WHERE sp.place = 'Toronto'
If I understand you correctly, your database design is just wrong. Try reading about it more. Generally, in good design you should not have lists of values as one field in database and you should introduce new table for it.
But if you want to do it this way, you can use strcmp function.
If i understood correctly, this should work:
WHERE DB.PLACES LIKE '%TORONTO%'
but as other users said, its not a nice thing to have denormalized tables.
To directly answer your question, your query needs to look something like this
SELECT *
FROM mytable
WHERE places LIKE( '%toronto%' )
But, be aware, that LIKE() is slow.
To indirectly answer your question, your database schema is all wrong. That is not the right way to do a M:N (many-to-many) relationship.
Imagine instead you had this
mytable place mytable_place
+------------+ +----------+----------+ +------------+----------+
| mytable_id | | place_id | name | | mytable_id | place_id |
+------------+ +----------+----------+ +------------+----------+
| 1 | | 1 | new york | | 1 | 1 |
| 2 | | 2 | toronto | | 1 | 2 |
| 3 | | 3 | london | | 1 | 3 |
+------------+ +----------+----------+ | 2 | 2 |
| 3 | 1 |
| 3 | 3 |
+------------+----------+
The table mytable_places is what's called a lookup table (or, xref/cross-reference table, or correlation table). Its only job is to keep track of which mytable records have which place records, and vice versa.
From this example we can see that The 1st mytable record has all 3 places, the 2nd has only toronto, and the 3rd has new york and london.
This opens you up too all sorts of queries that would be difficult, expensive, or impossible with your current design.
Want to know how many mytable records have toronto? No problem
SELECT COUNT(*)
FROM mytable_place x
LEFT JOIN place p
ON p.place_id = x.place_id
WHERE p.name = 'toronto';
How about the number of mytable records per place, sorted?
SELECT p.name
, COUNT(*) as `count`
FROM mytable_place x
LEFT JOIN place p
ON p.place_id = x.place_id
GROUP BY p.place_id
ORDER BY `count` DESC, p.name ASC
And these are going to be much faster than any query using LIKE since they can use indexes on columns such as place.name.
I have 3 mysql tables: events, artists and (artist) descriptions. All of them are in many-to-many relations.
Table 'events':
ID | eventTitle | etc.
-----------------------
1 | event 1 |
2 | event 2 |
etc.
Table 'artists':
ID | artistName | etc.
-----------------------
1 | artist 1 |
2 | artist 2 |
etc.
Table 'descriptions':
ID | artistDesc | etc.
----------------------------------
1 | artist 1 description 1 |
2 | artist 1 description 2 |
3 | artist 2 description 1 |
4 | artist 2 description 2 |
5 | artist 3 description 1 |
etc.
I made also junction tables events_artists and artists_desctriptions. Both of them have only 2 foreign keys and serve only for linking event, artist and description IDs.
Notice in my descriptions table - each artist can have many descriptions. That actually means that each description belongs to only one specific event. =)
If I do a query like this:
$q = "SELECT
events.*,artists.*,descriptions.*,events_artists.*,artists_descriptions.*
FROM
events,artists,descriptions,events_artists,artists_descriptions
WHERE
events.eventID = events_artists.eventID AND
events_artists.artistID = artists.artistID AND
artists.artistID = artists_descriptions.artistID AND
artists_descriptions.descID = descriptions.descID";
I will get all the descriptions for a particular artist. But none of descriptions will be aware which event they belong to...
What I want to display to user is something like this:
EVENT 1
artist 1 (artist 1 description 1)
artist 2 (artist 2 description 2)
EVENT 2
artist 3 (artist 3 description 6)
artist 1 (artist 1 description 3)
etc.
Should I make a junction table for event-description relation? If I do, I don't know exactly how to use it, uff! =)
Or maybe my problem isn't solvable with a simple query? Should I do something with php too? Sorry but I am totally confused =)
I hope I managed to explain my problem properly...
Thanks in advance for any help!
you should combine events_artists & descriptions tables to have only 1 table that links artist to an event and a description.
Can you modify the tables you already have? If so, and if each artist description can have only one artist and one event, then I would modify your schema to be:
Table event as is.
Table artists as is.
Table descriptions:
ID | artistDesc | artistId | eventId | etc.
------------------------------------------------------------------
1 | description of artist at event | 4 | 1 | ...
Then you can select all descriptions for an event with:
$query = "SELECT
events.*,artists.*,descriptions.*
FROM
events,artists,descriptions
WHERE
artists.artistID = descriptions.artistID AND
events.eventID = descriptions.eventID AND
events.eventID = $eventIdYouWant";
You can change the last row of that query to either events.event_name = $eventNameYouWant or artists.artist_name = $artistNameYouWant and it will work the same as if you were directly specifying the id.
you have already said its a relation between 3 tables .. so i think the answer is pretty obvious .. you need to have 1 table artist_id , event_id and description_id in ONE table instead of diving that into two tables like u have now.
I think you should alter your table structure, if you can.
It will result in a neater design.
Make a table, artist_event_description which contains all the IDs as foreign keys, instead of the two junction tables, it will help you to find out, to which event and artist a description belongs.
Another thing you can do is to include two more columns in the Description table, eventId and artistId (these will be foreign keys) and remove the junction tables. This way you will directly get all the information you need by just doing a SELECT over the description table.