iBase.ru Forum

Здравствуйте!

Есть проблема:
используется FIB-FB 1.5.1

2 таблицы:

CREATE TABLE PERSON (
ID_HUMAN DNKEY ,
DATEEND DATE NOT NULL,
DATEBEGIN DATE NOT NULL,
... some other fields
);
ALTER TABLE PERSON ADD PRIMARY KEY (ID_HUMAN, DATEBEGIN, DATEEND);
=============
CREATE TABLE ABITURIENT (
ID_HUMAN DNKEY ,
DATEBEGIN DATE NOT NULL,
DATEEND DATE NOT NULL,
ID_ABITURIENT DNKEY
);
ALTER TABLE ABITURIENT ADD PRIMARY KEY (ID_ABITURIENT);
ALTER TABLE ABITURIENT ADD FOREIGN KEY (ID_HUMAN, DATEBEGIN, DATEEND)
REFERENCES PERSON (ID_HUMAN, DATEBEGIN, DATEEND);

datasetPerson - master, datasetAbiturient - detail

На сервере (RemoteDataModule) 2 TpFIBDataSet'a связаны через DataSource.
У datasetAbiturient в Select стоит
WHERE ID_HUMAN=:ID_HUMAN and DATEBEGIN=:DATEBEGIN and DATEEND=:DATEEND
у datasetAbiturient в AutoUpdateOptions выставлен генератор на поле
ID_ABITURIENT.

На клиенте 2 pFIBClientDataSet'a также связаны через MasterSource.

Теперь, если в MasterDBGrid попытаться встать на строку, отличную от первой
и для которой в detail _ничего нет_, то происходит ошибка "Key Violation".
Если на сервере обнулить AutoUpdateOptions, то ошибки нет!

Где копать?

Всего доброго,
Антон

где копать - не скажу, а вот интересно, зачем такой странный первичный ключ у таблицы person?
например:

1 28.10.2005 29.10.2005
1 29.10.2005 30.10.2005
1 28.10.2005 30.10.2005

в чем смысл отличия этих записей?

Их смысл - период действия записи.
Например, человек поступает (либо пытается) во второй (третий,..) раз. Вынеся date за ключ, id будет разный, т.е. по сути это разные люди. а так, человек всегда один, и можно проследить историю.
Почему date не в abituriente, потому что на person завязано много других таблиц, в которых тоже имеет роль период действия

Дык всё просто - родился-умер, потом опять родился, опять умер, потом... Я сам аж четыре предыдущих жизни помню На самом деле - ошибка, которой я тоже в начале работы с SQL грешил. Типа по первому сегменту искать буду, по второму или третьему сортировать. Такие индексы на самом деле были весьма удобны при работе с BTrieve из DOS-овских приложений. Берёшь первую запись по сегменту ID индекса и начинаешь некстить по индексу же пока не найдёшь нужную или просто гнать на экран как бы в сортировке. А в SQL от таких индексов никакой пользы акромя вреда - дубликаты не контролируются, FK на такой PK это просто курам на смех, условия на непервые сегменты всё равно пойдут натуралом, при сортировке по ним индекс использоваться не будет... В общем, отвыкать надо от навигационно-индексных замашек.

atg писал(а):Их смысл - период действия записи.
Например, человек поступает (либо пытается) во второй (третий,..) раз. Вынеся date за ключ, id будет разный, т.е. по сути это разные люди. а так, человек всегда один, и можно проследить историю.
Почему date не в abituriente, потому что на person завязано много других таблиц, в которых тоже имеет роль период действия

Не надо смешивать сущности. Человек один? Один. Вот и запись о нём в таблице Человеков с атрибутикой человека должна быть одна. А пытаться поступать он может раз двадцать. И записи об этом, следственно, должны быть в таблице Попыток с атрибутами попыток, растущей как 1:n от таблицы Человеков.

и причем, если на человека 1 попытка 1 раз в год, то тогда надо ПК как
DBEGIN INT
IDPERSON INT

то есть, год 4-мя цифрами, а не дату. А дальше уже конкретную дату приема документов, например, и т.д. и дата это просто атрибут, никак данную персону или попытку поступления не идентифицирующей.

В общем, ушли от темы, занявшись просветительством по поводу проектирования БД

kdv писал(а): В общем, ушли от темы, занявшись просветительством по поводу проектирования БД

А по теме и сказать-то нечего Не знаю насчёт нонешнего Датаснапа, а в его предшественнике Мидасе вокруг мастер-деталей и обновлений такого навертели, пытаясь притянуть за уши клиент-серверную идеологию, да столько ошибок при этом напороли, что я на их потуги плюнул и построил свою технологию и для того и для другого.