Funcionarios

Employés

Système de gestion des employés d'une entreprise.

Conseils

Ce qui a été développé

Le projet a été développé à l'aide d'ASP.NET pour le développement d'applications et SQL Server en tant que base de données de stockage. Un enregistrement des employés (personne + cargaison) a été effectué où il est possible de faire les 4 actions des normes CRUD. Lire, créer, modifier et supprimer. De plus, l'option de recalcul des salaires a également été mise en œuvre, où la base de données rend la relation à nouveau entre la personne et le bureau, peuplant le tableau de la personne_salary dicté dans la description du test.

Comment exécuter l'application

Dans les officiels / sauvegarde / possède un fichier de sauvegarde SQL Server que j'ai utilisé avec toutes les procédures utilisées et les données déjà saisies. Par conséquent, il vous suffit de faire une restauration bancaire.

Remarque : Après la restauration, vous devez modifier la chaîne de connexion présente dans la classe des employés dans le fichier de l'employé.aspx.cs. Changer par la chaîne de connexion de votre machine.

Après avoir configuré la base de données, ouvrez la solution à un éditeur de code de votre choix (j'ai utilisé Visual Studio) et exécutez l'application.

Procédures de stockage

Pour faciliter la visualisation des procédures utilisées dans l'application, je mets leurs fichiers de création dans les employés / SQL /.

Objectifs

• Créez la base de données avec les données passées
• Créer le projet de base
• Stocker la procédure de la population du tableau Person_salario
• Table de la personne populaire_salario
• Stocker la procédure de création de personnes
• Stocker la procédure de mise à jour de la personne
• Stocker la procédure d'exclusion de la personne
• Procédure de stockage pour répertorier les personnes et les salaires
• Stockez la procédure de liste des positions
• Stocker la procédure de sélection des personnes
• Page d'inscription des personnes et des sceaux
• Routine de création de la personne
• Routine de mise à jour de la personne
• Routine d'exclusion de personne
• Routine de nettoyage sur le terrain
• Confirmation d'action apparaît
• Calculer / recalculer le salaire de la routine

Considérations sur l'architecture

Pendant le développement, j'ai trouvé des choses étranges sur l'architecture proposée. Principalement en relation avec la base de données.

Il est dit dans la description du test qui consiste à créer un tableau appelé pessoa_salario qui ferait la connexion de la table de personne avec position. Cependant, l'existence de ce tableau n'est pas nécessaire. Pour la nécessité de créer une table intermédiaire, n'est nécessaire que lorsqu'il existe une relation de beaucoup pour beaucoup entre les deux tables analysées. Ce qui n'est pas le cas entre la personne et le bureau. Après tout, une personne ne peut être en position qu'à la fois et il y a donc un champ appelé position_id en personne. Et à partir de cela, la manière unique du tableau de position existe déjà et, par conséquent, il est déjà possible d'accéder à la position et au salaire de cette personne, sans avoir besoin de créer un tableau pour ce faire.

La façon dont vous êtes décrit dans le test, il y a un problème en double dans la banque. Qui en plus d'être mauvais architectural, car il peut générer une incohérence dans ces données à un moment donné, une "correction" de ceci était également nécessaire dans l'application qui était la création du bouton de recalcul salarial. Après tout, si la valeur du salaire d'un stagiaire à l'avenir, par exemple, modifiait, le tableau de position aurait la valeur mise à jour, mais le tableau de vente Sanal aurait toujours l'ancienne valeur (problème d'incohérence des données) et il serait nécessaire d'aller manuellement sur l'écran de l'employé et de déclencher l'action de recalcul du salaire. Ce qui n'aurait pas besoin d'être fait s'il n'y avait pas de table de personne, car en plus d'avoir seulement ces données en un seul endroit, empêchant les incohérences, la consultation prendrait correctement la valeur. À la fois avant de modifier le montant du salaire et après.

La preuve de cela consiste à analyser les consultations que les deux architectures génèrent.

Il s'agit de la consultation pour retourner toutes les données de la personne, du fret et de la personne_salary utilisées dans la liste par les propositions d'architecture:

 SELECT p . ID , p . Nome as Pessoa, Cidade, Email, CEP, Endereco, Pais, Usuario, Telefone, Data_Nascimento, c . Nome as Cargo, ps . Salario FROM Pessoa as p 
	INNER JOIN Pessoa_Salario as ps on p . ID = ps . Pessoa_ID
	INNER JOIN Cargo as c on p . Cargo_ID = c . ID

Et cela a la même fonction que la consultation ci-dessus, mais implique uniquement la personne et le bureau et renvoie exactement les mêmes données d'une manière plus simple et plus optimisée:

 SELECT p . ID , p . Nome as Pessoa, Cidade, Email, CEP, Endereco, Pais, Usuario, Telefone, Data_Nascimento, c . Nome as Cargo, c . Salario FROM Pessoa as p 
	INNER JOIN Cargo as c on p . Cargo_ID = c . ID

Remarque : Mes propositions de solution ont été développées à l'aide de l'architecture proposée. Ce commentaire était juste pour montrer la façon dont je l'ai trouvé le plus intéressant et optimisé par l'architecture.