Добрый день!
Поделитесь опытом в решении такой задачи.
Есть таблица "Документы" и
"ИсторияДокумента"
id - ключ
docId - id документа
hDate - дата события
SessionId - вид события (поступил в рассмотрение, отложен, рассмотрен и т.д.)
Вот смущает меня такая структура, особенно в части такого события как "Отложен". Необходимо указать на какую дату перенесён документ, а эта структура не позволяет этого сделать. Подскажите пожалуйста как это дело исправить.
Спасибо.

Меня прокси не пускает. Можеш здесь запостить?

Программист-ЛюбительЧто толку постить каталог схем БД, все равно надо нужную выбирать и в нее проваливаться.
Спасибо, щаз с мобильника попробую.
А в рамках моего вопроса есть мнение? Я пока только до доп таблицы додумался, но как-то коряво это.

Bely SNiL Программист-ЛюбительЧто толку постить каталог схем БД, все равно надо нужную выбирать и в нее проваливаться.
Спасибо, щаз с мобильника попробую.
А в рамках моего вопроса есть мнение? Я пока только до доп таблицы додумался, но как-то коряво это.Есть мнение, что раз встал такой вопрос, то надо садиться с бизнес-пользователями и изучать предметную область.

Какие бывают еще заковыки в документах, что именно с ними делают.
Причем, надо разговаривать не с точки зрения "как вы работаете в программе", а "как вы делаете в реальности", с бумажными документами.

После того как будет получен достаточно полный список ВСЕХ необходимых доп. требований - нужно садиться и оценивать масштаб бедствия.

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

А если окажется, что это ЕДИНСТВЕННОЕ требование, то это совсем другое.
Дату, например, можно сохранять в дополнительном поле, которое просто добавить в таблицу "ИсторияДокумента" или в таблицу "Документы".

Исходим из утверждения что это требование единственное.
Доп. поле в этих таблицах - на мой взгляд коряво. Откладывать могут один документ из пяти и оставлять пустыми поля... ну не знаю как-то привык, чтобы все поля несли смысловую нагрузку, а для события "Рассмотрен" - для чего это поле? Хотя я профессионально разработкой не занимаюсь и спец. образования в этой области не имею, так что могу ошибаться.

Bely SNiLДоп. поле в этих таблицах - на мой взгляд коряво. Откладывать могут один документ из пяти и оставлять пустыми поля... ну не знаю как-то привык, чтобы все поля несли смысловую нагрузку, а для события "Рассмотрен" - для чего это поле?А, собственно, чего вы хотите? Дату где-то надо хранить.

Если хотите полностью нормализовать структуру своих данных - вводите доп таблицу из двух полей:
Первичный ключ (он же FK) + дата до которого отложено.
Не забываем про все издержки (индексы, JOIN-ы, проверки целостности и т.д.)

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

И в том и в другом подходе важно чувство меры, иначе получится просто плохая программа.

По какому пути пойдете вы - решайте сами.

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

GoffmanДа еще, по теме то, почему бы не сделать простое текстовое поле "Примечание", и юзеры при смене статуса пусть забивают туда хоть дату пересмотра, хоть номер служебки, все что посчитают нужным
Для некоторых отчётов эта дата необходима, выбирать из "Примечания" будет проблематично.

GoffmanКонечно если исходить из этих соображений, то логично было бы привязать доп. таблицу отношением 1:1 с полем "дата переноса", данные туда заносить только для строки со статусом "Отложен". Для другого состояния придумать другую табличку со своими аттрибутами, и т.д.
Но это дело вкуса, на практике мы ничего от этого не выигрываем, запросы усложнятся да и только.

Собственно поэтому и ступор - что доп. поле что таблица 1:1 теже яйца, только в профиль. Думал что-то другое есть :((