Travailler avec PreparedStatement

Types de déclarations

Nous avons déjà vu l' interface Statement la plus simple . Et bien qu'il soit tout à fait adapté au travail, il n'est pas aussi bien adapté aux requêtes complexes. Dans certaines sources, l'opinion est exprimée qu'il n'est pas du tout nécessaire d'utiliser Statement - des interfaces plus complexes et plus riches en fonctionnalités conviennent à la place.

• Affirmation préparée
• CallableStatement

Une question tout à fait raisonnable se pose - pourquoi ces interfaces sont-elles nécessaires ? Essayons de comprendre.

Tout d'abord, nous allons jeter un œil à l' interface PreparedStatement et aux autres fonctionnalités de JDBC. Nous nous tournerons vers l' interface CallableStatement plus tard - son utilisation, premièrement, n'est pas si courante, et deuxièmement, après tout ce qui a été considéré à ce sujet, la conversation peut déjà être assez courte.

En outre, PreparedStatement est d'une grande aide grâce à l'approche populaire du piratage de bases de données appelée SQL Injection.

Mais plus à ce sujet un peu plus tard.

Affirmation préparée

Si vous essayez de traduire le nom PreparedStatement , vous pouvez obtenir quelque chose comme "prepared statement". Le mot le plus important ici est "préparé". Qu'est-ce que la "préparation" ?

Avant d'examiner cette question, je propose de voir un point assez important du point de vue de la commodité, qui se produit très souvent. Ainsi, dans certaines applications, nous devons insérer des données de contact dans la table CONTACT. Pour ce faire, nous devons préparer une requête comme celle-ci :

INSERT INTO JC_CONTACT (FIRST_NAME, LAST_NAME, PHONE, EMAIL) VALUES (‘Harry’,'Potter','+79112345678','harry@example.com);

À première vue, il semble que tout n'est pas si difficile et effrayant. Nous devons écrire un code qui collectera la chaîne dont nous avons besoin à partir des paramètres : prénom, nom, adresse et numéro de téléphone. Vous devez juste vous rappeler que toutes les données de chaîne doivent être entourées d'un guillemet simple.

Si nous le faisons dans une fonction séparée, nous obtenons quelque chose comme ceci :

public String buildInsert(String firstName,, String lastName, String phone, String email) {
    String sql = "INSERT INTO JC_CONTACT (FIRST_NAME, LAST_NAME, PHONE, EMAIL) “+
             	”VALUES ('" + firstName + "','" + lastName + "','" + phone + "','" + email + ")";
    return sql;
}

Nous transmettons le prénom, le nom, le numéro de téléphone et l'adresse dans la fonction de paramètre du formulaire, et à partir d'eux, nous composons une chaîne de requête SQL. Les citations gâchent un peu l'image, mais jusqu'à présent, ce n'est pas effrayant.

Ok, qu'en est-il des chiffres ? Ils n'ont pas besoin d'être entourés de guillemets. Opanki, dans un cas, vous avez besoin de citations, dans l'autre non. La situation se complique.

Ajoutons maintenant un autre problème - que se passe-t-il s'il y a un guillemet ordinaire (et même pas un) à l'intérieur de la chaîne ? Vous devez d'abord rechercher ces devis et les traiter. Mdaaa. D'une manière ou d'une autre, nous commençons à nous sentir mal à l'aise.

Si nous ajoutons maintenant le traitement de la date, la tâche devient complètement ennuyeuse - vous devez faire une énorme quantité de travail. Les dates sont généralement désagréables - différents serveurs SQL acceptent différents formats de dates.

Alors que voyons-nous ? Si nous devons utiliser des paramètres à l'intérieur de la requête, la construction manuelle de la requête devient très désagréable. Et pas seulement désagréable - je dirais même ennuyeux. Il y a un grand nombre de cas à considérer, et c'est un travail terriblement ennuyeux. Fondamentalement, c'est pour de tels cas que l' interface PreparedStatement a été proposée .

Cette requête vous permet de faire deux choses :

• Préparer une demande à l'avance indiquant les endroits où les paramètres seront substitués
• Définir des paramètres d'un certain type, puis exécuter une requête avec des paramètres déjà définis

Exemple d'instruction préparée

La structure de PreparedStatement pour notre option de définition des paramètres ressemblera à ceci :

// Example variables
String firstName = "Harry";
String lastName = "Potter";
String phone = "+12871112233";
String email = "harry@example.com";

// Request with indication of places for parameters in the form of "?"
String sql = "INSERT INTO JC_CONTACT (FIRST_NAME, LAST_NAME, PHONE, EMAIL) VALUES (?, ?, ?, ?)";

// Create a request. The con variable is an object of type Connection
PreparedStatement stmt = con.prepareStatement(sql);

// Set parameters
stmt.setString(1, firstName);
stmt.setString(2, lastName);
stmt.setString(3, phone);
stmt.setString(4, email);

// Execute the request
stmt.executeUpdate();

Comme vous pouvez le voir, tout est assez simple.

Premièrement, lors de l'écriture d'une requête SQL, les endroits où les paramètres devront être remplacés sont écrits avec des points d'interrogation - "?".

Deuxièmement, la requête est créée en appelant con.prepareStatement() .

Troisièmement, le réglage des paramètres passe par l'indication du nombre et de la valeur. Veuillez noter que le nombre de paramètres commence à partir de 1, et non de 0, comme nous en avons l'habitude lorsque nous travaillons avec des tableaux et des collections.

L' interface PreparedStatement contient des méthodes pour définir des chaînes — setString() , pour définir des nombres — setInt() , setLong() , setDouble() , pour définir des dates — setDate() . Et des types plus complexes - cela peut être vu dans la documentation.

Quatrièmement, l'appel à stmt.executeUpdate() est déjà exécuté sans spécifier la chaîne de requête.

Je recommande fortement de se faire des amis avec PreparedStatement - c'est un outil très efficace.