Funcionarios
1.0.0
Sistem manajemen karyawan perusahaan.
Proyek ini dikembangkan menggunakan ASP.NET untuk pengembangan aplikasi dan SQL Server sebagai database penyimpanan. Pendaftaran karyawan (orang + kargo) dibuat di tempat yang dimungkinkan untuk membuat 4 tindakan standar CRUD. Baca, Buat, Edit, dan Hapus. Selain itu, opsi penghitungan ulang gaji juga diimplementasikan, di mana database membuat hubungan lagi antara orang dan kantor, mengisi tabel orang yang ditentukan dalam deskripsi tes.
Di pejabat/ cadangan/ memiliki file cadangan SQL Server yang saya gunakan dengan semua prosedur yang digunakan dan data sudah dimasukkan. Karena itu, Anda hanya perlu melakukan pemulihan bank.
Catatan : Setelah melakukan pemulihan, Anda perlu mengubah string koneksi yang ada di kelas karyawan dalam file karyawan.aspx.cs. Mengubah dengan string koneksi mesin Anda.
Setelah mengkonfigurasi database, buka solusi untuk beberapa editor kode pilihan Anda (saya menggunakan Visual Studio) dan jalankan aplikasi.
Untuk membuatnya lebih mudah untuk melihat prosedur yang digunakan dalam aplikasi, saya meletakkan file kreasi mereka di karyawan/SQLS/.
Selama pengembangan saya menemukan beberapa hal aneh tentang arsitektur yang diusulkan. Terutama dalam kaitannya dengan database.
Dikatakan dalam deskripsi tes yaitu membuat tabel yang disebut Pessoa_Salario yang akan membuat koneksi tabel orang dengan posisi. Namun, keberadaan tabel ini tidak diperlukan. Karena kebutuhan untuk membuat tabel perantara hanya diperlukan ketika ada hubungan banyak bagi banyak orang di antara dua tabel yang dianalisis. Yang tidak terjadi antara orang dan kantor. Setelah semua orang hanya bisa berada dalam posisi pada suatu waktu dan jadi ada satu bidang yang disebut Position_id secara langsung. Dan dari ini, cara unik dari tabel posisi sudah ada dan akibatnya sudah mungkin untuk mengakses posisi dan gaji orang itu, tanpa perlu membuat tabel untuk melakukan ini.
Cara Anda dijelaskan dalam tes, ada masalah duplikat di bank. Yang selain salah secara arsitektur, karena dapat menghasilkan ketidakkonsistenan dalam data ini di beberapa titik, "koreksi" ini juga diperlukan dalam aplikasi yang merupakan penciptaan tombol penghitungan ulang gaji. Lagi pula jika nilai gaji magang di masa depan, misalnya, berubah, tabel posisi akan memperbarui nilai, tetapi tabel penjualan sanal masih akan memiliki nilai lama (masalah inkonsistensi data) dan perlu untuk menggunakan layar karyawan secara manual dan memicu tindakan pengembalian perhitungan gaji. Yang tidak perlu dilakukan jika tidak ada tabel orang, karena selain hanya memiliki data ini di satu tempat, mencegah ketidakkonsistenan, konsultasi akan mengambil nilainya dengan benar. Keduanya sebelum memodifikasi jumlah gaji dan sesudahnya.
Bukti dari ini adalah untuk menganalisis konsultasi yang dihasilkan oleh kedua arsitektur.
Ini adalah konsultasi untuk mengembalikan semua data orang, kargo, dan orang yang digunakan dalam daftar oleh proposal arsitektur:
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 . IDDan ini memiliki fungsi yang sama dengan konsultasi di atas, tetapi hanya melibatkan orang dan kantor dan mengembalikan data yang persis sama dengan cara yang lebih sederhana dan lebih dioptimalkan:
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 . IDCatatan : Proposal solusi saya dikembangkan menggunakan arsitektur yang diusulkan. Komentar ini hanya untuk menunjukkan cara saya menemukan itu paling menarik dan dioptimalkan oleh arsitektur.
