Запрос моделирования / проектирования класса

Вы ничего не упомянули о требованиях к производительности или использованию, поэтому я отвечу в общих чертах и ​​обновлю свой ответ, если вам понадобится более конкретная информация. Для таблиц БД я предлагаю общий нормализованный подход в этом направлении.

tblProject
    ProjectID
    ProjectDescription etc.

tblTask
    TaskID
    TaskDescription etc.

tblEmployee
    EmployeeID
    Name etc.

tblProjectTasks
    ProjectTasksID
    ProjectID
    TaskID

tblTaskAssignments
    TaskAssignmentsID
    TaskID
    EmployeeID

Другой допустимый подход - создать таблицу, определяющую проект, и другую таблицу, чтобы определить список проектов. То же самое касается задач и сотрудников. В реальном приложении эти сущности обычно хорошо определяются в более общих таблицах, так же как вы можете разработать класс, содержащий другие четко определенные объекты. Например, вы не упомянули ресурсы проекта, кроме сотрудника. Эти ресурсы могут быть представлены в схеме, которая определяет тип ресурса, свойства ресурса и т. Д., А затем присоединяет ресурс к проекту и / или задаче.

Вы также можете создать таблицу, представляющую сотрудников проекта, но данные в ней будут избыточными, поскольку вы сможете найти сотрудников, назначенных проекту, путем объединения других таблиц. IMHO, такое дублирование будет оправдано только в том случае, если таблицы огромны и этот конкретный тип запроса используется очень часто. Но я бы все же сначала рассмотрел другие подходы.

Вы также спросили о занятиях. Трудно быть слишком конкретным без лучшего понимания своих целей. В типичном объектно-ориентированном дизайне классы должны четко представлять проект, задачу и сотрудника. Но вам нужно будет адаптировать это к вашим конкретным потребностям.

Я постараюсь ответить на ваши вопросы как можно более обобщенно и избегать повторения конкретных структур таблиц, как в предыдущих ответах. Вообще говоря, циклические отношения между вашими сущностями - это неплохо ... наоборот, они довольно распространены:

There are many Projects
Projects have Employees
Projects have Tasks
Employees are assigned some Tasks

В то время как у проекта есть сотрудники ... и у сотрудника также есть проект (или, возможно, несколько проектов, если сотрудник может работать над более чем одним проектом одновременно). С точки зрения базы данных, когда вы создаете внешний ключ, эта «круговая» связь существует независимо от того, хотите вы этого или нет.

Более важный вопрос, с концептуальной точки зрения, имеет ли значение, знает ли Сотрудник, частью какого проекта (проектов) он является? Хотя, вероятно, очень важно, чтобы проект знал, какие сотрудники над ним работают ... может быть не важно, чтобы Сотрудник знал, в каком проекте он работает. Это то, что называется «Навигация», и, в отличие от нашей структуры базы данных, мы МОЖЕТ контролировать это с помощью наших классов. Объект Project будет иметь коллекцию объектов Employee, но объект Employee не обязательно должен иметь свойство Project (или коллекцию проектов).

Я не могу дать вам готового ответа относительно судоходства. Обычно это субъективно и зависит от потребностей вашего бизнеса. Если бизнес, который вы моделируете, основан на концепции сотрудника, который знает, над какими проектами он работает, и эти знания важны для завершения процессов, которые будет выполнять ваша бизнес-логика ... тогда вам нужны эти круговые отношения. То же самое касается навигации между сотрудниками и задачами, проектами и задачами и т. Д.

начать с базы данных и работать оттуда. Мне нужна дополнительная информация, чтобы порекомендовать структуру классов. вы хотите / нужны предметы для сотрудников? или они будут собственностью проекта? и т.д..

Дизайн БД:

Projects
    ProjectID
    ProjectName...
    EmployeeID

Tasks
    TaskID
    ProjectID
    TaskName...
    EmployeeID

Employees
    EmployeeID
    EmployeeName...

Я бы сделал что-то вроде этого для дизайна базы данных:

    Create Table Projects
(
    ProjectID int Identity(1,1),
    ProjectName varchar(50) Primary Key NonClustered,
    OtherStuff varchar(255)
)
CREATE CLUSTERED INDEX IX_PROJECTS_ID ON dbo.Projects(ProjectID)

Create Table Employees
(
    EmployeeID int Identity(1,1),
    EmployeeName varchar(50) Primary Key NonClustered,
)
CREATE CLUSTERED INDEX IX_EMPLOYEES_ID ON dbo.Employees(EmployeeID)

Create Table ProjectEmployees
(
    ProjectID int,
    EmployeeID int,
    Constraint pk_ProjectEmpoyees Primary Key (ProjectID, EmployeeID)
)

Create Table Tasks
(
    TaskID int Identity(1,1),
    TaskName varchar(50) Primary Key NonClustered,
    AssignedEmployeeID int, --NOTE: assumes only 1 employee per task
    OtherStuff varchar(255)
)
CREATE CLUSTERED INDEX IX_TASKS_ID ON dbo.Tasks(TaskID)

Create Table TaskPrecedents
(
    TaskID int,
    PrecedentTaskID int,
    PrecedentType Char(2)   --Codes, you'll have to work these out
    Constraint pk_TaskPrecedents Primary Key (TaskID, PrecedentTaskID)
)