db design question

Sabina · Post by **Sabina** » 27 Feb 2004 18:59

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

Колонка predecessor - это те же taskID. То есть таблица ProjectTaskPredecessor определяет какие задачи должны быть выполнены (predecessors) до того как сама задача (taskID) начнет выполняться.
Получается 2 foreign keys из этой таблицы и оба к taskID таблицы ProjectTask.

По моему мнению введение такой таблицы в схему внесет кучу проблем из-за этих двух foreign keys, ведь весь софт написан без учета этих constraints, то есть он начнет валиться то там то здесь, а projectTask - это основная таблица по которой вообще загружается само приложение для данного userProfile ...

Вопроса два:
1) Согласны ли вы со мной?
2) Если да, не подкинете еще аргументов в защиту моей точки зрения.

Спасибо,
Сабина

testuser · Post by **testuser** » 27 Feb 2004 19:43

Потенциальные проблемы могут возникнуть, если будет зацикливание. При Insert или Uodate нужно проверять, чтобы этого зацикливания не было.

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

Sabina · Post by **Sabina** » 27 Feb 2004 19:51

testuser wrote:Потенциальные проблемы могут возникнуть, если будет зацикливание. При Insert или Uodate нужно проверять, чтобы этого зацикливания не было.

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

А вот скажем такая ситуация. Эта таблица явно введена с целью определить какие-нибуль business rules, типа никто не может начать работать над проектом XX до тех пор, пока все predecessors не завершены.
А приложение работает так, что при каждом запуске, идет чтение из ProjectTask, а может быть и task re-assignment. А вдруг эти business rules будут держать таблицу?

Just a thought,
Sabina

testuser · Post by **testuser** » 27 Feb 2004 20:05

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

testuser · Post by **testuser** » 27 Feb 2004 20:11

Sabina wrote:А вот скажем такая ситуация. Эта таблица явно введена с целью определить какие-нибуль business rules, типа никто не может начать работать над проектом XX до тех пор, пока все predecessors не завершены.
А приложение работает так, что при каждом запуске, идет чтение из ProjectTask, а может быть и task re-assignment. А вдруг эти business rules будут держать таблицу?

Just a thought,
Sabina

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

JustMax · Post by **JustMax** » 27 Feb 2004 20:23

testuser wrote:
Sabina wrote:А вот скажем такая ситуация. Эта таблица явно введена с целью определить какие-нибуль business rules, типа никто не может начать работать над проектом XX до тех пор, пока все predecessors не завершены.
А приложение работает так, что при каждом запуске, идет чтение из ProjectTask, а может быть и task re-assignment. А вдруг эти business rules будут держать таблицу?

Just a thought,
Sabina

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

Я бы сделал еще одну колонку с fk на parent id а потом

select * from task connect by prior childid = parentid start with ?

и вы получите сразу всю иерархическую цепочку задач.
Причем если нужно отслеживать на незацикливаемость и уникальность прохода по таскам - могу подарить триггер - котроый это отслеживает

Sabina · Post by **Sabina** » 27 Feb 2004 20:30

testuser wrote:Ну так бизнес-рулз будут скорее всего на чтение, а не на запись, держать таблицу не должны. Т.е. в начале проверяем, можно ли работать над проектом, если да - отдаем.
У меня в одном проекте была подобная система с бухгалтерскими счетами.
Вначале мы имели корень - валюту. Потом разные счета, которые могут иметь в себе либо дерево счетов, либо отдельный счет. Работало все прекрасно, проблем не было.

Спасибо, развеяли мои сомнения. А то я уже начала было нервничать, что опять очередной грех на свою душу повесила. Не люблю я эти все db schema changes, особенно после нормально работающей беты. А может так оно и происходит в большинстве случаев

Сабина

Sabina · Post by **Sabina** » 27 Feb 2004 20:35

JustMax wrote:Я бы сделал еще одну колонку с fk на parent id а потом

В смысле внутри самой таблицы Predecessor fk c taskID на predecessor?

JustMax wrote:select * from task connect by prior childid = parentid start with ?
и вы получите сразу всю иерархическую цепочку задач.

А это что за синтаксис? Не нашла я такого "connect" в Transact_SQL :oops:

JustMax wrote:Причем если нужно отслеживать на незацикливаемость и уникальность прохода по таскам - могу подарить триггер - котроый это отслеживает

Ну как я могу отказаться от такого сооблазнительного предложения :lol:

nsabinaЭТsbcglobalДОТnet

Сабина

testuser · Post by **testuser** » 27 Feb 2004 21:05

Sabina wrote:Спасибо, развеяли мои сомнения. А то я уже начала было нервничать, что опять очередной грех на свою душу повесила. Не люблю я эти все db schema changes, особенно после нормально работающей беты. А может так оно и происходит в большинстве случаев

Сабина

Рефакторинг как правило приводит к лучшему дизайну и более надежно работающему приложению. Так что переделок не нужно бояться, главное чтобы они были в правильном направлении.

Strannik223 · Post by **Strannik223** » 27 Feb 2004 22:21

testuser wrote:Рефакторинг как правило приводит к лучшему дизайну и более надежно работающему приложению. Так что переделок не нужно бояться, главное чтобы они были в правильном направлении.

Ха! Не путайте рефакторинг с изменением функционала
Обычно изменение даже одного столбца в базе приводит к болезненному перелопачиванию stored procedures

Lazy44 · Post by **Lazy44** » 27 Feb 2004 22:22

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

Strannik223 · Post by **Strannik223** » 27 Feb 2004 22:29

testuser wrote:да, кстати, это все можно сделать в одной таблице, predecessor как отдельное поле.

А это как раз может поломать приложение
А в схеме с 2-мя таблицами приложение будет продолжать работать по мере добавления функциональности
Но с точки зрения дизайна лучше конечно одна таблица

Sabina · Post by **Sabina** » 27 Feb 2004 22:32

Strannik223 wrote:
testuser wrote:Рефакторинг как правило приводит к лучшему дизайну и более надежно работающему приложению. Так что переделок не нужно бояться, главное чтобы они были в правильном направлении.

Ха! Не путайте рефакторинг с изменением функционала
Обычно изменение даже одного столбца в базе приводит к болезненному перелопачиванию stored procedures

Вот-вот Strannik, потому и не люблю все эти "моча в голову ударила базу поменять", особенно по нескольку раз в неделю. "Сразу надо было думать" (С)
С точки зрения процедур, наверное хорошо, что это все в отдельной таблице. Чтобы если что пойдет не так, убирать легче было.

Сабина

Sabina · Post by **Sabina** » 27 Feb 2004 22:33

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

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

Сабина

JustMax · Post by **JustMax** » 28 Feb 2004 00:39

Sabina wrote:В смысле внутри самой таблицы Predecessor fk c taskID на predecessor?

Yep, ето работает только в том случае если у вас отношения One to Many, Many to One. Many to Many только в отдельную таблицу.

Sabina wrote:А это что за синтаксис? Не нашла я такого "connect" в Transact_SQL

Это Оракл - стандартные иерархические запросы. Я то думал что вы с Oracle работаете :oops:

.В MS SQL , насколько я знаю , с этим пока тяжко.

JustMax wrote:Причем если нужно отслеживать на незацикливаемость и уникальность прохода по таскам - могу подарить триггер - котроый это отслеживает

Sabina wrote:Ну как я могу отказаться от такого сооблазнительного предложения
nsabinaЭТsbcglobalДОТnet

Он полностью основан на фишках оракла - plsql tables, иерархические запросы. Если все равно интересно как это в Оракле делаеться - в понедельник вышлю заказным письмом