Massa52,

В своё время меня тоже душила жаба, что добавляя суррогатный ключ, я как-то непродуктивно увеличиваю размер БД, усложняю структуру и пр. В общем, комплексы, вызванные небольшим размером жёсткого диска (диск был 10 Мб, да-да 10 мегабайт, СУБД FoxPro 2.0)
Потом эти комплексы прошли, и сейчас я всегда, не задумываясь, при создании таблицы первым делом создаю суррогатный ключ, потому-что знаю, он всегда нужен.
Нужен он и тебе, просто ты ещё об этом не знаешь. Попробую не быть голословным, разберём твою ситуацию: поезд проходит через датчик и этот момент фиксируется в БД.
Твои таблицы мы видели. Не вдаваясь в подробности, я просто добавляю к ним суррогатный автоинкрементный ключ. По мере работы твоей программы в таблице в этом поле будут значения вида 1 2 3 4 5 6 7 ........ 100499 100500. Вроде, пока ничего интересного, они вроде и нах не нужны.
Ну, а теперь, представь, прибегает к тебе менеджер, и начинает на тебя орать, что твоя грёбанная программа покоцала данные за один месяц позапрошлого года, мол, данные с датчиков за январь и февраль есть, есть за апрель, а вот за март нету. Ты лезешь в БД, смотришь - действительно данных нет. Стоишь, обтекаешь, в башке одна мысль: "или я накосячил, или какая-то сволочь данные грохнула, или вообще там данные не поступали"
Главное, ответить нечего :-(
Теперь представь ситуацию, у тебя есть суррогатный ключ и прибегает этот-же менеджер.
Открываешь БД, смотришь, действительно, марта нету, однако записи 1001, 1002, 1003 относятся к февралю, 1004, 1005, 1006 уже к апрелю относятся. Показываешь всё это менеджеру и отправляешь его лесом выяснять, почему данные в марте не поступали. Ах, да, вспоминает он, там тогда КамАЗ перевернулся, а потом вообще рельсы бомжи спёрли.

Ну, и самое главное, сурогатный ключ не позволяет, или по крайней мере затрудняет изготовление говноБД.
Давай рассмотрим твою БД

Log_Train
TrainTime smalldatetime
SiteID tinyint - идентификатор данного участка пути
NumberOfAxels smallint
...
Log_Axle
TrainTime smalldatetime
SiteID tinyint - идентификатор данного участка пути
AxleNumber smallint
AxleSpeed real

Тут в обоих таблицах первые два поля содержат одинаковую информацию, и, если вы захотите эти две таблицы связать SQL-запросом, то он будет выглядеть ~ так:


Громоздко, да?
Поэтому лучше сделать ключ, тогда:
Log_Train
Log_TrainID integer
TrainTime smalldatetime
SiteID tinyint - идентификатор данного участка пути
NumberOfAxels smallint
...
Log_Axle
Log_AxleID integer
Log_TrainID integer
TrainTime smalldatetime
SiteID tinyint - идентификатор данного участка пути
AxleNumber smallint
AxleSpeed real

Запрос будет выглядеть так



Уже лучше?

Massa52,

я уважаю твою настойчивость, но позволь мне мягко выразить свои сомнения.
1. Я вообще не уверен, что поле типа SmallDateTime подходит в качестве внешнего ключа, т.е. мне кажется, что связь между двумя таблицами не возможна (т.е. ты не сможешь их объединить SQL-запросом), или будет весьма "корявой".
2. Меня весьма настораживает твоё неоднократно сказанное слово "репроцессинг". Я так понял, что первоначальных данных, пришедших с датчиков уже давно нет? Их каждый раз перелопачивают-переписывают по прихоти менеджера, в зависоимости от температуры на улице? Если это так, то мне кажется, у вас в конторе всё очень плохо, так не должно быть.
Если хочешь знать, как стоило-бы сделать в подобной ситуации, то:
1. Данные с датчиков ОДИН раз записываются в БД, не зависимо от того, правильные они или кривые, мороз или жара, сломанный датчик или нет, - всё: пришли данные - записали.
2. В БД ведётся справочник датчиков и ведётся там-же временнОй журнал исправности датчиков с соответствующим коэффициентом, например, 33-й датчик в июне коэффициент 1.000 - данные датчика попадают менеджеру без измененний. Этот-же датчик в ноябре - коэффициент 0.786. Т.е. ты мысль мою понял? Первичные данные не трогаются, а если кто хочет похимичить с данными - пусть балуется с коэффициентами. И никакого "репроцессинга"
Удачи!