Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Снова хранение истории данных / 23 сообщений из 23, страница 1 из 1
10.08.2006, 14:46
    #33910675
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Есть сущность лицо с кучей аттрибутов и уникальным ИНН

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
create table Persons
{
   INN crah( 10 ),
   F varchar( 50 ), 
   I varchar( 50 ),
   O varchar( 50 ),
   ....
}

FK - INN

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

Очень хочется реализовать систему хранения истории изменений в одной таблице путем добавления полей DateBegin, DateEnd
при этом таблица примет вид

create table Persons
{
INN crah(10),
DateBegin datetime,
DateEnd datetime,
F varchar(50),
I varchar(50),
O varchar(50),
....
}
[/src]
при этом FK - {INN, DateBegin, DateEnd}

проблема что такой FK тяжело тягать по другим сущностям

Как быть?
делать доп таблицу истории не предлагать пожалуста - интересует только этот вариант
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 14:49
    #33910685
gybson
gybson
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
интересует только этот вариант

а в чем тогда вопрос? :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 15:00
    #33910734
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
gybson
интересует только этот вариант

а в чем тогда вопрос? :)

Вопрос в том как обойти ситуацию с таким неестественным ключем
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 16:10
    #33910962
KM2
KM2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Введите "обычный" первичный ключ в отдельном поле, и используйте его для ссылок из других таблиц. А комбинацию INN, DateBegin, DateEnd можете тогда использовать как вторичный уникальный ключ.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 16:27
    #33911047
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
KM2Введите "обычный" первичный ключ в отдельном поле, и используйте его для ссылок из других таблиц. А комбинацию INN, DateBegin, DateEnd можете тогда использовать как вторичный уникальный ключ.

Но при изменении аттрибутов получается обычный ключ изменится и мне необходимо во всех таблицах изменить ключ - тогда историчность к черту - ведь она предполагает что ключ не меняется а версия бертся по периоду
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 16:37
    #33911101
KM2
KM2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Честно говоря, я не вполне понял Ваши возражения. Напишите, пожалуйста, поподробнее, как именно вы собираетесь использовать версии и почему ключ при этом меняется. Может быть, пример какой-нибудь.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 16:45
    #33911137
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
KM2Честно говоря, я не вполне понял Ваши возражения. Напишите, пожалуйста, поподробнее, как именно вы собираетесь использовать версии и почему ключ при этом меняется. Может быть, пример какой-нибудь.

Если я сделаю так ка вы говорите:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table Persons
{
   ID int,
   INN crah( 10 ),
   DateBegin datetime,
   DateEnd datetime,
   F varchar( 50 ), 
   I varchar( 50 ),
   O varchar( 50 ),
   ....
}

и ID - первичный автогенерируемый ключ, то при изменении аттрибутов я должен вставить новую строку в таблицу в которой ID будет вновь сгенерирован и он уже не тот который есть в других таблицах - т.е. мне нужно теперь во всех таблицах изменить старое значение ключа на новое, что есть неприемлемо!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 16:59
    #33911195
KM2
KM2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Если Вы вставляете новую запись в таблицу, то при этом Вы создаете новую версию объекта. При этом записи, которые ранее ссылались на предыдущую версию объекта, так на нее и продолжают ссылаться. Т.е. связаны именно с определенной версией, а не "вообще с объектом". Я не очень понял, почему это неприемлемо?

Т.е. если Вы хотите, чтобы внешние таблицы ссылались всегда на одну и ту же запись, вне зависимости от версии, то тогда решение вставить в эту запись поля дат не представляется правильным решением...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 19:14
    #33911567
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
KM2Если Вы вставляете новую запись в таблицу, то при этом Вы создаете новую версию объекта. При этом записи, которые ранее ссылались на предыдущую версию объекта, так на нее и продолжают ссылаться. Т.е. связаны именно с определенной версией, а не "вообще с объектом". Я не очень понял, почему это неприемлемо?

Т.е. если Вы хотите, чтобы внешние таблицы ссылались всегда на одну и ту же запись, вне зависимости от версии, то тогда решение вставить в эту запись поля дат не представляется правильным решением...

При вставке новой версии объекта все записи которые ссылались на эту запись должны теперь ссылаться на новую версию - иначе смыла никакого нет
Пример: Иванов до 2006г был ивановым и по всем договорам выписанным до 2006г он Иванов
Тут он женился и стал ПЕТРОВЫМ - и в новых документах с 2006г он ПЕТРОВ, но при этом я вижу эту сущность как один объект а не как два разных ПЕТРОВ и ИВАНОВ
А в вашей версии я имею 2 разных объекта правильно привязанных к документам по времени и все - где же здесь история? и зачем мне в таком случае поля DateBegin DateEnd - ID вполне хватит !
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 20:15
    #33911641
