Разбор tcx файла с Garmin навигатора для построения на основе данных графиков через WEB-интерфейс.

[sash-kan]

Но в данном конкретном случае полей всего два

в таблице замеров несколько больше, чем два поля — по крайней мере идентификатор круга, время, пульс и расстояние·
возможно, ещё координаты, и другая информация, извлекаемая из файла·

Но очевидно, что лишнее поле в данных в полтора раза увеличивает объём таблицы, и в полтора раза уменьшает скорость (было 2 поля, стало 3).

ну, про объём вы уже поняли, а про скорость (кстати, скорость _чего_?) я лучше совсем промолчу…

раз уж гранулярность в 1 сек задана по ТЗ

время trackpoint-а в файле записано·
в виде <Time>2012-03-20T07:18:42Z</Time>

p.s. я уже написал выше, что в таблице замеров (trackpoints) можно обойтись и вообще без primary key·
просто потому, что к записям этой таблицы не требуется привязывать записи других таблиц·

[drBatty]

в таблице замеров несколько больше, чем два поля — по крайней мере идентификатор круга, время, пульс и расстояние·
возможно, ещё координаты, и другая информация, извлекаемая из файла·

ну вот... Я же говорил - надо знать задачу... В таком случае отдельный primary key безусловно полезен.

а про скорость (кстати, скорость _чего_?) я лучше совсем промолчу…

скорость извлечения выборки например с 5й по 10ю минуту. Если у вас будет составной индекс, то эта скорость будет меньше. Наверное вдвое меньше (хотя это уже от реализации зависит - если там, в индексе всё равно 64х битные числа, то два 32х битных можно упаковать в одно).
С другой стороны, совсем непонятно в этом случае, зачем вам тут составной индекс? Логичнее сделать три индекса:
1. по primary key, зачем не знаю, сам создастся.
2. по временной не уникальной метке - для выборки по времени.
3. по расстоянию - для выборки по расстоянию.
Зачем мешать 1 и 2 - не очень понятно, если я правильно понимаю ТЗ, то время уникально для каждого круга. Если не уникально, то правильнее смешать в одном индексе 2 и 3. Наверное. Я не в курсе, как эти приборы работают...

[Stasroot1]

в таблице замеров несколько больше, чем два поля — по крайней мере идентификатор круга, время, пульс и расстояние·
возможно, ещё координаты, и другая информация, извлекаемая из файла·

ну вот... Я же говорил - надо знать задачу... В таком случае отдельный primary key безусловно полезен.

а про скорость (кстати, скорость _чего_?) я лучше совсем промолчу…

скорость извлечения выборки например с 5й по 10ю минуту. Если у вас будет составной индекс, то эта скорость будет меньше. Наверное вдвое меньше (хотя это уже от реализации зависит - если там, в индексе всё равно 64х битные числа, то два 32х битных можно упаковать в одно).
С другой стороны, совсем непонятно в этом случае, зачем вам тут составной индекс? Логичнее сделать три индекса:
1. по primary key, зачем не знаю, сам создастся.
2. по временной не уникальной метке - для выборки по времени.
3. по расстоянию - для выборки по расстоянию.
Зачем мешать 1 и 2 - не очень понятно, если я правильно понимаю ТЗ, то время уникально для каждого круга. Если не уникально, то правильнее смешать в одном индексе 2 и 3. Наверное. Я не в курсе, как эти приборы работают...

Чувствую себя отсталым идиотом по двум причинам:
1. не пойму как комментировать часть поста а не весь пост. Кнопка "Цитата" работает не понятно, надо почитать как ей пользоваться в инструкциях.
2. Я еле еле поспеваю за ходом ваших мыслей, чувствуется что вы в вопросах БД и программирования разбираетесь лучше меня на порядки... но это тут я сам виноват, все таки спортсмен и основную часть времени трачу на тренировки и планирование, анализ. Спортивные теории и практики...

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

Теперь к сути вопросов...

sash-kan, вы понимаете проблемы очень хорошо как мне кажется. Что касается PK по pid в таблице t, то считаю это поле необходимым так как в дальнейшем предполагается использовать данные об отдельных наборах точек для составления и анализа отдельных частей тренировки с разными tid. И для хранения данных о точках в особо важных отрезках проведенной тренировки. Хранить эти особо важные точки (ссылки на этот pid) надо будет в соответствующей таблице, которой пока нет в нашей БД, чтобы не усложнять проект, это уже на следующем этапе так сказать.

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

