I am trying to work with a two (already) generated tables.
In one table 1 there is a column named column_code
In table 2 the columns are named like the data in column_code
Per example
Table 1:
meta_data
----------------------------------
| pid | 1 |
| question | favorite website |
| column_code | AA123ZZ |
----------------------------------
where column_code has a content named: 'AA123ZZ'
and question is called: what is your favorite website
Table 2:
content
-----------------------------------
| id | 4 |
| submit_date | 14-01-2013 |
| AA123ZZ | stackoverflow.com |
-----------------------------------
The content of this table_name AA123ZZ is for instance "stackoverflow.com"
Now what I want is a query where the result will be something like:
id: = 1
what is your favorite website: stackoverflow.com
So actually AA123ZZ stands for this question, I have no other way of matching these together, how can I do this?
I am sorry I cannot make this any clearer.
I got these two tables and indeed they seem to be missing something.
So to try make this a bit clearer.
In the content table the table name AA123ZZ is 'code' for the question.
The maker of the database should just have placed the question as column name in stead of this code AA123ZZ. Now I need to match this code to what is inside meta_data.
So in meta_data in the question_column you can find: "favorite website"
and in the column_code you will find AA123ZZ.
in the content table in the AA123ZZ column you will find: stackoverflow.com
As you can see I cannot match these easily on a inner join.
So is there a way to match a column_name from one table to the contents of a column in another table?
You can't join tables where the column name itself is variable. You're going to need to fix the schema here, perhaps to include a foreign key value to the meta_data table from the content table and from there you can do a simple join on the two tables.
Read more on foreign keys
Related
I have a list of ids in text format as a comma separated value like so
("12345", "12346", "12347", etc, etc)
I would like to find their existence or non existence from a table say devices table which has a column called device ids (not primary key)
Ideally i would like to get a list which says if each item exists or not.
So far I have tried to get the query of those that exist and I have to manually find the non existing ones.
Is there a for loop I have to run on stored procedures or something like that. Please help.
Table structure
<pre>
| id | device_id | device_name |
+------+-----------------+---------------+
| 71 | 352701060409650 | 57X |
| 13 | 352701060409700 | 582 |
</pre>
You need to create a query with left join to the same table with 'IFNULL' condition. There already has been a post for this topic. Please check this out here.
Lookup table - unique row identity
The other lookup tables just do not make sense as from what I have seen giving a row an ID then putting that id in another table which also has a id then adding these id's to some more tables which may reference them and still creating a lookup tables with more id's (this is how all the examples I can find seem) What I have done is this :
product_item - table
------------------------------------------
id | title | supplier | price
1 | title11 | suuplier1 | price1
etc.
it then goes on to include more items (sure you get it)
product_feature - table
--------------------------
id | title | iskeyfeature
1 | feature1 | true
feature_desc - table
-----------------------------
id | title | desc
1 | desc1 | text description
product_lookup - table
item_id | feature_id | feature_desc
1 | 1 | 1
1 | 2 | 2
1 | 3 | 3
1 |64 | 15
(as these only need to be referenced in the lookup the id's can be multiples per item or multiple items per feature)
What I want to do without adding item_id to every feature row or description row is retrieve only the columns from the multiple tables where their id is referenced in the same row of the lookup table. I want to know if it is possible to select all the referenced columns from the lookup row if I only know the item_id eg. Item_id = 1 return all rows where item_id = 1 with the columns referenced in the same row. Every item can have multiple features and also every feature could be attached to multiple items , this will not matter if I can just get the pattern right in how to construct this query from a single known value.
Any assistance or just some direction will be greatly appreciated. I'm using phpmyadmin, and sure this will be easier with some php voodoo I am learning mysql from tutorials ect and would like to know how to do it with sql directly.
Having a NULL value in a column is not the major concern that would lead to this design - it's the problem with adding new attribute columns in the future, at which MySQL is disgracefully bad.
If you want to make a query that returns everything about an item in one row, you need to LEFT OUTER JOIN back to the product_lookup table for each feature_id. This is about every 10th mysql question on Stack Overflow, so you should be able to find tons of examples.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am trying to create an application like Facebook in which each user can create multiple albums and then place photos inside it. Users can also comment on the photos, so I need to make a database where album_name, pic_name, then comments on the pic will be applied.
I have a concept but I don't know whether it is feasible or not.
Here is my user table schema:
candidate_register_table
|----------------------------------------------------|
| username | name | age | sex | password |
|----------------------------------------------------|
A record would look like this:
|---------------------------------------------------------|
| saz26 | Saswat Routroy | 26 | Male | Saswat |
|---------------------------------------------------------|
Now I want to create a table holding the album_names for each user creating albums.
Say the table name is saz26_albums, where saz26 is the username in the candidate_register_table, (I am concatenating the username with the string "_albumname" to create a table) the schema of this table will be like this:
|------------------------------|
| album_name | cover_pic |
|------------------------------|
A tuple in the above table will look like this:
|--------------------------------------------------------------------------|
| Candidate_Pics/Male/saz26/MyPics |Candidate_Pics/Male/saz26/MyPics/2.jpg|
|--------------------------------------------------------------------------|
That means, for each username, a new table username_albums will be created holding the path of each albums(folder) he creates:
Another table with the name saz26_pics will be created with the following schema:
|------------------------------------------|
| pic_name | album_name | caption |
|------------------------------------------|
For example like this:
|------------------------------------------|-----------------------------------|----------|
| Candidate_Pics/Male/saz26/MyPics/1.jpeg | Candidate_Pics/Male/saz26/MyPics | At Sea |
|------------------------------------------|-----------------------------------|----------|
Now, the last part, which definitely needs a table for each picture, I mean that a table denoting a single pic, and it contains all the usernames, and their corresponding comments given by them.
Say for example, a table with name:
saz26_MyPics/1_comments
|----------------------------|
| username | comments |
|----------------------------|
For example like this:
|----------------------------------|
| suhani18 | Where is this place |
|----------------------------------|
| saz26 | Dead Sea |
|----------------------------------|
I don't know whether any other possible design can be achieved, I just want someone to let me know any other possibilities. If any other possibilities not present, then is my design feasible enough?
Some people told me to maintain a schema somewhat like this by creating a table albums:
|-----------------------------------------|
| username | album_name | cover_pic |
|-----------------------------------------|
This doesn't solve my problem which is how to maintain comments on each picture. Because some pictures can have 200 comments, some 3 comments and some will have no comments at all.
You only need four tables: users, albums, pics and comments. Each table should have an id column of type int, with auto_increment, and set as the primary key for the table.
Then on table albums you have a user_id column for the album owner. On pics, you have an album_id, and on comments you have both pic_id and user_id (all int columns, preferably indexed).
With such a structure, you can easily retrieve you data using SQL JOINS.
UPDATE
Since username is already a PK on the users table, you can use that instead of user_id in albums and comments.
About the comments table: it seems to me that it only needs 3 columns: username (the user who made the comment), pic_id (the id of the picture the comment refers to), and comment (the comment itself).
Sorry for the confusing question, I will try to clarify.
I have an SQL database ( that I did not create ) that I would like to write a query for. I know very little about SQL, so it is hard for me to even know what to search for to see if this question has already been asked, so sorry if it has. It should be an easy solution for those in the know.
The query I need is for a search I would like to perform on an existing data management system. I want to return all the documents that a given user has NOT signed-off on, as indicated by rows in a signoffs_table. The data is stored similarly to as follows: (this is actually a simplification of the actual schema and hides several LEFT JOINS and columns)
signoffs_table:
| id | user_id | document_id | signers_list |
The naive solution I had was to do something like the following:
SELECT document_id from signoffs_table WHERE (user_id <> $BobsID) AND signers_list LIKE "%Bob%";
This works if ONLY Bob signs the document. The problem is that if Bob and Mary have signed the document then the table looks like this:
signoffs_table:
-----------------------------------------------
| id | user_id | document_id | signers_list |
-----------------------------------------------
| 1 | 10 | 100 | "Bob,Mary,Jim" |
| 2 | 20 | 100 | "Bob,Mary,Jim" |
-----------------------------------------------
(assume Bob's ID = 10 and mary's ID = 20).
and then when I do the query then I get back document_id 100 (in row #2) because there is a row that Bob should have signed, but did not.
Is what I am trying to do possible with the given database structure? I can provide more details if needed. I am not sure how much details are needed.
I guess this query is what you mean:
SELECT document_id FROM signoffs_table AS t1
WHERE signers_list LIKE "%Bob%"
AND NOT EXISTS (
SELECT 1 FROM signoffs_table AS t2
WHERE (t2.user_id = $BobsID) AND t2.document_id = t1.document_id )
I believe your design is incorrect. You have a many-to-many relationship between documents and signers. You should have a junction table, something like:
ID DocumentID SignerID
I have a CMS system that stores data across tables like this:
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
Entries META Table
+----+----------+-------+-------+
| id | entry_id | value | param |
+----+----------+-------+-------+
Files Table
+----+----------+----------+
| id | entry_id | filename |
+----+----------+----------+
Entries-to-Tags Table
+----+----------+--------+
| id | entry_id | tag_id |
+----+----------+--------+
Tags Table
+----+-----+
| id | tag |
+----+-----+
I am in trying to implement a revision system, a bit like SO has. If I was just doing it for the Entries Table I was planning to just keep a copy of all changes to that table in a separate table. As I have to do it for at least 4 tables (the TAGS table doesn't need to have revisions) this doesn't seem at all like an elegant solution.
How would you guys do it?
Please notice that the Meta Tables are modeled in EAV (entity-attribute-value).
Thank you in advance.
Hi am currently working on solution to similar problem, I am solving it by splitting my tables into two, a control table and a data table. The control table will contain a primary key and reference into the data table, the data table will contain auto increment revision key and the control table's primary key as a foreign key.
taking your entries table as an example
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
becomes
entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+
to query
select * from entries join entries_data on entries.revision = entries_data.revision;
instead of updating the entries_data table you use an insert statement and then update the entries table's revision with the new revision of the entries table.
The advantage of this system is that you can move to different revisions simply by changing the revision property within the entries table. The disadvantage is you need to update your queries. I am currently integrating this into an ORM layer so the developers don't have worry about writing SQL anyway. Another idea I am toying with is for there to be a centralised revision table which all the data tables use. This would allow you to describe the state of the database with a single revision number, similar to how subversion revision numbers work.
Have a look at this question: How to version control a record in a database
Why not have a separate history_table for each table (as per the accepted answer on the linked question)? That simply has a compound primary key of the original tables' PK and the revision number. You will still need to store the data somewhere after all.
For one of our projects we went the following way:
Entries Table
+----+-----------+---------+
| id | date_from | date_to |
+----+--------_--+---------+
EntryProperties Table
+----------+-----------+-------+------+--------+--------+
| entry_id | date_from | title | text | index1 | index2 |
+----------+-----------+-------+------+--------+--------+
Pretty much complicated, still allows to keep track of full object's lifecycle. So for querying active entities we were going for:
SELECT
entry_id, title, text, index1, index2
FROM
Entities INNER JOIN EntityProperties
ON Entities.id = EntityProperties.entity_id
AND Entities.date_to IS NULL
AND EntityProperties.date_to IS NULL
The only concern was for a situation with entity being removed (so we put a date_to there) and then restored by admin. Using given scheme there's no way to track such kind of tricks.
Overall downside of any attempt like that is obvious - you've to write tons of TSQL where non-versioned DBs will go for something like select A join B.