Travailler avec SQL Server

SQL est notre tout

Comme vous le devinez probablement déjà, toutes les commandes au serveur SQL peuvent être transmises via des requêtes SQL. Tout.

Ces équipes sont officiellement divisées en 4 groupes :

• déclarations de définition de données (Data Definition Language, DDL ):

  • CREATE crée un objet de base de données (base de données elle-même, table, vue, utilisateur, etc.)
  • ALTER modifie un objet
  • DROP supprime un objet

• opérateurs de manipulation de données (Data Manipulation Language, DML ) :

  • SELECT sélectionne les données qui satisfont aux conditions données
  • INSERT ajoute de nouvelles données
  • UPDATE modifie les données existantes
  • DELETE supprime les données

• opérateurs de définition d'accès aux données (Data Control Language, DCL ):

  • GRANT accorde à un utilisateur (groupe) des autorisations pour effectuer certaines opérations sur un objet
  • REVOKE révoque les autorisations précédemment émises
  • DENY établit une interdiction qui a préséance sur un permis

• Instructions TCL ( Transaction Control Language) :

  • COMMIT applique une transaction
  • ROLLBACK annule toutes les modifications apportées dans le contexte de la transaction en cours
  • SAVEPOINT divise une transaction en sections plus petites

Et les deux premiers niveaux, nous avons étudié uniquement les variétés de l'instruction SELECT. Imaginez combien de choses intéressantes nous attendent dans le futur.

Mais nous nous préparons ici principalement sur les programmeurs Java, nous étudierons donc les scénarios que vous rencontrerez certainement au travail.

L'administrateur système du projet créera très probablement toutes les bases de données, mais vous devrez certainement faire une sélection à partir des données vous-même plusieurs fois.

De plus, parfois, votre code n'écrira pas toutes les données dans la base de données ou ne l'écrira pas dans le bon sens, vous devrez donc souvent y grimper avec des stylos et voir ce qui y est réellement stocké.

Reprenons les choses que nous avons abordées dans les conférences précédentes.

Créer un schéma dans une base de données

Pour créer un nouveau schéma dans le SGBD, vous devez exécuter la commande :

CREATE SCHEMA Name;

C'est l'option la plus simple. De plus, lors de la création d'un nouveau schéma, vous pouvez spécifier le format d'encodage des données et d'autres paramètres.

Si vous souhaitez supprimer le schéma, mais que vous n'êtes pas sûr qu'il existe, vous devez exécuter la commande :

DROP SCHEMA IF EXIST Name;

Vous verrez souvent ces commandes dans des fichiers avec des sauvegardes de différentes bases de données, c'est pourquoi je les apporte ici.

Sélection du schéma actuel

Si vous avez beaucoup de schémas dans votre SGBD, il peut facilement arriver que différents schémas aient les mêmes tables. Pour éviter toute confusion, vous pouvez faire deux choses :

• Mettez toujours le nom du schéma avant le nom de la table
• Spécifier le schéma par défaut

Écrivons une requête qui sélectionnera les données de la table utilisateur , qui se trouve dans le schéma de test . Cela ressemblera à ceci :

SELECT * FROM test.user;

C'est tout simplement indispensable si vous avez besoin de joindre (JOIN) plusieurs tables de différents schémas en une seule requête.

Soit dit en passant, dans le langage Java, nous faisons souvent quelque chose de similaire : si dans le code nous devons utiliser des classes portant le même nom dans différents packages, nous ajoutons le nom du package avant le nom de la classe.

La deuxième méthode consiste à spécifier le schéma par défaut . Si la requête spécifie un nom de table mais pas de schéma, le schéma par défaut est utilisé. Pour ce faire, utilisez l'instruction USE :

USE name - schemes;

Réécrivons la requête précédente en utilisant l'instruction USE :

USE test;
SELECT * FROM user;

Création d'une vue

En plus des tables avec des données réelles, SQL vous permet de stocker quelque chose comme des tables virtuelles, où les données sont extraites de tables réelles. Ces tables virtuelles sont appelées VIEW.

Une telle table ne peut pas stocker de données réelles et, à chaque accès, elle extrait des données de tables réelles. Le contenu d'une telle VUE est spécifié à l'aide d'une requête SQL.

Vous pouvez créer une VIEW à partir de n'importe quelle requête SELECT avec une commande telle que :

CREATE VIEW Name AS
SELECT-request;

CREATE VIEW public_employee AS
SELECT id, name FROM employee

Dans l'exemple ci-dessus, notre table (VIEW) public_employee ne contiendra que les identifiants des employés et leurs noms, mais pas d'informations sur leur salaire. Vous pouvez utiliser de telles vues au même endroit que de vraies tables.

Pourquoi les vues sont-elles nécessaires ? Ils présentent plusieurs avantages :

Contrôle flexible de l'accès à l'information . Vous pouvez donner à certains utilisateurs l'accès uniquement à VIEW, mais pas l'accès aux tables. Et dans View, ne retirez que les informations publiques des tables. De plus, si de nouvelles colonnes contenant des informations importantes sont ajoutées aux tables à l'avenir, elles n'entreront pas accidentellement dans la vue.

Dénormalisation des données . Pour faciliter le stockage, les données sont souvent divisées en centaines et milliers de tables, mais il n'est pas très pratique pour une personne ordinaire de travailler avec de telles données - vous devez écrire des requêtes trop complexes. Avec View, vous pouvez créer des tables virtuelles qui affichent les données de dizaines de tables différentes dans une seule table.

Polymorphisme et Encapsulation . Vous pouvez modifier les structures de votre base de données. Dans le même temps, les utilisateurs du programme qui travaillent avec vos vues ne devineront pas que quelque chose a changé. Et il ne sera pas nécessaire de réécrire le code des programmes qui ont accès à View. Vous aurez juste besoin de modifier le script SQL lié à VIEW.

Lecture seule . View ne peut être défini qu'avec une requête SELECT, donc travailler avec View ne peut en aucun cas modifier les données dans des tables réelles. Soit dit en passant, c'est un autre avantage en faveur de la mise en cache des requêtes. Mais plus à ce sujet la prochaine fois.