|
|
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
По мотивам обсуждения предыдущей темы я нарисовал диаграмму, представленную ниже. Суть в том, что у каждой задачи есть тип. Например "Побелка" и "Покраска". Для каждого типа есть свой набор статусов. Например для побелки - "Ошкурено", "Побелено" а для покраски - "Нанесли первый слой", "Нанесли второй слой", "Сохнет", "Готово". TaskEntry - пусть для простоты это будут разные стены или разные здания. Всё прекрасно концептуально, но вот в реализации в таблицу TaskEntry попадает внешний ключ из таблицы EntryStatus. Хотелось бы чтобы туда попадало только поле Code из таблицы EntryStatus. Но это, как я понимаю, невозможно, потому что PK у EntryStatus - составной. В каком месте ДНК у меня ошибка? Как избежать дублирования информации при вынесении типа в отдельную сущьность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 12:44 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
Вот физическая модель для наглядности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 12:47 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
А зачем? Т.е. сделать PK у EntryStatus - не составной - без проблем, но засада в другом - TaskEntry по бизнесу вроде должен иметь только те статусы, какие имеет его TaskType . А это ограничение ("тот же самый") наборот требует мигрирования ключа TaskType (возможно AK, а не PK) в три другие таблицы. Разбиралось на форуме, и вот еще . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 15:43 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
AmdeiВот физическая модель для наглядностиТут есть несколько вариантов: 1) Использовать составные ключи (естественные), возлагать логику правильности присвоения статусов - на constraint-ы. (Это как предлагает сделать "ModelR") 2) Использовать суррогатные ключи, логику правильности присвоения статусов возлагать на приложение. у каждого метода - свои сторонники, свои плюсы, свои минусы. К приведенной схеме могу добавить, что кроме указанной схемы еще используют ЕДИНЫЕ СТАТУСЫ. т.е. имеется отдельная таблица СТАТУСЫ (или состояния) в которой перечесляются все статусы, которые есть в системе. Далее в связующей таблице конкретные статусы связываются с типами объектов. Таким способом для разных типов объектов можно получить одинаковый статус. Например: "Работы завершены", "Ожидание оплаты" итп. соответственно бизнес-логика может привязываться к этому единому статусу - если ей не важно какой именно тип объекта имеет этот статус. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 21:11 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
Объясните пожалуйста, что такое Task? По концептуальной модели, это нечто, связанное с TaskType 0 к 1. Кроме того, получается, что несколько записей в TaskEntry могут ссылаться на одну и ту же запись в Task. Т.е. одна Task может объединять, скажем, TaskEntry со статусом "Нанесли второй слой" и TaskEntry со статусом "Ошкурено" - разного типа. Если это правильно, то зачем связь между Task и TaskType? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 00:50 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
PWinterОбъясните пожалуйста, что такое Task? По концептуальной модели, это нечто, связанное с TaskType 0 к 1. Там фигня нарисована на модели - ошибку допустил при подготовке примера. TaskType -> Task - один ко многим должно быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2007, 22:33 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
Не пойму, а зачем вы вынесли EntryStatus в отдельную таблицу? Ведь по логике Статус задачи является ее атрибутом. Или это сделано, что-бы у текущей задачи вести нечто вроде журнала состояний? Тогда где временные аттрибуты для этого журнала? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2007, 23:43 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
СтрадалецъНе пойму, а зачем вы вынесли EntryStatus в отдельную таблицу? Ведь по логике Статус задачи является ее атрибутом. Или это сделано, что-бы у текущей задачи вести нечто вроде журнала состояний? Тогда где временные аттрибуты для этого журнала?Там тоже один-ко-многим должен был быть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2007, 00:26 |
|
||
|
Как избежать дублирования информации при вынесении типа в отдельную сущьность?
|
|||
|---|---|---|---|
|
#18+
Code из таблицы EntryStatuses является уникальным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2007, 11:52 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35017299&tid=1544116]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
172ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 460ms |

| 0 / 0 |
