ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / сохранение истории ...
14 сообщений из 14, страница 1 из 1
сохранение истории ...
    #32047521
Sanek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sanek
Участник
Есть интересный вопросик, который меня давно мучает ...
Как можно сохранить историю изменения определенного поля ....
ну наверно неправильно я сказал , скажем так :
есть человек (записанный в базе), так вот ФИО его Иванов Иван Иваныч, прошло время и звать его стали Иванов Иван Петрович ... вроде все просто ... если строить отчет с его присутствием, то тогда получается, что в определенный момент времени он имеет одно отчество , но если строить тот же отчет , но за период времени (вовремя которого он изменил отчество), то тогда их будет два !
как из такой ситуации можно выйти ?
Кто что может посоветовать ?
...
Рейтинг: 0 / 0
02.09.2002, 16:35:02
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047529
Фотография Maxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxx
Участник
Я просто веду таблицу - журнал,для тех данных изменение которых может повлеч за собой какието последствия (типа изменнения в расчетах),во избежание дублей по смыслу и т.д. и т.п.
...
Рейтинг: 0 / 0
02.09.2002, 16:55:40
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047532
Sanek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sanek
Участник
Ну замечательно , теперь строим отчет, о том, как этот чувак получал зарплату ... отчество то какое писать ?
...
Рейтинг: 0 / 0
02.09.2002, 17:09:04
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047549
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
на дату отчета....
у меня примерно так...
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
create table [person] (
  [id] uniqueidentifier  not null default (newid()),
  [begindate] smalldatetime not null default('19000101'),  -- 
 
  [enddate] smalldatetime null default (null),
  [name1] varchar( 50 ) not null,
  [name2] varchar( 50 ) not null,
  [name3] varchar( 50 ) not null
CONSTRAINT [UPKCL_person] PRIMARY KEY  CLUSTERED 
	( [id],[begindate],[enddate] )
)

актуальный ...
Код: plaintext
1.
2.
select [id],[name1],[name2],[name3]
from [person]
where isnull([enddate])

и т.д.
...
Рейтинг: 0 / 0
02.09.2002, 17:49:48
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047601
Sergey Vinogradov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Vinogradov
Участник
Простой вариант истории.
Практически как у MiCe, только DateEnd у последнего состояния равна не NULL, а некой DateMax.
ИМХО так проще добывать состояние на заданную дату.
...
Рейтинг: 0 / 0
03.09.2002, 05:12:06
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047608
Dominic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dominic
Участник
Есть интересный вопросик, который меня давно мучает ...
А нас-то как мучит! На нашем производстве (энергетика) во многих системах требуется хранить ответственного за изменение данных - даже когда человек уволен, меняет фамилию и т.д. Дебатируем пока с системными администраторами... Хочется применить системный подход для всех приложений (пример MiCe все же годится как частный случай в пределах одного приложения). Я (разработчик) предлагаю хранить в записи идентификатор доменной учетной записи, в связи с чем при увольнении сотрудника его учетная запись не удаляется из домена, а делается Disabled, при изменении ФИО создается новая учетная запись, предыдущая не удаляется и делается Disabled. При таком решении БД истории пользователей становится БД активного каталога. Технократичное решение, короче, но - возможно в будущем.
Пока же я пошел на денормализацию данных и в структурах данных, требующих ретроспективы, в записи храню не идентификатор пользователя, а его символьное ФИО; содержимое этого поля поддерживается тригером вставки/изменения. При объемах ~500 тыс. записей - терпимо.
...
Рейтинг: 0 / 0
03.09.2002, 08:21:16
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047611
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
2 Sergey Vinogradov
в моем случае если enddate не нулл - то человек уже уволен.....;))
т.е. в обратном случае (null) запись на текущий момент актуальна и используется....
...
Рейтинг: 0 / 0
03.09.2002, 08:46:29
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047621
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Народ - а не проще людей в отдельную таблицу физ лиц вынести, со всеми их паспортными и другими данными, на которые и делать ссылки в документах, заключаемых договорах и т.д.
...
Рейтинг: 0 / 0
03.09.2002, 09:45:34
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047633
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
так это и есть отдельная таблица....
суть вопроса история изменения .
те нужны данные на определенный момент времени.....
...
Рейтинг: 0 / 0
03.09.2002, 10:21:11
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047634
Sergey Vinogradov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Vinogradov
Участник
To: MiCe
То же работает и с помощью DateMax (например DateMax = '30000101').
Просто без NULL запросы на определенную дату становятся более простыми .
Да и более логично как бы это выглядит (мне так кажется), что для каждого состояния объекта установлен четкий период его действия - как в прошлом, так и в будущем.
...
Рейтинг: 0 / 0
03.09.2002, 10:22:05
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047635
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
все умерают через неделю!.... ;))
немного повторюсь...
актуальный ...
Код: plaintext
1.
2.
3.
select [id],[name1],[name2],[name3]
from [person]
where isnull([enddate])

что может быть проще?
а так как данные в основном добавляются в текущем периоде ....
...
Рейтинг: 0 / 0
03.09.2002, 10:32:35
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047693
Sergey Vinogradov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Vinogradov
Участник
Да я не про актуальное состояние говорил.
Тоже повторюсь:
Просто без NULL запросы на определенную дату становятся более простыми.

Например:
Код: plaintext
1.
2.
3.
select [id],[name1],[name2],[name3]
from [person]
where [begdate] <= @Date and [enddate] > @Date


С NULL в конечной дате это будет выглядеть несколько хуже.
...
Рейтинг: 0 / 0
03.09.2002, 12:18:17
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047717
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
На правах идеи.

Если несколько развить методику Dominic-а, то мне приходят лично вот такие мысли

Представим историю изменения атрибутов клиента не ввиде просто таблицы, а виде 2-х уровневого дерева
Объект первого уровня это клиент как сущность. Все его потомки есть информация о конкретных значения атрибутов клиента на какой-то момент времени(период).
Тогда каких-либо документах нам нужны 2 поля
- для ссылки на клиента как на сущность (для получения каких-либо сводных отчетов)
- для ссылки на конкретное состояние атрибутов клиента

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

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

Повторюсь, что мои размышления - теоритические.
...
Рейтинг: 0 / 0
03.09.2002, 12:50:18
| Ответить | Цитировать | Написать  
сохранение истории ...
    #32047926
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
ссылка на сущность + дата ссылки.....
у меня так на практике....
...
Рейтинг: 0 / 0
04.09.2002, 09:41:00
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / сохранение истории ...
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=32047693&tid=1820638]:
 0ms
get settings:
 5ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 33ms
get topic data:
 6ms
get forum data:
 2ms
get page messages:
 28ms
get tp. blocked users:
 1ms
others: 195ms
total:  283ms
созд. / загр.: 283ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]