SergGol
SergGol
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
В детских документах нужно хранить не ID, а INN, а фамилию и пр. выводить либо согласно текущей дате, либо согласно дате из детского документа. Тогда в договоре от 2005 г. он Иванов, а в 2006г. будет Петров.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.08.2006, 21:32
    #33911699
KM2
KM2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Ну, вот вы постановку задачи раскрываете по песчинке, и из-за этого не все и понятно. Я же и просил вас привести пример, как вы собираетесь работать с версиями, чтобы понять, как же правильно сделать БД.
spПример: Иванов до 2006г был ивановым и по всем договорам выписанным до 2006г он Иванов
Тут он женился и стал ПЕТРОВЫМ - и в новых документах с 2006г он ПЕТРОВ, но при этом я вижу эту сущность как один объект а не как два разных ПЕТРОВ и ИВАНОВ
А в вашей версии я имею 2 разных объекта правильно привязанных к документам по времени и все - где же здесь история? и зачем мне в таком случае поля DateBegin DateEnd - ID вполне хватит
Ну, вот и пример. Только он ничего не поясняет. Если в договорах 2005 года значился Иванов, то зачем в 2006 году переставлять ссылки со старых договоров на теперь уже Петрова? Договора - это же не просто так, это же юридические документы. Если там был прописан Иванов, то, сколько ни меняй потом фамилию, в договоре-то останется Иванов. Поэтому ваши слова, что
spПри вставке новой версии объекта все записи которые ссылались на эту запись должны теперь ссылаться на новую версию - иначе смыла никакого нет
не очень понятны - с точки зрения обычной житейской логики как раз в переставлении ссылок на новую запись смысла никакого нет - ведь искажается содержание документов. Может быть, в вашей системе есть какие-то другие специальные требования, чтобы это было обосновано?

Кстати, я не буду настаивать, что предложенная мной версия решения универсальная и отвечает на все случаи жизни, но раз вы спросили "где же здесь история?", поясню. История в том, что документы связаны именно с той версией субъекта, которая прописана в этом документе. А комбинацию полей INN, DateBegin, DateEnd можно использовать для того, чтобы определить, какие конкретно реквизиты данный субъект имел в заданный момент времени (например, в текущий момент).

А вообще, нужно все-таки определиться с тем, какие у вас предъявляются требования к хранению "версий" и "истории". Тогда мы имели бы объективную основу для оценки вариантов решения. А не зная требований, это пустой спор - для каких-то задач один вариант будет удобнее, для каких-то - другой...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.08.2006, 12:23
    #33912880
Gennady_
Gennady_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Наверное надо так:

Код: plaintext
1.
2.
3.
4.
create table Root
  ID_ROOT int,
  INN char( 10 )
  ...

а затем

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
create table Persons
{
   ID_ROOT_TABLE_ROOT int,
   DateBegin datetime,
   DateEnd datetime,
   F varchar( 50 ), 
   I varchar( 50 ),
   O varchar( 50 ),
   ....
}
где ID_ROOT_TABLE_ROOT внешний ключ.
При заполнении поля DateEnd хранимкой создается новая запись в Persons со ссылкой на всё тот-же ID_ROOT из Root
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.08.2006, 12:27
    #33912896
Gennady_
Gennady_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Ну и во всех документах ссылаемся на ID_ROOT из таблы Root
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.08.2006, 05:01
    #33914824
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Gennady_Ну и во всех документах ссылаемся на ID_ROOT из таблы Root
Спасибо всем кто ответил
Я пришел к устраивающему меня и систему решению:
так как INN уникальный и в нашей системе является обязательным - вынести его в отдельную таблицу и тогда параметры лица автоматически становятся дочерней таблицей со стандартной системой хранения истории

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
create table INN
{
  INN char( 10 )
}

create table Persons
{
   INN char( 10 ),
   DateBegin datetime,
   DateEnd datetime,
   F varchar( 50 ), 
   I varchar( 50 ),
   O varchar( 50 ),
   ....
}

Еще раз спасибо всем
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.08.2006, 10:58
    #33914858
Cat2
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Я рад, что проблема решена. Но я предостерегаю от использования ИНН как первичного ключа. В одной из моих знакомых контор ИНН менялся уже четыре раза. Я бы использовал суррогатный ключ
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.08.2006, 17:24
    #33917190