(пояснение для drBatty:даже если наши виртуальные 20 спортсменов, реально их больше, тех которые каждый день пользуются навигаторами (около 250-300 человек) запустят тренировку в РАЗНЫЕ временные промежутки, именно запустят, то при гранулярности в 1 секунду у них всегда будет разное время так как оно пишеться ориентируясь на СПУТНИКОВОЕ время из космоса (GMT) на всех устройствах течение времени СИНХРОННО это по технологии позиционирования навигаторов на местности. Если предположить, что во время тренировки НИКТО не остановит свой таймер, то уникальность сохраниться до конца тренировки. В реальности такого почти не бывает так как спортсмены довольно часто пользуются кнопкой stop на навигаторе А это значит, что именно время записываемое далее может сбиваться и таким образом может появиться таймштамп с одинаковым временем , в результате могут начаться проблемы построения графиков, например точка от одного спортсмена может стать точкой другого спортсмена а это будет значить что как минимум какой то из спортсменов по ошибке в архитектуре хранения данных получит пиковое ускорение скажем до 1500 км/час (вдруг пересекающийся спортсмен был в другой точке Земли) В результате анализ сбивается... Постарался поподробнее)

Теперь как работает устройство, вернее устройства:
В космосе есть спутники они постоянно синхронизируются между собой и с атомным временем. На них всегда GMT там нет поправок на часовые пояса. Спутники находятся на геостационарной орбите, или нет, в общем это не важно, они отправляют на Землю сигнал с координатами своего положения и ТОЧНОЕ время. Для работы навигатора, любого, в том числе спортивного надо минимум три спутника, получив данные о координатах с этих спутников навигатор высчитывает свое положение, к слову высчитывает он его чаще чем рас в секунду, чипсэт это определяет. Так вот мой навигатор и другие спортивные навигаторы пишут инфу о координатах и времени каждую секунду, не чаще. (ну так вот они запрограммированы). Мой например еще при этом успевает посчитать перемещение и тоже пишет эту инфу в файл. Все вроде. Таким образом у нас нет возможности не перепрограммируя навигатор получить время чаще и координат больше. По сути все.

Скорее всего ответил не на все возникшие вопросы, не мог нормально писать сообщение, постоянно отрывали звонками, так что надеюсь не слишком рваная мысль получилась.

Сейчас бегу на тренировку после внимательно все что вы написали прочитаю и может еще что то добавлю от себя.

На данный момент чуть переделал ключи и исправил кое какие ошибки в структуре и создал дамп с данными для загрузки. Оба файла прикрепляю сюда.

Схема БД SQL.

02_02.garmin2data.sql.tar.gz

(856 байт) 41 скачивание

Импортируемые данные (внутри коменты импортируемых данных):

02_garmin2schema.sql.tar.gz

(1.25 КБ) 38 скачиваний

Импорт данных транзакцией.

[drBatty]

1. не пойму как комментировать часть поста а не весь пост. Кнопка "Цитата" работает не понятно, надо почитать как ей пользоваться в инструкциях.

слева под аватаркой есть ещё одна "цитата". А движок форума да, кривовастенький... Ну что делать - один из лучших, большинство других ещё хуже...

2. Я еле еле поспеваю за ходом ваших мыслей, чувствуется что вы в вопросах БД и программирования разбираетесь лучше меня на порядки... но это тут я сам виноват, все таки спортсмен и основную часть времени трачу на тренировки и планирование, анализ. Спортивные теории и практики...

во-во. А я вот даже зарядку не делаю :-(
Сразу за компьютер :(((
Ладно, пойду с детьми гулять, потом вам отвечу :-)
Хоть что-то похожее на спорт...

[sash-kan]

Что касается PK по pid в таблице t, то считаю это поле необходимым так как в дальнейшем предполагается использовать данные об отдельных наборах точек для составления и анализа отдельных частей тренировки с разными tid. И для хранения данных о точках в особо важных отрезках проведенной тренировки. Хранить эти особо важные точки (ссылки на этот pid) надо будет в соответствующей таблице, которой пока нет в нашей БД, чтобы не усложнять проект, это уже на следующем этапе так сказать.

даже в этом случае уникальный идентификатор не жизненно необходим:
надо будет всего лишь хранить в этой будущей таблице не уникальные номера замеров (trackpoint-ов), а пары "идентификатор круга"+"время замера"·
но тут уж вам виднее, как вы планируете работать с этими «важными отрезками»·

кстати, при запросах к таблице замеров (trackpoints), как я понимаю, чаще всего будут запрашиваться наборы замеров (весь круг или только часть — не важно), а не единичные записи·
и проще, наверно, будет формулировать границы не абстрактными номерами, а «с такого-то времени по такое-то»·
типа:
select * from p where lid=<идентификатор круга> and time_field between "2012-03-20 07:18:00" and "2012-03-20 07:19:00";
(здесь time_field — столбец, содержащий отметки времени)·

поэтому для ускорения обработки таких запросов, даже при наличии уникального идентификатора записи, совсем не помешает индекс, построенный на этом поле с отметками времени·
индекс может быть не отдельный, а совместный по тем полям, которые чаще всего будут фигурировать вместе в условии "where"·
в вышеприведённом примере это lid и time_field

слева под аватаркой есть ещё одна "цитата".

hint: надо выделить текст и нажать эту ссылку·
выделенный текст появится внизу страницы в поле быстрого ответа, уже обрамлённый тэгами quote·
только обращайте внимание на то, под чьей аватарой ее нажимаете, ибо он и станет автором цитаты (улыбка)

[Stasroot1]

hint: надо выделить текст и нажать эту ссылку·
выделенный текст появится внизу страницы в поле быстрого ответа, уже обрамлённый тэгами quote·
только обращайте внимание на то, под чьей аватарой ее нажимаете, ибо он и станет автором цитаты (улыбка)

Нороший хинт! :-)
Сейчас почитаю все подробнее, кое что отпишу... кое какие вопросы формируются в моем спортивном мозгу .

Ладно, пойду с детьми гулять, потом вам отвечу :-)

По моему это прекрасный спорт! :-)

