db design question

[JustMax]

Там relationship one-to-many, то есть у одной task может быть несколько predecessors. То есть тут в одну таблицу не получится.
Сабина

Если successor все равно один то просто меняем местами (т.е не ребенок хранит ссылку на родителя а родитель на дитя)
select * from task connect by prior parentid = childid start with childid = ?
[/b]

[Sabina]

Это Оракл - стандартные иерархические запросы. Я то думал что вы с Oracle работаете .В MS SQL , насколько я знаю , с этим пока тяжко.

Это уж точно. "Все смешалось - кони, люди". Оракл я на учебном проекте пользую, а на работе у нас SQL server. Мне наверно надо пояснять, чтобы в заблуждение не вводить

Сабина

[Dedal]

Я бы добавил одну колонку predcessor в таблицу ProjectTask и сделал эту колонку FK на TaskID. Тогда вторая таблица ProjectTaskPredcessorстанет не нужна.Получится обычная иерархия.

Там relationship one-to-many, то есть у одной task может быть несколько predecessors. То есть тут в одну таблицу не получится.

Сабина

Тогда приведенная схема работать не будет, первичным ключом все равно назначен только taskID. Надо заводить искусственный ПК для этой таблицы.

[Sabina]

Тогда приведенная схема работать не будет, первичным ключом все равно назначен только taskID. Надо заводить искусственный ПК для этой таблицы.

да, я уже ввела pairID, просто на рисунке не исправила, sorry.

Сабина

[Lazy44]

Тогда приведенная схема работать не будет, первичным ключом все равно назначен только taskID. Надо заводить искусственный ПК для этой таблицы.

да, я уже ввела pairID, просто на рисунке не исправила, sorry.

Сабина

Лучше сделайте превичный ключ на таблице ProjectTaskPredcessor composite - taskid, predcessor. И оба дожны быть FK на ProjectTask (TaskId)

[Sabina]

Лучше сделайте превичный ключ на таблице ProjectTaskPredcessor composite - taskid, predcessor. И оба дожны быть FK на ProjectTask (TaskId)

FK конечно есть, а вот PK из комбинации двух как-то не догадалась сделать. Ну да уж ладно, написала уже все и протестировала, переделывать из-за одного ключа неохота.
А чем это лучше? Память буду экономить ?

Сабина

[Sabina]

Еще вот такой вопрос, правда не по дизайну, сорри.

Я обратила внимание, что в нашем приложении гоняют туда-сюда целые объекты, даже когда нужны всего 2-3 аттрибута.

Скажем когда я добавляла в project сервис методы для этой новой таблицы, обратила внимание, что в соседнем методе getProjectTasks(int userID, Project proj) методу передается весь проект, хотя для запроса мне нужен только projectID.

Ну то есть запрос там будет выборкой из user function, нечто вроде

SELECT pt.taskID, pt.taskName
FROM ProjectTask pt (nolock)
INNER JOIN ProjectMember pm (nolock)
ON pt.projectID = pm.projectID
WHERE pt.projectID = @projectID AND
pm.userID = @userID

Не пойму зачем передают весь проект? Не проще ли было бы сделать getProjectTasks(int userID, int projectID) ?

Это все равно, если я в метод getProjectTaskPredecessors(int projectID) буду передавать не projectID, а весь объект Project...

Сабина

[testuser]

Ну то есть запрос там будет выборкой из user function, нечто вроде

SELECT pt.taskID, pt.taskName
FROM ProjectTask pt (nolock)
INNER JOIN ProjectMember pm (nolock)
ON pt.projectID = pm.projectID
WHERE pt.projectID = @projectID AND
pm.userID = @userID

Не пойму зачем передают весь проект? Не проще ли было бы сделать getProjectTasks(int userID, int projectID) ?

Это все равно, если я в метод getProjectTaskPredecessors(int projectID) буду передавать не projectID, а весь объект Project...

Сабина

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