iamhere
iamhere
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Cat2Я рад, что проблема решена. Но я предостерегаю от использования ИНН как первичного ключа. В одной из моих знакомых контор ИНН менялся уже четыре раза. Я бы использовал суррогатный ключ

Абсолютно!!! Не смейте использовать ИНН как первичный ключ - хлопот не оберетесь!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.08.2006, 12:43
    #33918687
sqllex
sqllex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
+1
Верующие в качестве ИНН часто используют номер паспорта.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.08.2006, 12:52
    #33918711
INN-щик
INN-щик
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
spтак как INN уникальный и в нашей системе является обязательным
1. Если у организации есть филиалы, то ИНН у них один и тот же, а КПП разные - нормальная ситуация.
2. У человека может не быть ИНН запросто. У иностранных организаций, не стоящих на учете в налоговых органах в РФ, также нет ИНН.

В итоге, ИНН 1) не является обязательным и 2) не является уникальным.
Кроме того, ИНН реально может меняться со временем. Так что ИНН не просто не может быть первичным ключем, но даже по нему нельзя идентифицировать контрагента/партнера/сотрудника/поставщика/покупателя/и т.п.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.08.2006, 12:56
    #33918721
Templar
Templar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Хронологические данные. Шаблоны проектирования базы данных
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.08.2006, 14:44
    #33919085
LightNet
LightNet
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
spINN уникальный и в нашей системе является обязательным
Код: plaintext
1.
2.
3.
4.
create table INN
{
  INN char( 10 )
}

ну уж тогда не char(10), а char(12), актуально для физлиц.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.08.2006, 03:44
    #33931222
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
Спасибо всем за посты - мне надо задуматься над Вашими замечениями :)
Я не думал что с ИНН может происходить такая фигня
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.08.2006, 03:45
    #33931223
sp
sp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
INN-щик spтак как INN уникальный и в нашей системе является обязательным
1. Если у организации есть филиалы, то ИНН у них один и тот же, а КПП разные - нормальная ситуация.
2. У человека может не быть ИНН запросто. У иностранных организаций, не стоящих на учете в налоговых органах в РФ, также нет ИНН.

В итоге, ИНН 1) не является обязательным и 2) не является уникальным.
Кроме того, ИНН реально может меняться со временем. Так что ИНН не просто не может быть первичным ключем, но даже по нему нельзя идентифицировать контрагента/партнера/сотрудника/поставщика/покупателя/и т.п.

речь шла о лицах :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.08.2006, 10:29
    #33936570
Bonn
Bonn
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Снова хранение истории данных
У меня почти та же проблема, и предложенное решение меня настораживает, выборка всех документов нужного обьекта (например кронтрагента) с таким построением.... жутко неудобно. В связи с этим возник ряд вопросов:

1) для чего нужна дата DateEnd? Разве DateBegin не достаточно? для того чтобы узнать версию объекта на определенную дату, достаточно выбрать версию с максимальной датой, меньшей (или равной) необходимой даты.
Или я не прав? Какие могут возникнуть трудности?

2)Если рассмотреть такой вариант:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table Persons
{
   ID int,
   IDP int,
   ...
   DateBegin datetime,
   F varchar( 50 ), 
   I varchar( 50 ),
   O varchar( 50 ),
   ....
}

где ID - первичный ключ,
IDP - возможно внешний ключ, который ссылается на поле ID этой же таблицы, но не обязательно (хотя желательно)
в любом случае для первой записи IDP=ID

Принцип работы с объектом
Ну с первой записью вроде понятно...
При изменении например фамилии:
а) копируем текущую (актуальную) запись объекта но с новым ID
б) в текущей (активной) записи обновляем фамилию и дату DateBegin на новые значения
В результате имеем реальный объект с постоянным ID и всю его историю с IDP=ID. Имея объект (его ID) теперь легко получить все объекты, которые на него ссылаются не зависимо от истории, правда несколько осложняется работа с данными в контексте ссылающихся объектов, но по ID и DateBegin все остальные поля получить не трудно.
Не исключено, что я не заметил еще каких-то подводных камней или даже айсбергов, если их кто-то заметит, огромная просьба отозваться, не хотелось бы идти по ложному пути
Заранее огромное спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Снова хранение истории данных / 23 сообщений из 23, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 430ms
Закрыть
start [/forum/topic.php?fid=32&mobile=1&tid=1545083]:
 0ms
get settings:
 7ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 158ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 33ms
get tp. blocked users:
 1ms
others: 198ms
total:  430ms
x
x
Закрыть


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