[Stasroot1]

даже в этом случае уникальный идентификатор не жизненно необходим:
надо будет всего лишь хранить в этой будущей таблице не уникальные номера замеров (trackpoint-ов), а пары "идентификатор круга"+"время замера"·
но тут уж вам виднее, как вы планируете работать с этими «важными отрезками»·

Мысль интересная, пожалуй надо поделиться планами того как данные будут использоваться помимо построения общего графика за тренировку...

И так, со стороны пользователя это выглядеть должно примерно так:
1. Пользователь может сразу после загрузки файла с данными посмотреть эти данные в виде графика. О том как отрисовать график - вопрос пока далекий. Но для отрисовки естесственно потребуются данные о трекпоинтах. Думаю тут относительно просто, построить набор данных соответствующих тренировке и отобразить.
2. Далее у него должна быть возможность отрисовать графики по кругам, т.е. запрос типа трекпоинты соответствующие lid... отрисовать.

На этом заканчивается тот функционал который предоставляет Garmin в своей стандартной утилите для работы с данными о тренировке в среде ОС Win и ОС MAC.

Мне нужно в дополнение к этим двум функциям (они описаны примитивно но это основное, так сказать без рюшечек.) реализовать следующие..

3. Отрисовать график круга, последовательности кругов, или всей тренировки так, чтобы пользователь смог явно указать с какого (времени или pid) места и по какое его интересуют данные в первую очередь. Таких мест может быть много.
Вы можете задаться вопросом, а почему например не хватает отобразить графики именно соответствующие заранее определенным кругам... отвечаю: дело в том, что периодически тренировка которая планировалась к выполнению и была задана на устройство в качестве задания в ходе самой реальной тренировки может корректироваться и в результате фактически проведенное ускорение или увеличенный по времени/расстоянию отрезок выходит за рамки запланированного круга. Т.е. ему приходиться отрисовать например несколько фактически выполненных кругов и найти на них то ускорение которое он совершал отклонившись от выполнения этих трех кругов.

Чуть позже, выложу пару/тройку графиков с данными о тренировках. Кое что что станет яснее.
Прикрепляю:
в этом файле видно, что по горизонтали отложено время по вертикали слева скорость по вертикали с права пульс. К слову это мои личные данные и я могу их публиковать как хочу. Это то как я тысячу метров прошел на одной из своих КПД (контрольное прохождение дистанции) Там еще есть желтенькое такое всплывшее облачко которое показывает скорость.... о том как оно работает в фирменной утилите расскажу позже, когда посчитаем нужным, работает оно не совсем удобно. И к тому же очень очень не точно, точность с приближением до целого километра/час это слишком большая погрешность. К справке, не вся тренировка - это круг в рамках понимания garmina... ну а для меня физически это прямая :-) Мне надо строить через вэб графики более точные. Схожие по этому примеру что ниже на картинке. Но это реализация только первых двух основных функций... а еще надо добавить третью. Это возможность выделить на этом графике кусок от начала до середины, от начала до четверти, от четверти до середины и так далее так сказать по шаблону, и произвольное выделение. И анализ выделенного участка по аналогии с тем как анализирует система гармина в настоящее время, т.е. определит среднюю скорость на выделенном/выделенных (выделенных отрезков может быть несколько) максимальную скорость, пульсовые характеристики и прочее, ну например степень изменения скорости передвижения, т.е. определение стабильности передвижения на участке с тем чтобы потом можно было сравнивать стабильность с другими участками и другими спортсменами...

А это тот же отрезок но с горизонтальной откладкой по расстоянию. Только без верхушки.

