Funcionarios
1.0.0
会社の従業員管理システム。
このプロジェクトは、ASP.NETを使用してアプリケーション開発とSQL Serverをストレージデータベースとして開発しました。従業員（人 +貨物）の登録が行われ、CRUD基準の4つのアクションを作成することができる場合に行われました。読み取り、作成、編集、削除。さらに、給与の再計算オプションも実装されました。ここでは、データベースが人とオフィスの間の関係を再び行い、テストの説明に記載されている人物の表に定義されています。
役人/バックアップ/には、使用されているすべての手順と既に入力されたデータで使用したSQL Serverバックアップファイルがあります。したがって、銀行を復元するだけです。
注：復元を実行した後、従業員file.aspx.cs内の従業員クラスに存在する接続文字列を変更する必要があります。マシンの接続文字列によって変更されます。
データベースを構成した後、選択したコードエディター（Visual Studioを使用しました）にソリューションを開き、アプリケーションを実行します。
アプリケーションで使用されている手順を簡単に表示できるようにするために、作成ファイルを従業員/SQLS/に配置します。
開発中、私は提案されたアーキテクチャについていくつかの奇妙なことを見つけました。主にデータベースに関連して。
テストの説明では、Pessoa_Salarioというテーブルを作成することで、Person TableとPositionの接続を作成することが言われています。ただし、このテーブルの存在は必要ありません。分析された2つのテーブルの間に多くの人が多くの関係がある場合にのみ、中間テーブルを作成する必要があります。これは、人とオフィスの間ではそうではありません。結局のところ、一度にしか位置にいることができるので、Position_Idと呼ばれる1つのフィールドが直接あります。そしてこのことから、ポジションテーブルのユニークな方法がすでに存在しているため、これを行うためのテーブルを作成する必要なく、その人のポジションと給与にアクセスすることがすでに可能です。
テストで説明する方法では、銀行に重複する問題があります。それは、間違っていることに加えて、ある時点でこれらのデータの矛盾を生成できるため、給与の再計算ボタンの作成であるアプリケーションでもこれの「修正」も必要でした。結局のところ、たとえば将来のインターンの給与の価値が変更された場合、位置テーブルに値が更新されますが、SANALセールテーブルにはまだ古い値（データの矛盾の問題）があり、従業員の画面に手動で移動し、給与の再計算措置をトリガーする必要があります。人のテーブルがなかった場合は、これを行う必要はありません。なぜなら、このデータのみを単一の場所に持っているだけでなく、矛盾を妨げる以外に、相談は価値を正しく取るからです。給与額を変更する前と後に変更する前に。
これの証明は、2つのアーキテクチャが生成する協議を分析することです。
これは、アーキテクチャの提案によってリストで使用されている人、貨物、Person_Salaryのすべてのデータを返品するための相談です。
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これは上記の相談と同じ機能を持っていますが、個人とオフィスのみを含み、よりシンプルで最適化された方法でまったく同じデータを返します。
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注：私のソリューション提案は、提案されたアーキテクチャを使用して開発されました。このコメントは、私がそれが最も興味深く、アーキテクチャによって最適化されたと感じた方法を示すためだけでした。
