In a customer CMS the customer can update their personal information, like change their address and first/last name. I use a mysql UPDATE query for that.
Problem with working like this is, is that people can change their information. E.g. change their name from john doe to asdfdas. I would like to SAVE their old information.
What are my options? What is the best way to do this?
Assuming the user has a unique ID you could have an old_user_information table and when you do an update also do a new entry into that table. The table would have an autogenerated ID as well as the unique user ID and the rest of that users past information.
A user could have multiple rows in this table but only one row in the real Users table.
Edit: If I were you I would write a stored procedure that does both of these things so that it is easier to manage if things change.
You can make table that contains something like this
`yourTableID, field, value, date`
and update this with a trigger. You write an update trigger that adds the old value if it is changed. Look at the manual here to find out more about triggers.
If you don't want to use triggers you could obviously do the same in your logic: just update the history table with the old value. But this needs some trickery to find out if you need to update it, but nothing to complicated.
For easy retrieval what happened you might want to add something like "oldvalue" AND "newvalue", but the latter isn't really needed, as it is either in the next update as 'old' value, or it is the current value.
Create new columns for the data being updated column would be prior_to_update_column
On update, move the old info into prior_to_update_column
If the user updates again, append to the prior_to_update_column seperated by , (to look like an array).
This should keep all the previous info the user updates
add an additional field name version
and use Insert instead of update
あの答えのとうりに、やってない。
UPDATE table name SET column=column+'new value' WHERE condition
Related
I want to maintain the history table for my application to track what all the fields were changed by the user.
The following is my bugs_history table structure -
id, bugsid, userid, field_changed, old_value, new_value, created_on, created_by
So my query is, when I'll update my form and submit, how to get the field name that was changed along with old value and new value. And add the modified changes in the above history table.
I have googled a lot for this but didn't get as per my requirments. Please let me know how to achieve this.
If you know the field names (you have a HTML form containing them, so you probably know the names) then build a list of them that you then loop through, building a new SELECT query to get old_value and then an INSERT query to save it. The select would order on created_on DESC and LIMIT 1.
But I see a clear problem here: concurrency. What happens when two users try to edit the same bug (with the same bugsid) at the same time? They would expect the old_value to be the same for both? Or should the two operations be executed sequentially? Or should the last one to edit be warned that he's trying to edit stale data? Which one would get the "latest" created_on?
This right here is your real problem, not writing the code that generates two SQL queries.
I have gone through this post
I have a Database that has id,password,date of birth.
id|name|password|dob
1 |avi |vx1 |2013-1-1
I have a few questions lets say a user wishes to change his/her password then what is the correct way to go should I use UPDATE user SET password='pusheen' WHERE id=1 or Should I delete the value first and then Insert the value in the column.
(I understand password should be inserted in database in encrypted form but I`m newbie learning so saving it as plain text.)
The link above suggests not to use update is the case in above link similar to mine?
The same goes for any other field lets say I wish to have name field as blank/null.
whats the command to delete a field say name where id=1 and insert again? each time I try to delete I end up deleting the whole row.
is use of UPDATE user SET name=NULL WHERE id=1 not the correct way?
You can delete the record simply by using
delete from user where id = 1
but if you are going to update the user password,then you don't need to delete and insert as new one.. you can simply use the update statement like
UPDATE user SET password='pusheen' WHERE id=1
If you want to insert new user, then only goes to insert statement like
insert into user(id,name,password,dob) values
(2,'name','password','11/11/1985')
Aside: You should not store passwords as plain text ever. This answer shows the simplest method that you will not have a problem using. It's better than nothing.
The right way is to UPDATE because in that table you will have multiple columns and you don't want to miss something.
UPDATE user SET name='username' WHERE id=1
I am working on a database application with MySQL and PHP. At this moment I'm trying to get the changes caused by the last UPDATE. My first way to solve the problem is
getting the 'old' state with SELECT
Doing the changes with UPDATE
getting the 'new' state with SELECT
comparing the arrays with php
These are three mysql-connections...
Is there any way to shorten this?
You could do an before update trigger that will push an entire copy of the record to a history table that also contains additional state data you wish to store (updated date, user etc.)
This way you will have a complete revision history of what happened with what records and it should happen transparently. only think to remember is you should drop any unique constraints from the history table.
Hope this helps.
you can use the following hack using variables:
update table set
col=(#oldValue:=col),col=newValue
where id=1234;
select #oldValue;
Let me tell you how I do that,
When I update a row, firstly I get which row I'm updating and I call them active records. Then I compare each column of active records with the form fields. That's how I know which column has changed.
And if you want to store changed columns, create history table that would be like;
id (for primary key)
tablename (which table i'm updating)
recordid (which row i'm updating)
column (which columns has been changed)
oldvalue (active record value)
newvalue (form value-updated value)
date (obvious)
user (who did this change)
After that, you can use your imagination for structures how you want to use.
I have a MySQL database where I am storing information that is entered from a PHP web page. I have a page that allows the user to view an existing row, and make changes and save them to the database. I want to know the best way to keep the original entries, as well as the new update and any subsequent updates.
My thought is to make a new table with the same columns as the first, with an additional timestamp field. When a user submits an update, the script would take the contents of the main table's row, and enter them into the archive table with a timestamp when it was done, and then enter in the new values to the main table. I'd also add a new field to the main table to specify whether or not the row has ever been edited.
This way, I can do a query of the main table and get the most current data, and I can also query the archive table to see the change history. Is this the best way to accomplish this, or is there a better way?
You can use triggers on update, delete, or insert to keep track of all changes, who made them and at what time.
Lookup database audit tables. There are several methods, I like the active column which gets set to 0 when you 'delete' or 'update' and the new record gets inserted. It does make a headache for unique key checking. The alternative I've used is the one you have mentioned, a separate table.
As buckbova mentions you can use a trigger to do the secondary insert on 'delete' or 'update'. Otherwise manage it in your PHP code if you don't have that ability.
You don't need a second table. Just have a start and end date on each row. The row without an end date is the active record. I've built entire systems using this method, and just so long as you index the date fields, it's very fast.
When retrieving the current record, AND end_date IS NULL gets added to the WHERE clause.
In this situation, I would recommend you to consider all properties in one table after adding it few columns:
active/ not active
ID of the person who kept these parameters
timestamp of adding
How can we re-use the deleted id from any MySQL-DB table?
If I want to rollback the deleted ID , can we do it anyhow?
It may be possible by finding the lowest unused ID and forcing it, but it's terribly bad practice, mainly because of referential integrity: It could be, for example, that relationships from other tables point to a deleted record, which would not be recognizable as "deleted" any more if IDs were reused.
Bottom line: Don't do it. It's a really bad idea.
Related reading: Using auto_increment in the mySQL manual
Re your update: Even if you have a legitimate reason to do this, I don't think there is an automatic way to re-use values in an auto_increment field. If at all, you would have to find the lowest unused value (maybe using a stored procedure or an external script) and force that as the ID (if that's even possible.).
You shouldn't do it.
Don't think of it as a number at all.
It is not a number. It's unique identifier. Think of this word - unique. No record should be identified with the same id.
1.
As per your explanation provided "#Pekka, I am tracking the INsert Update and delete query..." I assume you just some how want to put your old data back to the same ID.
In that case you may consider using a delete-flag column in your table.
If the delete-flag is set for some row, you shall consider program to consider it deleted. Further you may make it available by setting the delete-flat(false).
Similar way is to move whole row to some temporary table and you can bring it back when required with the same data and ID.
Prev. idea is better though.
2.
If this is not what you meant by your explanation; and you want to delete and still use all the values of ID(auto-generated); i have a few ideas you may implement:
- Create a table (IDSTORE) for storing Deleted IDs.
- Create a trigger activated on row delete which will note the ID and store it to the table.
- While inserting take minimum ID from IDSTORE and insert it with that value. If IDSTORE is empty you can pass NULL ID to generate Auto Incremented number.
Of course if you have references / relations (FK) implemented, you manually have to look after it, as your requirement is so.
Further Read:
http://www.databasejournal.com/features/mysql/article.php/10897_2201621_3/Deleting-Duplicate-Rows-in-a-MySQL-Database.htm
Here is the my case for mysql DB:
I had menu table and the menu id was being used in content table as a foreign key. But there was no direct relation between tables (bad table design, i know but the project was done by other developer and later my client approached me to handle it). So, one day my client realised that some of the contents are not showing up. I looked at the problem and found that one of the menu is deleted from menu table, but luckily the menu id exist in cotent table. I found the menu id from content table that was deleted and run the normal insert query for menu table with same menu id along with other fields. (Id is primary key) and it worked.
insert into tbl_menu(id, col1, col2, ...) values(12, val1, val2, ...)