Думаю когда задача ставиться нагляднее то она и понятнее должна становиться.
А мне по хорошему спать надо уже ложиться... :-(

[Stasroot1]

кстати, при запросах к таблице замеров (trackpoints), как я понимаю, чаще всего будут запрашиваться наборы замеров (весь круг или только часть — не важно), а не единичные записи·

Да так как запрашивать для построения графика только одну точку ну не слишком будет ... поэтому чтобы построиь график с максимальной гранулярностью в одну секунду надо делать как вы предлагаете, т.е. запрос на пару lid+время с такого по такое - для построения части круга, запрос на весь круг может как то проще типа все точки, соответствующие lid (не в SQL так как пока не сильно разбираюсь и написание элементарного комбинированного запроса для меня пока сложно, изучаю на примере PhPMyAdmin..)

А вот если строить версии графиков ознакомительного характера Типа с интервалом в 5-10 секунд, думаю правильнее построить по запросу типа: выбрать данные соответствующие условию: lid+каждый пятый ID из pid соответствующих lid.... как то так, думаю вы меня поймете правильно.

Что будет запрашиваться чаще пока не знаю, думаю что чаще все таки будут спрашивать полностью гранулярный график с шагом в секунду. Но и с переменным размером гранулы графики тоже будут востребованы как мне представляется ситуация с запросом на подобный функционал.

и проще, наверно, будет формулировать границы не абстрактными номерами, а «с такого-то времени по такое-то»·
типа:
select * from p where lid=<идентификатор круга> and time_field between "2012-03-20 07:18:00" and "2012-03-20 07:19:00";
(здесь time_field — столбец, содержащий отметки времени)·

На счет столбца time_field это я понял сам сразу.
По этому поводу отписал свой взгляд несколькими строками выше.

[drBatty]

по поводу уникальности времени: lid я не предлагал убирать, потому круги НЕ будут смешиваться, и никаких ускорений в 1500мс тоже не будет. Будет очень незначительное и очень редкое замедление. Гранулярность приборов я тоже не предлагаю менять - речь лишь о внутреннем представлении.

[drBatty]

я вот еще понять не могу: как вы вычисляете расстояние от начала круга? ИМХО оно должно вычисляться при загрузке данных, и хранится в отдельном поле таблицы трекпоинтов.

[Stasroot1]

я вот еще понять не могу: как вы вычисляете расстояние от начала круга?

в начале темы были файлы, которые получались с этого устройства, делее еще был файл с другого устройства.
И там и там в данных о трекпоинте есть параметр расстояния. Как я понял он отсчитывается от начала, т.е. от первого трекпоинта. Первый трекпоинт 0 метров, второй уже 2 метра, значит зза первую секунду 2 метра, третий трекпоинт уже имеет указание на 5 метров, значит за вторую секунду - 5-2=3 метра пройдено, и так далее. Т.е. как я понимаю в трекпоинт записывается информация о расстоянии по предидущему трекпоинту плюс то расстояние которое преодолено за последнюю секунду. Естесственно этот параметр тоже будет писаться в таблицу с трекпоинтами. Таблици БД что прикреплял выше расширю сегодня дополнительными данными и снова выложу сюда.

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

Соответственно мы можем посчитать скорость в каждую секунду времени, например: трекпоинт №1000 имеет показатель расстояния равный 5685 метров, трекпоинт №1001 имеет показатель 5689 метров, соответственно 5689-5685=4метра - разница между трекпоинтами а это значит что скорость у нас равна 4 метра/секунду так как гранулярность в 1с. Ну а дальше дело техники преобразовать в км/ч например если понадобится.

Если это не сложно, то можно полученные 4м/с тоже записать в таблицу о трекпоинтах чтобы потом при выбоках из БД использовать этот параметр а не заниматься каждый рас при выборках вычислениями, может так кстати и оптимальнее будет делать, правда операция импорта данных в БД будет чуть дольше...

ИМХО оно должно вычисляться при загрузке данных, и хранится в отдельном поле таблицы трекпоинтов.

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

В подтверждение и чтобы не искать файл выше по теме. часть файла которая соответствует первым двум точкам тренировки:

Код: Выделить всё

<Track>
<Trackpoint>
<Time>2012-03-22T08:28:05Z</Time>
<Position>
<LatitudeDegrees>45.010642</LatitudeDegrees>
<LongitudeDegrees>39.047021</LongitudeDegrees>
</Position>
<AltitudeMeters>23.071</AltitudeMeters>
<DistanceMeters>0.093</DistanceMeters>
<HeartRateBpm>
<Value>102</Value>
</HeartRateBpm>
</Trackpoint>
<Trackpoint>
<Time>2012-03-22T08:28:06Z</Time>
<Position>
<LatitudeDegrees>45.010643</LatitudeDegrees>
<LongitudeDegrees>39.047022</LongitudeDegrees>
</Position>
<AltitudeMeters>23.071</AltitudeMeters>
<DistanceMeters>0.239</DistanceMeters>
<HeartRateBpm>
<Value>102</Value>
</HeartRateBpm>
</Trackpoint>

а вот последние две точки тренировки:

Код: Выделить всё

<Trackpoint>
<Time>2012-03-22T11:01:31Z</Time>
<Position>
<LatitudeDegrees>45.010709</LatitudeDegrees>
<LongitudeDegrees>39.046783</LongitudeDegrees>
</Position>
<AltitudeMeters>19.851</AltitudeMeters>
<DistanceMeters>10615.634</DistanceMeters>
<HeartRateBpm>
<Value>97</Value>
</HeartRateBpm>
</Trackpoint>
<Trackpoint>
<Time>2012-03-22T11:01:32Z</Time>
<Position>
<LatitudeDegrees>45.010710</LatitudeDegrees>
<LongitudeDegrees>39.046781</LongitudeDegrees>
</Position>
<AltitudeMeters>19.851</AltitudeMeters>
<DistanceMeters>10615.707</DistanceMeters>
<HeartRateBpm>
<Value>97</Value>
</HeartRateBpm>
</Trackpoint>
</Track>

тэг <DistanceMeters></DistanceMeters> как рас и содержит данные о пройденном на момент трекпоинта расстоянии.

[drBatty]

но зачем, если это расстояние уже посчитал прибор

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

Если это не сложно, то можно полученные 4м/с тоже записать в таблицу о трекпоинтах чтобы потом при выбоках из БД использовать этот параметр

это не сложно, но зачем? При необходимости скорость можно вычислить, причём это вычисление будет иметь копеечную стоимость. Т.е. мы практически не затратим на него времени, по сравнению со всем остальным. Как я уже говорил, не нужно в БД хранить лишние и ненужные данные. Скорость можно было-бы хранить в тех например случаях, когда вам нужно постоянно извлекать выборки типа "покажи мне спортсменов, которые плыли со скоростью от 4х до 5и метров в сек". Как я понимаю, такие запросы если и нужны, то достаточно редко, и потом ориентироваться на них не нужно.

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

эта структура хороша при след. условиях:
1. в каждой тренировке учавствует _один_ спортсмен, который на этой тренировке пользуется _одним_ прибором.
2. каждый круг входит только в _одну_ _единственную_ тренировку.
Если вы не планируете что-то менять, то данная структура вполне подходит.
По поводу отдельной таблицы "особых" точек - я не знаю, есть-ли смысл её вводить. Вполне можно, и может быть даже лучше, обойтись и без неё, добавив в таблицу трекпоинтов поле "особости", которое равно 0 для обычной точки, и 1 для особой. Тогда для того, что-бы сделать точку "особой", будет достаточно изменить это новое поле с 0 на 1. Преимущество данной схемы в том, что если мы захотим удалить какие-то точки, то мы это можем сделать одним запросом, к одной таблице, а если у нас две таблицы, причём в каждой из них точки, то придётся делать два запроса.

[drBatty]

lid+каждый пятый ID из pid соответствующих lid...

вот с этим вашим pid вы можете и ошибиться: вы _уверены_ что прибор выдаёт точки в _правильном_ порядке? Т.е. разве принципиально невозможна ситуация, когда строчка в файле за 123ю секунду идёт _после_ строчки за 124ю? ИМХО намного правильнее сортировать точки именно по времени, а не по pid'у, который у нас введён искуственно, и его значения зависят от порядка строчек. К тому же, время, как я понимаю, уникально, в пределах одного круга. Т.е. прибор в принципе не может выдать две строчки за 123ю секунду(?). Если таки прибор может так делать, то следует сортировать и выбирать точки по двум ключам, а именно по времени, и по расстоянию. Т.е. в течении одной 123й секунды спортсмен был на расстоянии 100метров, и 101метр от старта, что вполне возможно в реальной жизни. Это надо для того, что-бы не получилось такого, что в течении одной секунды спортсмен был _сначала_ в 101ом метре, а _потом_ в 100 метрах, т.е. плыл зигзагом. Однако, всё это не играет роли, если ваши приборы не умеют фиксировать две точки за одну секунду.

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

[Stasroot1]

Цитата(Stasroot1 @ 7th April 2012 - в 09:22) *
но зачем, если это расстояние уже посчитал прибор

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

Думаю вы понимаете, что расстояние от начала круга не совсем правильно... так как начало круга в одной точке, а та точка в которой указывается это расстояние от начала круга (например под номером 1000). Как изывестно расстояние между двумя точками мерится по прямой... а точки №№ 125, 258, 589, 985.. могут быть в стороне от этой самой прямой, поэтому говорить что это расстояние от первой точки (от начала круга) не совсем корректно, это все таки сумма предидущих расстояний между предидущими точками + расстояние от предпоследней точки до последней, т.е. до точки номер 1000. Думаю понятно изяснился.

это не сложно, но зачем? При необходимости скорость можно вычислить, причём это вычисление будет иметь копеечную стоимость. Т.е. мы практически не затратим на него времени, по сравнению со всем остальным. Как я уже говорил, не нужно в БД хранить лишние и ненужные данные. Скорость можно было-бы хранить в тех например случаях, когда вам нужно постоянно извлекать выборки типа "покажи мне спортсменов, которые плыли со скоростью от 4х до 5и метров в сек". Как я понимаю, такие запросы если и нужны, то достаточно редко, и потом ориентироваться на них не нужно.

Т.е. если я правильно вас понял выбрать 7200 параметров о расстоянии и потом провести расчет для 7200 точек на стороне PHP намного проще (дешевле по ресурсам) чем выбрать скорость для каждой точки напрямую из таблицы? К справке: расстояние указывается в формате: 10615.634 а скорость для каждой точки в формате 4,55 так как мы быстрее 9,99 даже теоретически не перемещаемся.... у меня нет опыта по выборкам и вычислениям, просто кое какие мысли на счет скорости в БД. Или это реально сильно замедляет работу БД? Мне кажется тут есть над чем подумать...
Запросы типа покажи спортсменов такой то скорости практически не нужны ни на данном этапе ни на этапе завтрашнего дня. может позже.

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

тут ситуация видится так:
1. У тренера группа из произвольного числа спортсменов от 1 до ,,,15 хотя это уже излишне. у каждого свое устройство. Устройство не передается в ходе текущей тренировки от спортсмена к другому спортсмену. Т.е. устройство записывает круг и трекпоинт индивидуально для каждого спортсмена. Т.е. по сути тренировка у каждого спортсмена индивидуально, а вот к разным индивидуальным тренировкам в одно время может присоединиться тренер - вот и получится группа спортсменов, так что с точки зрения системы думаю пункт 1 как у вас и не требует изменений. А групповую принадлежность формировать другими способами по той причине что тут кавардак... седня спортсмен у одного тренера завтра у другого после завтра тренер помер, снова новый тренер.... как то так.

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

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

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

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

Однако, всё это не играет роли, если ваши приборы не умеют фиксировать две точки за одну секунду.

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

[sash-kan]

возможность выделить на этом графике кусок

кстати, у garmin-а это реализовано через веб-интерфейс?
наверно, на жабе, да?
я, честно говоря, не представляю, как это можно сделать жабаскриптом, впрочем я и не настоящий сварщик·

[sash-kan]

кстати, при запросах к таблице замеров (trackpoints), как я понимаю, чаще всего будут запрашиваться наборы замеров (весь круг или только часть — не важно), а не единичные записи·

Да так как запрашивать для построения графика только одну точку ну не слишком будет ... поэтому чтобы построиь график с максимальной гранулярностью в одну секунду надо делать как вы предлагаете, т.е. запрос на пару lid+время с такого по такое - для построения части круга, запрос на весь круг может как то проще типа все точки, соответствующие lid (не в SQL так как пока не сильно разбираюсь и написание элементарного комбинированного запроса для меня пока сложно, изучаю на примере PhPMyAdmin..)

ну, я пока писал, забыл про вторую половину мысли:
индекс по меткам времени (отдельный или составной) обязательно нужен потому, что строки нужно получать в порядке возрастания этих меток (select ... order by time_field)·
если индекса не будет, то такой select будет гораздо сильнее нагружать сервер бд·

[sash-kan]

каждый пятый ID

ни стандарт sql, ни (известные мне) реализации рсубд (а реализаторы стремятся расширить стандарт кто во что горазд) не позволяют сделать такое простым select-ом·
но существуют обходные многоэтажные пути, к тому же, скорее всего, специфичные для конкретной реализации·
например, для mysql: http://www.webveteran.com/blog/web-coding/...ery-nth-record/

upd. но для данной конкретной задачи можно сделать попроще, без многоэтажности·
примерно так:
select ... where ... and time_field % 5 = 0 ... ;
возможно, понадобится приведение time_field к какому-нибудь целочисленному типу (тут зависит ещё от того, какого именно типа вы сделаете этот столбец; надеюсь, не строкового (улыбка))·

[sash-kan]

При необходимости скорость можно вычислить, причём это вычисление будет иметь копеечную стоимость. Т.е. мы практически не затратим на него времени, по сравнению со всем остальным. Как я уже говорил, не нужно в БД хранить лишние и ненужные данные.

учитывая, что:
1. скорость требуется при каждой выборке (по крайней мере при подавляющем большинстве, насколько я представляю себе картину)
2. для вычисления скорости требуются данные не из одной строки, а ещё и из «некой предыдущей»

я думаю, расчёт скорости во время парсинга и сохранение её в таблице замеров будет вполне приемлемым компромиссом между количеством ненужных вычислений, излишней информацией в базе данных и удобством разработки и внесения последующих изменений/дополнений в программу·

[drBatty]

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

всё правильно. Я смотрел формулу1 - там круги совсем не круглые, и ничего, считают как-то :-) "Расстояние" это путь, проплытый вашим гребцом, от точки старта. Разве не так?

