Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

MySQL UPDATE vs INSERT and DELETE

I am working on a web app project and there is a rather large html form that needs to have its data stored in a table. The form and insert are already done but my client wants to be able to load the saved data back into the HTML form and be able to change it, again, this is no problem, but I came across a question when going to do the update, would it be appropriate to just keep the insert query and then delete the old row if it was an edit?

Basically, what already happens is when the form is submitted all of the data is put into a table using INSERT, I also have a flag called edit that contains the primary key ID if the data is for an existing field being updated. I can handle the update function two ways:

a) Create an actual update query with all the fields/data set and use an if/else to decide whether to run the update or insert query.

b) Do the insert every time but add a single line to DELETE WHERE row=editID after the insert is successful.

Since the Delete would only happen if the INSERT was successful I don't run the risk of deleting the data without inserting, thus losing the data, but since INSERT/DELETE is two queries, would it be less efficient than just using an if/else to decide whether to run an insert or update?

There is a second table that uses the auto-increment id as a foreign key, but this table has to be updated every time the form is submitted, so if I delete the row in table A, I will also be deleting the associated rows from table b. This seems like it would be bad programming practice, so I am leaning towards option a) anyway, but it is very tempting just to use the single line option. The DELETE would basically be as follows. Would this in fact be bad programming practice? Aside from conventions, are there any reasons why this is a "never do that!" type of code?

    if ($insertFormResults) {
        $formId = mysql_insert_id();
        echo "Your form was saved successfully.";
        if(isset($_POST['edit'])){
            $query = "DELETE FROM registerForm WHERE id='$_POST[edit]'";
            $result = mysql_query($query);
        }
    }
like image 293
awestover89 Avatar asked Jan 31 '11 18:01

awestover89


People also ask

Is it better to DELETE and INSERT or update?

For best future query performance, it's better to do an update to keep the same extents. Delete and insert will not necessarily use the same extents. For a table of that size, it would be unlikely to do so. Furthermore, delete can leave "holes" in your data.

Is INSERT same as update in mysql?

Insert is for adding data to the table, update is for updating data that is already in the table.

Is INSERT faster than update in mysql?

Insertion is inserting a new key and update is updating the value of an existing key. If that is the case (a very common case) , update would be faster than insertion because update involves an indexed lookup and changing an existing value without touching the index.

Which is faster DELETE or INSERT?

Inserting rows in a table is faster than deleting them. Loading data into a new table using create-table-as-select (CTAS) is faster still. So if you're removing most of the rows from a table, instead of issuing a delete you can: Create a new table saving the rows you want to keep.


1 Answers

Whilst the INSERT/DELETE option would work perfectly well I'd recommend against it as:

  • Unless you bundle the INSERT/DELETE up into a single transaction, or better yet encapsulate the INSERT/DELETE up into a stored procedure you do run the theoretical risk of accumulating duplicates. If you use a SP or a transaction you're just effectively rewriting the UPDATE statement which is obviously inefficient and moreover will give rise to a few WTF raised eyebrows later by anyone maintaining your code.
  • Although it doesn't sound like an issue in your case you are potentially impacting referential integrity should you need that. Furthermore you are loosing the rather useful ability to easily retrieve records in creation order.
  • Probably not a great consideration on a small application, but you are going to end up with a seriously fragmented database fairly quickly which will slow data retrieval.
like image 122
Cruachan Avatar answered Oct 02 '22 02:10

Cruachan