My table looks like this,
RangeId CellId Some Coulmns more
101 1
101 2
I ll get a list with [101,2],[101,1] now i have to swap cellId values in the above table. How to write an update query for this. I went through Swapping column values in MySQL but this swaps between two coulmns. Any suggestion..
EDIT: I am swapping the cells in my app and i ll get two cell ids. I have two just swap 2 with 1 and 1 with 2 and rest of the values in the rows remains the same
EDIT2: The table doesnt have any Id column nor a primary key.
With your table as currently stated you cannot really do as you wish as there is no unique way to identify rows. I advise that you step back and look at what you are trying to do as it feels like either a: it's not been thought through, or b: you've not given enough information for this to really be solved
If b:, please provide more information on this table and the tables it links to and precisely what you are trying to achieve (yes I know you want to swap 2 numeric values however without knowing more information about the tables / what can be used to select it is VERY hard to advise accurately)
note below was written for OPs original edit
This isn't a nice way to do it but it may get what you are after, it relies on ID being a PKID
http://sqlfiddle.com/#!2/0c48c/2
Related
I have a database like this:
Database example
My problem is I need multiple entries in the Substrate spot.
Kind of like a 3 dimensional database. I need to add in things like, hay, straw, potato peels etc. But it needs to be on the same spot like a list just for substrates. I cant go down the rows because that would be messing with the wrong mushroom and the only alternative I can think about is making substrate01, substrate02 substrate03 ... but since this can vary a lot, it makes no sense to make hundreds of rows just to reserve enough space for entries. One might only have 1 substrate and another might have 50 I need it to be dynamic.
Create another table, which contains a column for the key of the one row your trying to add to, and another column for the name, like substrate1, substrate2
So table one row might look like:
MushroomKey, mushroomname
Table two might look like:
Substratekey, mushroomkey, substratename
You might also want to learn about the normal forms of a database
If I'm understanding correctly, the general method to do this is to have a second table, linked by ID that contains one substrate. Then have one record per substrate in the second table.
If you need to display it all on one line, you can join the tables and use 'group concat' to assemble them.
First, I am making a little raffle site. I have a grid of square buttons (all assigned a number) right now and I want to be able to toggle as many as I want, then send that info to my database that those squares are "taken".
Will I need to make a separate row for each square? Or is there some easier way to do this?
In the case that you want to query the database just when you click a button and not everytime you toggle a square, having a separate record for every number will be unnecessarily expensive. There are more elegant ways of achieving the same result.
I would instead suggest creating a record for individual person playing the raffle with a primary key of autoincrementing id so that you can easily identify a person. Each time a person flips the squares and hit submit, a query will be fired through php that will carry the values entered by that person which will be in form of 0s and 1s. If you have 9 squares for example, the user input will be something like 101011001. You can now save the record in form of < userid , raffleentry >. This structure will make it extremely easy for your query system to store the values as well as make out who won the raffle.
Note: You can also do some cheeky stuff and save the raffleentry as a decimal value by interpreting the raffle entry as a binary representation. hence you can save the entry as 345 instead of 101011001
EDIT: To answer OP's question in the comments
I have a primary key for my users, but I have at least 5 raffles that are going on at one time. Should I make 5 different raffleentry columns? Like raffleentry1, raffleentry2, etc
You can do that. But again theres a more elegant solution here. Make only a single column (integer) called raffleentrynumber this will take values 1-5. Now instead of creating primary key only on the userid, create it one composite (userid, raffleentrynumber). What this will do is preserve your primary key integrity constraint and also make your table much cleaner
Your table will look something like
USER_ID RAFFLEENTRYNUMBER TICKET
1 1 101010101
1 2 111100001
1 3 000000000
1 4 111111111
1 5 010101010
2 1 000011110
2 2 011110011
Yes. I would create a separate record for every number. I'd also create a second column indicating if they've been selected or not using 0's and 1's. (For example, 1 if it has or 0 if it has not). You can use SQL query statements through php to update these values.
Scenario:
I am creating a website for a checklist, it can be done/accessed by multiple users in the same time thus it needs certain fields to be editable, saveable and retrievable.
Dilemma:
The checklist has 212 entries, this means 212 rows. I have 5 columns that needs entries thus, 212x5. This means, I have to create 1060 columns to be able for me to code the website to do what I want it to do. 1060 columns on a table seems wrong and very tiring to use.
My Sample solution:
I would divide the 5 columns into 5 tables, making the date that the checklist was created as their primary key. I would then use this 5 tables for their corresponding columns thus reducing the number of columns per table to 212.
Is there anyway that I could reduce this? Sorry for the long post, any help would be appreciated.
**Edit: For some reason, I can't comment on any answers, says error on page. Nevertheless, I do appreciate everybody's answer; Yet I have 1 info that may change your answers. I have thought of making 5 columns instead of the obnoxious 1060, but doing that, I would need/The system would need to create 1 table per 1 worksheet and of course, over time, this would cause massive problems to the database.
Although still pretty huge, ah_hau's answer seems to be the smallest and easiest to handle. By using it, the system would create 217 entries per checklist, but will use 6-8 columns only. Thank you to everyone who shed light into this dillemma, I do hope that I see you guys again on my next question. Cheers!
There are different ways to do it, I'd just store a Json string per checklist. The Json string would be a Json array of object { checklistName, checklistValue, timestamp }. So, the database table would only have two columns { id, checklist }. This is on the minimum side, you might want to break it down to smaller Json objects and/or add more details to them.
looking thrrough all your requirements, thou you've ban the common 6 column setup, I'd still suggest you to use a similar setup.
try to have a table like this
id [bigInt] (PK,auto_incrment)
rowId [int] //checklist row id
columnId [int] //checklist column id
text [varchar/text]
create_date [Date]
create_time [Time]
Index
unique key chekcklist_cell (create_date, rowId, columnId)
depending on your preference, you could also split columnId field into 5 columns with name column1~5 to reduce the DB entry count. But i'd suggest using my setup as it seems like user will update your checklist 1 cell at a time (or multiple cell all around the list), which my schema will make more sense. Also this schema is very expandable and could easily add new fields to them. Last thing I could think of is that you doesn't have to lock the whole checklist while a user is only updating 1 cell. This helps speed up that concurrent access thing.
why not directly add 1 more column in your checklist table?
your table structure should look like
userid
entryid (value from 1-212)
col1_entry
col2_entry
col3_entry
col4_entry
col5_entry
I have searched for a solution for this problem, but haven't found it (yet), probably because I don't quite know how to explain it properly myself. If it is posted somewhere already, please let me know.
What I have is three databases that are related to each other; main, pieces & groups. Basically, the main database contains the most elementary/ most used information from a post and the pieces database contains data that is associated with that post. The groups database contains all of the (long) names of the groups a post in the main database can be 'posted in'. A post can be posted in multiple groups simultaneously. When a new post is added to my site, I check the pieces too see if there are any duplicates (check if the post has been posted already). In order to make the search for duplicates more effective, I only check the pieces that are posted in the same group(s).
Hopefully you're still with me, cause here's where it starts to get really confusing I think (let me know if I need to specify things more clearly): right now, both the main and the pieces database contain the full name of the group(s) (basically I'm not using the groups database at all). What I want to do is replace the names of those groups with their associated IDs from the groups database. For example, I want to change this:
from:
MAIN_table:
id | group_posted_in
--------|---------------------------
1 | group_1, group_5
2 | group_15, group_75
3 | group_1, group_215
GROUPS_table:
id | group_name
--------|---------------------------
1 | group_1
2 | group_2
3 | group_3
etc...
into:
MAIN_table:
id | group_posted_in
--------|---------------------------
1 | 1,5
2 | 15,75
3 | 1,215
Or something similar to this. However, This format specifically causes issues as the following query will return all of the rows (from the example), instead of just the one I need:
SELECT * FROM main_table WHERE group = '5'
I either have to change the query to something like this:
...WHERE group = '5' OR group = '5,%' OR group = '%,5,%' OR group = '%,5'
Or I have to change the database structure from Comma Separated Values to something like this: [15][75]. The accompanying query would be simpler, but it somehow seems like a cumbersome solution to me. Additionally, (simple) joins will not be easy/ possible at all. It will always require me to run a separate query to fetch the names of the groups--whether a user searches for posts in a specific group (in which case, I first have to run a query to fetch the id's, then to search for the associated posts), or whether it is to display them (first the posts, then another query to match the groups).
So, in conclusion: I suppose I know there is a solution to this problem, but my gut tells me that it is not the right/ best way to do it. So, I suppose the question that ties this post together is:
What is the correct method to connect the group database to the others?
For a many-to-many relationship, you need to create a joining table. Rather than storing a list of groups in a single column, you should split that column out into multiple rows in a separate table. This will allow you to perform set based functions on them and will significantly speed up the database, as well as making it more robust and error proof.
Main
MainID ...
Group
GroupID GroupName
GroupsInMain
GroupsInMainID MainID(FK) GroupID(FK)
So, for MainID 1, you would have GroupsInMain records:
1,1,1
2,1,5
This associates groups 1 and 5 with MainID 1
FK in this case means a Foreign Key (i.e. a reference to a primary key in another table). You'd probably also want to add a unique constraint to GroupsInMain on MainID and GroupID, since you'd never want the same values for the pairing to show up more than once.
Your query would then be:
select GroupsInMain.MainID, Group.GroupName
from Group, GroupsInMain
where Group.GroupID=GroupsInMain.GroupID
and Group.GroupID=5
I have a typical table, e.g.
id(int) name(varchar) address(varchar) date(datetime)
I also have a table that references validation functions for each one, e.g.
id(int) function(varchar) fail_message(varchar)
1 email Please enter a valid email address
2 required This field can not be left blank
I'd like to be able to associate each column from the first table with one or more of these validators.
The only way I can think of doing this is to stuff the ids into the column names e.g. (column name: email;1;2) and keep track of it through PHP, but that seems very messy.
Is there a good way to do this with relational databases? Would a NoSQL implementation suit this problem better?
Similar to what Dan said, a relatively easy way to implement an association in sql would be to do the following:
id(int) function_id(int) col_name(varchar)
1 1 address
2 1 second_address
3 2 address
4 2 name
And then when you want to do the failure check, use the above table to link the error message to the column name (e.g. 'select function_id from above_table where col_name="address"') and then query the failure table. These tables could subsequently be combined using a view with a join so that a single query would suffice.
Hope this helps.
put this in another table that describes the columns for tables oddly this is very much like extending the table that lists table columns with additional columns
let's say if you extend your example with say localized strings that would mean that the fail_message would become a fail_message_id and the table fail_message would have the columns (id, language, message)