Т.е. если я правильно вас понял выбрать 7200 параметров о расстоянии и потом провести расчет для 7200 точек на стороне PHP намного проще (дешевле по ресурсам) чем выбрать скорость для каждой точки напрямую из таблицы?

наверное да, хотя-бы потому, что вам совсем не обязательно выбирать все 7200 точек, достаточно только нужных + ещё одна. Ведь для вычисления скорости необходимо и достаточно только расстояния между точками, и времени между ними. Если для графика вам надо 100 точек, то для скорости в каждой точке надо сделать выборку в 101у точку.

Или это реально сильно замедляет работу БД?

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

Запросы типа покажи спортсменов такой то скорости практически не нужны ни на данном этапе ни на этапе завтрашнего дня. может позже.

ну вот как надо будет, тогда и введёте. И то, не факт, что это будет _надо_, дело в том, что MySQL умеет не только делать выборки, но и считать. И ещё не факт, что MySQL считает медленнее, чем выбирает.

А групповую принадлежность формировать другими способами по той причине что тут кавардак... седня спортсмен у одного тренера завтра у другого после завтра тренер помер, снова новый тренер.... как то так

В любом случае, как я понимаю, в одной тренировке участвуют несколько спортсменов, и возможно, следует использовать отношение "многие ко многим". А может быть и нет. Всё зависит от того, является-ли "тренеровка с одним тренером и многими спортсменами" для вас единой и важной сущностью, или вас результаты по _тренировкам_ не интересуют, и важнее индивидуальный зачёт. Если последнее, то всё норм, и можно считать что одна тренировка являются для нас просто 10ю обособленными "тренировками", которые просто проводятся в одно время, в одном месте, и с одним тренером.

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

