Funcionarios
1.0.0
Система управления сотрудниками компании.
Проект был разработан с использованием ASP.NET для разработки приложений и SQL Server в качестве базы данных хранения. Была проведена регистрация сотрудников (человек + груз), где можно сделать 4 действия стандартов CRUD. Читать, создавать, редактировать и удалять. Кроме того, был также реализован вариант пересчета заработной платы, когда база данных снова делает отношения между человеком и офисом, заполняя таблицу Person_salary, продиктованную в описании теста.
У чиновников/ резервного копирования/ имеет файл резервного копирования SQL Server, который я использовал со всеми используемыми процедурами и уже введенными данными. Поэтому вам просто нужно сделать банк восстановление.
ПРИМЕЧАНИЕ . После восстановления вам необходимо изменить строку подключения, присутствующую в классе сотрудников в файле сотрудников.aspx.cs. Изменение на строке подключения вашей машины.
После настройки базы данных откройте решение для некоторого редактора кода по вашему выбору (я использовал Visual Studio) и запустите приложение.
Чтобы облегчить просмотр процедур, используемых в приложении, я помещаю их файлы создания в сотрудниках/SQLS/.
Во время разработки я нашел несколько странных вещей о предлагаемой архитектуре. В основном по отношению к базе данных.
В описании теста говорится, что для создания таблицы под названием Pesoa_salario, которая сделает связь с таблицей человека с позицией. Однако существование этой таблицы не требуется. Для необходимости создания промежуточной таблицы необходимо только тогда, когда существует взаимосвязь многих для многих между двумя проанализированными таблицами. Что не так между человеком и офисом. В конце концов, один человек может находиться только в положении за раз, и поэтому есть одно поле, называемое Position_id лично. И из этого уникальный способ таблицы позиций уже существует, и, следовательно, уже можно получить доступ к позиции и зарплате этого человека без необходимости создания таблицы для этого.
То, как вы описаны в тесте, в банке есть повторяющаяся проблема. Что, помимо того, что в какой -то момент он может быть неправильным, так как это может привести к несоответствию в этих данных, «коррекция» этого также была необходима в приложении, которое было созданием кнопки пересчета заработной платы. В конце концов, если стоимость зарплаты стажера в будущем, например, изменена, таблица позиций будет обновлена, но таблица продажи санала все равно будет иметь старую стоимость (проблема несоответствия данных), и было бы необходимо перейти вручную на экране сотрудника и запустить действие по получению заработной платы. Что не нужно было бы делать, если бы не было таблицы человека, потому что, помимо наличия только этих данных в одном месте, предотвращая несоответствия, консультация будет правильно принимать ценность. Оба до изменения суммы заработной платы и после.
Доказательством этого является проанализировать консультации, которые генерируют две архитектуры.
Это консультация по возвращению всех данных о человеке, грузе и 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Примечание . Мои предложения решения были разработаны с использованием предлагаемой архитектуры. Этот комментарий был просто для того, чтобы показать, как я нашел его наиболее интересным и оптимизированным по архитектуре.
