7
votes

MySQL Update vs insert et supprimer

Je travaille sur un projet d'application Web et il existe une forme HTML assez importante qui doit avoir ses données stockées dans une table. Le formulaire et l'insertion sont déjà terminés mais mon client souhaite pouvoir recharger les données sauvegardées dans le formulaire HTML et pouvoir le changer, ce n'est pas un problème, mais je suis tombé sur une question lorsque vous allez faire la mise à jour. Serait-il approprié de simplement conserver la requête d'insertion, puis de supprimer l'ancienne rangée s'il s'agissait d'une édition?

Fondamentalement, ce qui se passe déjà, c'est lorsque le formulaire est soumis, toutes les données sont placées dans une table à l'aide d'insert, je Vous avez également un drapeau appelé Modifier qui contient l'ID de clé primaire si les données sont mises à jour pour un champ existant. Je peux gérer la fonction de mise à jour de deux manières: p>

a) Créez une requête de mise à jour réelle avec tous les champs / jeu de données et utilisez un IF / else pour décider de lancer la mise à jour ou d'insérer la requête. P >

b) Faites l'insertion à chaque fois, mais ajoutez une seule ligne à supprimer lorsque la rangée = éditable après le succès de l'insertion. P>

puisque la suppression n'arriverait que si l'insert a été réussi que je ne réussirais pas Exécutez le risque de supprimer les données sans insérer, perdez ainsi les données, mais car insert / Supprimer est deux requêtes, serait-elle moins efficace que d'utiliser un IF / elet pour décider de lancer une insertion ou une mise à jour? p>

Il y a une deuxième table qui utilise l'ID d'incrément automatique en tant que clé étrangère, mais ce tableau doit être mis à jour chaque fois que le formulaire est soumis, donc si je supprime la ligne du tableau A, je vais Supprime également les lignes associées du tableau b. Cela semble que ce serait une mauvaise pratique de programmation, alors je me penche vers l'option a) de toute façon, mais il est très tentant d'utiliser l'option unique. Le Supprimer serait fondamentalement comme suit. Cela serait-il en fait une mauvaise pratique de programmation? Outre les conventions, y a-t-il des raisons pour lesquelles il s'agit d'un "ne fais jamais ça!" Type de code? P>

    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);
        }
    }


1 commentaires

MySQL's last_insert_id vous donnera la valeur ATOINCRÈME , que vous pouvez ensuite utiliser dans une déclaration de mise à jour. La suppression exécutera inutilement la valeur AutooincreMremrement inutilement, outre l'impact sur l'intégrité référentielle.


3 Réponses :


0
votes

mise à jour n'est qu'un voyage aller-retour au serveur, ce qui est plus efficace. Sauf si vous avez une raison qui implique la possibilité de mauvaises données, toujours par défaut à l'aide d'une mise à jour.


0 commentaires

0
votes

Il me semble que la suppression est inutile, si vous exécutez une mise à jour dans MySQL, elle ne mettra que mettre à jour l'enregistrement s'il est différent de ce que ce qui est déjà stocké, y a-t-il une raison pour laquelle vous auriez besoin de faire une suppression. . J'utilise habituellement un cas (commutateur) pour attraper les appels de mise à jour / Supprimer de l'utilisateur,

<?php
switch (action) {

case "delete" :
block of coding;
if the condition equals value1;
break;

case "edit" :
block of coding;
if the condition equals value2;
break;

}
?> 


0 commentaires

5
votes

tandis que l'option Insérer / Supprimer fonctionnerait parfaitement bien, je recommanderais contre elle comme suit:

  • sauf si vous rejetez l'insertion / Supprimer en une seule transaction, ou mieux encore encapsuler le Insérer / Supprimer dans un stockage stocké procédure que vous faites gérer la théorique risque d'accumuler des doublons. Si vous utilisez une sp ou une transaction que vous êtes juste réécrire efficacement la mise à jour déclaration qui est évidemment inefficace et en outre donnera monter à quelques sourcils surélevés WTF plus tard par quiconque conserve votre Code.
  • Bien que cela ne sonne pas comme un problème dans votre cas vous êtes potentiellement impact sur le référentiel Intégrité si vous avez besoin de cela. En outre, vous perdez la capacité plutôt utile à facilement récupérer des enregistrements dans l'ordre de création.
  • probablement pas une grande considération sur une petite application, mais vous êtes va se retrouver avec un sérieux Base de données fragmentée assez rapidement qui va ralentir la récupération de données.

3 commentaires

C'est une base de données pour l'orientation de première année chez mon université, donc au moins 1 000 nouvelles entrées chaque année, en fonction de la taille de la classe entrante. Je n'envisais pas la fragmentation et cela causerait certainement des problèmes sur la route.


@ Awesverver89 - a du sens de faire les choses correctement alors. Personnellement avec ces choses, je suis généralement motivé par le premier - pas Donner quiconque vient après moi un moment WTF. Votre réputation est importante et bien que vous codissez, ils seront quelqu'un qui viendra plus tard qui vous critiquera (peut-être parce qu'ils font eux-mêmes des choses étranges), il vaut mieux ne pas leur donner l'excuse en utilisant des constructions inhabituelles pour des opérations standard.


Je suis d'accord avec Cruachan. Mettre à jour essentiellement est "Insérez un nouveau et supprimez l'ancien," Sauf que 1) C'est une opération atomique, 2) il conserve le même ID 3) C'est la façon dont MySQL comprend nativement cela et 4) C'est la façon dont tout le monde le fait. 3 et 4 sont à la fois importants. MySQL sera mieux optimisé pour faire des choses la solution standard. Et absolument le prochain programmeur comprendra "la mise à jour" plus rapidement. Essayez de ne faire que des choses de manière non standard lorsque vous avez une raison limitée et peut expliquer cela dans les commentaires.