я тоже так думаю.

каждый пятый ID

ни стандарт sql, ни (известные мне) реализации рсубд (а реализаторы стремятся расширить стандарт кто во что горазд) не позволяют сделать такое простым select-ом·

можно добавить поле типа BOOL, которое равно 1 только для каждых пятых ID. Тогда можно сделать выборку простым селектом. ИМХО это будет довольно быстро (если конечно у этого поля есть индекс).

но существуют обходные многоэтажные пути, к тому же, скорее всего, специфичные для конкретной реализации·
например, для mysql: http://www.webveteran.com/blog/web-coding/...ery-nth-record/

что-то лично меня не вдохновляет этот костыль - тогда уж проще всю выборку прочитать, а потом брать каждую пятую строку средствами php. ИМХО это будет быстрее и проще. Ну и переносимей.

[sash-kan]

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

звучит разумно·
но есть дополнения:
1. в дальнейшем разработчику/пользователям может захотеться более одной «особости»
2. возможно, «особости» могут быть разными для разных пользователей одних и тех же данных (у спорстмена одна, у тренера — другая, у … гхм … ну, например, врача команды — третья)·
upd. а ещё тренеров может быть больше, чем один·

[drBatty]

1. скорость требуется при каждой выборке (по крайней мере при подавляющем большинстве, насколько я представляю себе картину)
2. для вычисления скорости требуются данные не из одной строки, а ещё и из «некой предыдущей»

я думаю, расчёт скорости во время парсинга и сохранение её в таблице замеров будет вполне приемлемым компромиссом

1. согласен.
2. а некую предыдущию мы только-что считали - её искать не надо. Это нужно только для первой точки, и т.к. точек много, то разницы никакой нет.
Но в принципе да, можно и ввести скорость в отдельное поле. Получится своеобразное "кеширование". ИМХО и вреда, и пользы от него немного, потому вопрос не является критичным. Кроме того, точки _никогда_ не меняются, потому и скорость тоже можно вычислить один раз. (хотя одно сэкономленное деление и стОит копейки).

[sash-kan]

но есть дополнения:
1. в дальнейшем разработчику/пользователям может захотеться более одной «особости»
2. возможно, «особости» могут быть разными для разных пользователей одних и тех же данных (у спорстмена одна, у тренера — другая, у … гхм … ну, например, врача команды — третья)·
upd. а ещё тренеров может быть больше, чем один·

Stasroot1
не принимайте эти размышления близко к сердцу·
а то так можно скромную программу для записи дисков превратить в цуп (прецеденты уже почти были)·
вы разработчик — вам принимать решение о компромиссе между фичастостью и простотой·

[drBatty]

1. в дальнейшем разработчику/пользователям может захотеться более одной «особости»
2. возможно, «особости» могут быть разными для разных пользователей одних и тех же данных (у спорстмена одна, у тренера — другая, у … гхм … ну, например, врача команды — третья)·

ИМХО 32 поля типа BOOL вполне себе упакуются в одно число, и не будут занимать больше места и больше времени, чем одна такая переменная. ЕМНИП мануалы к MySQL как раз и рекомендуют уменьшать возможный диапазон, до ENUM, а ещё лучше до BOOL, что-бы работало быстрее. К тому-же BOOL концептуально более простое поле - по нему невозможна сортировка, т.е. в отличие от любых других полей, индекс к BOOL получается более простым. (если конечно он NOT NULL)

[sash-kan]

а некую предыдущию мы только-что считали - её искать не надо

вы не процитировали вторую часть, где есть слова:

удобством разработки и внесения последующих изменений/дополнений в программу

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

[sash-kan]

drBatty
ещё одно соображение по поводу сложности/простоты:
в случае вычисления скорости «на лету», для определённого отрезка круга (lap-а) невозможно будет правильно вычислить скорость для первой точки этого отрезка·
потребуется усложнять алгоритм, либо выбирая «предыдущую» точку, либо отбрасывая первую (и выводить данные для точек, начиная лишь со второй)·
upd. да и при выборке информации об одной конкретной точке тоже придётся усложнять, и делать select для этой _и_ «предыдущей» точки·

[Stasroot1]

возможно, понадобится приведение time_field к какому-нибудь целочисленному типу (тут зависит ещё от того, какого именно типа вы сделаете этот столбец; надеюсь, не строкового (улыбка))·

Естественно не строковый. :-)

Вечером все перечитаю, вынужден убегать на тренировку у меня сегодня КПД...

[drBatty]

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

да тут вопрос на самом деле спорный, что проще, а что сложнее. Я пока вижу скорость только в "облачке", которое рисуется явно на стороне клиента. Да ещё и в км/ч. Может оно там-же и считается? Ну а если и не там, то я его буду искать в коде, где-то в генерации графика, или там данных для построения графика. Ну это конечно моё ИМХО. Искать расчёт скорости в парсинге входных данных мне придёт уже во вторую очередь, если конечно эта скорость нужна _только_ в графиках. Если эта скорость каким-то боком используется в каких-то статистиках - вопрос иной.

в случае вычисления скорости «на лету», для определённого отрезка круга (lap-а) невозможно будет правильно вычислить скорость для первой точки этого отрезка·
потребуется усложнять алгоритм, либо выбирая «предыдущую» точку, либо отбрасывая первую (и выводить данные для точек, начиная лишь со второй)·
upd. да и при выборке информации об одной конкретной точке тоже придётся усложнять, и делать select для этой _и_ «предыдущей» точки·

а вы похоже давно не рисовали графиков средствами php ;-)
нам по любому придётся
1. сделать выборку нужных N точек
2. рассчитать среднюю абсциссу и среднюю ординату
3. масштабировать и абсциссу и ординату и округлить координаты к целым
4. нарисовать N-1 отрезков между соседними точками. Причём, в тех картинках, которые представленны выше, отрезками не отделаешься - их надо интерполировать многочленом 2-3й степени(т.е. по 3-4м соседним точкам), и рассчитать все промежуточные точки, для того, что-бы график получился плавным, а не угловатым.
Как видите, если на шаге №1 мы сделаем выборку в N+1 точек, это ничего не изменит. Ну и лишнее деление тоже погоды не сделает.

[sash-kan]

так как мы быстрее 9,99 даже теоретически не перемещаемся

из спортсменов с вами не согласятся как минимум спринтеры, яхтсмены и велосипедисты·

[sash-kan]

а вы похоже давно не рисовали графиков средствами php

вообще ни разу·
зато вижу «цифру в облачке» и понимаю, что она не из астрала появляется «на стороне клиента»·

а вы похоже давно не рисовали графиков средствами php

кстати, насколько понимаю, Stasroot1 тоже не будет «рисовать графиков средствами php»·
что-то там ему насоветовали выше·
то ли библиотеку gd, то ли ещё что-то·

[drBatty]

из спортсменов с вами не согласятся как минимум спринтеры, яхтсмены и велосипедисты·

а... какая разница? в DOUBLE и сверхсветовая скорость влезет.

вообще ни разу·

вот именно (:

зато вижу «цифру в облачке» и понимаю, что она не из астрала появляется «на стороне клиента»

она появляется из двух соседних точек. А на какой стороне - не очень и важно на самом деле.

кстати, насколько понимаю, Stasroot1 тоже не будет «рисовать графиков средствами php»·
что-то там ему насоветовали выше·
то ли библиотеку gd, то ли ещё что-то·

а я вот тут недавно рисовал, и именно с помощью gd, вот по этому мануалу: http://ru2.php.net/manual/ru/book.image.php
Эта библиотека рисует прямые линии, точки и т.д., но шаги №1, 2, 3, и 4 из моего поста нужно делать самостоятельно. Ну не умеет эта либа масштабировать и уж тем более интерполировать. Кстати, она рисует только статичные PNG картинки, и ни о каких "облачках" ессно речи нет. Лично я решил проблему "облачков" очень просто - я нарисовал 2 разноцветных графика, первый для одного параметра, второй для другого.