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

[Stasroot1]

это как? (я не настоящий сварщик^w веб-разработчик)

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

ActiveX
Adobe Flash, Adobe Flex
Java
JavaScript
Silverlight

одно дело - выделить и вставить цитату, как я только-что сделал JavaScript'ом, совсем другое - нарисовать график.
Учтите также тот факт, что программа на стороне пользователя является потенциально опасной, и потому всегда огорожена и сильно ограничена в возможностях, это тоже не добавляет производительности, а как раз наоборот. На стороне сервера никаких ограничений нет. Ну и наконец, не забудьте о мобильных устройствах - моя мобила не всякую страничку осилит, а уж такое...

Спасибо, ваше мнение ценно. но мобильные телефоны (пока) точно идут лесом так как дисплеи маленькие и графики строить на них исключительно для ознакомления. Т.е. основная задача в графиках - доскональное изучение... на телефоне досконально по моему не изучить, хотя нет, если приближать картинку только. но точно не на моем samsung-е 5-и летней давности. :-)

Какие примерно могут потребоваться ресурсы от серверной части если всю обработку выполнять на стороне сервера? Загрузка примерна такая по началу: 20 человек одновременно смотрят тренировки своих спортсменов. Эти 20 - тренеры. У каждого реально сейчас есть по три-четыре устройства, скорее всего тренер сможет смотреть и сравнивать в один момент не более двух спортсменов, соответственно: 20*2=40 Графиков в момент + сами спортсмены самостоятельно себя анализируют ... итого спортсменов 20*4=80 графиков в момент. Далее Всего пользователей в момент получается: 80+40=120. Итого надо построить в момент 120 графиков на стороне сервера и отдать эти графики в виде картинок.... Учитываем среднее количество секунд на график тренировки: 3600+1800=5400. Какого размера будет получаться график с такой атомарностью? В принципе можно задавать степень атомарности с шагом в 5 секунд, соответственно получиться: 1800 точек для построения, далее 540... Как тогда осуществить выборку определенного участка тренировки и отобразить ее? Фильтр по секундам, с последующим фильтром для уточнения границ графика?

Интересно ваше мнение по поводу изложенных мыслей, если конечно это не затруднит и представится возможным. С уважением.

[drBatty]

Какие примерно могут потребоваться ресурсы от серверной части

к сожалению, я не могу на это ответить. ИМХО не слишком и много.

Как тогда осуществить выборку определенного участка тренировки и отобразить ее?

Очень просто: запросом к СУБД вы получите массив с данными, ну а потом его нарисуете. Постоянно рисовать 120 графиков вовсе не обязательно, достаточно рисовать их по запросу. Или вы хотите, что-бы графики обновлялись в реальном времени, т.е. ползли по экранам клиента? Тогда их логично передавать клиенту вертикальными полосками, или даже действительно, заставить браузер клиента всё это рисовать самостоятельно...

Я не знаю, localhost у вас есть, пробуйте...

ЗЫЖ

мобильные телефоны (пока) точно идут лесом так как дисплеи маленькие и графики строить на них исключительно для ознакомления

не такие уж и маленькие экраны в мобильных устройствах. Да и потом, ИМХО спортсменам куда как удобнее например нетбук, а не стационарный десктоп. Всё дело в том (хотя возможно я и ошибаюсь, ибо опыта у меня в таких приложениях немного), что построение графика на стороне клиента потребует намного больше ресурсов, чем на стороне сервера. Т.е. на сервер это будет сравнительно небольшая нагрузка.

[Stasroot1]

Какие примерно могут потребоваться ресурсы от серверной части

к сожалению, я не могу на это ответить. ИМХО не слишком и много.

Как тогда осуществить выборку определенного участка тренировки и отобразить ее?

Очень просто: запросом к СУБД вы получите массив с данными, ну а потом его нарисуете. Постоянно рисовать 120 графиков вовсе не обязательно, достаточно рисовать их по запросу. Или вы хотите, что-бы графики обновлялись в реальном времени, т.е. ползли по экранам клиента? Тогда их логично передавать клиенту вертикальными полосками, или даже действительно, заставить браузер клиента всё это рисовать самостоятельно...

Я не знаю, localhost у вас есть, пробуйте...

ЗЫЖ

мобильные телефоны (пока) точно идут лесом так как дисплеи маленькие и графики строить на них исключительно для ознакомления

не такие уж и маленькие экраны в мобильных устройствах. Да и потом, ИМХО спортсменам куда как удобнее например нетбук, а не стационарный десктоп. Всё дело в том (хотя возможно я и ошибаюсь, ибо опыта у меня в таких приложениях немного), что построение графика на стороне клиента потребует намного больше ресурсов, чем на стороне сервера. Т.е. на сервер это будет сравнительно небольшая нагрузка.

Спасибо. В общем есть пища для размышлений. Графики в реальном времени невозможны по той причине что данные о тренировке заливаются на сайт постфактум один рас и навсегда, а дальше уже работа с этими данными. Скорее всего правильнее отобразить общий график со шкалой по 5 минут, и предоставить форму фильтра участка графика, например показать с 15 минуты по 20-ю, график отрисовывается подробнее и шкала становиться поминутной. Снова фильтр с возможностью отфильтровать с шагом в 30 секунд и так далее с перерисовкой графика. Как рас такого рода фильтры и перерисовки я и предполагал делать на стороне клиента, основываясь на том предположении, что на стороне клиента проще ибо: эти 120 графиков - это частично повторяющиеся графики, и из них - 80 графиков уникальны, так как каждый спортсмен - уникум. Каждый спортсмен в среднем будет инициировать построение для себя 10*4=40 графиков за сессию , итого задание на отрисовку графиков только для спортсменов: 120*40=4800 уникальных графиков, понятное дело, часть из них можно класть в кэш таблицу опять же в виде данных так как картинка займет скорее всего много места, и даже не в виде данных как таковых а в виде указаний с какого по какое место отобрать данные из основной таблици данных о трекпоинтах.... ушел думать. Думать над схемой и логикой. Программная реализация для меня это самое сложное, надеюсь на помощь со стороны сообщества.

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

Еще рас спасибо за ответы.

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

[Stasroot1]

Я тут интересную новость нашел: [NIXP] Tesseract — JavaScript-библиотека для визуализации больших массивов данных там в описании есть ссылка на тэстовую страничку где показывается что с этой штукой можно делать. Там про библиотеку с помощью которой можно строить графики и фильтровать их на стороне клиента как я понял.

[sash-kan]

Может как то переименовать название темы так как она уже сильно ушла от заданной в начале.

так переименуйте (отредактировав первый пост)·

[drBatty]

Думать над схемой и логикой. Программная реализация для меня это самое сложное

ИМХО у вас цифры лишние. Какая разница, сколько там у вас графиков? Сделайте 1, а потом 2. И там уже будет понятно, как сделать 100500.

По поводу отрисовки графика вертикальными полосками на стороне клиента...

вы меня не поняли - смысла нет на стороне клиента отрисовывать полоски. А если графики статические, то вообще нет никакого смысла ни в каких полосках. Сделайте хоть какие-то, потом будете думать о прозрачных верхушках. Уверен, у вас будут другие проблемы.

1. начните с создания БД, забейте туда как-нибудь какие-нибудь цифры.
2. отразите числа из БД в виде таблицы
3. отразите таблицу в виде графика

[Stasroot1]

Думать над схемой и логикой. Программная реализация для меня это самое сложное

ИМХО у вас цифры лишние. Какая разница, сколько там у вас графиков? Сделайте 1, а потом 2. И там уже будет понятно, как сделать 100500.

По поводу отрисовки графика вертикальными полосками на стороне клиента...

вы меня не поняли - смысла нет на стороне клиента отрисовывать полоски. А если графики статические, то вообще нет никакого смысла ни в каких полосках. Сделайте хоть какие-то, потом будете думать о прозрачных верхушках. Уверен, у вас будут другие проблемы.

1. начните с создания БД, забейте туда как-нибудь какие-нибудь цифры.
2. отразите числа из БД в виде таблицы
3. отразите таблицу в виде графика

Да проблем будет думаю предостаточно. И работать лучше конечно поэтапно.

Поэтому начну как вы и говорите с первого этапа...
Делюсь своими соображениями, в SQL не очень разбираюсь, и вот в меру того что я там понимаю сделал вот такую базу данных: 4-е таблицы: в одной данные о тренировке, во второй данные о кругах, в третьей данные о трекпоинтах, в четвертой данные для сопоставления номера тренировки номерам кругов в системе и номеру круга в конкретной тренировке. Таблицы InnoDB с применением внешних ключей, с ними как рас сложно, я не совсем понимаю, правильно ли я их понимаю эти внешние ключи. Привлекаю этот вариант так как когда будут реальные данные, чтобы была целостность данных, так, чтобы если тренировку удалил из системы, то все данные о кругах и трекпоинтах тоже удалились бы. Удаление круга при этом не должно вести к удалению тренировки и удалению трекпоинтов из других кругов. И так далее. Прикладываю файл sql для того, чтобы его можно было скачать и посмотреть, а так же вывожу sql сюда.

Прежде чем забивать туда вручную данные, массив данных не малый, Мне бы хотелось, чтобы вы глянули мою БД, на предмет избыточности и логичности. А так же правильности применения/понимания в моем случае механизма InnoDB.

С уважением.

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

-- phpMyAdmin SQL Dump
-- version 3.3.7deb7
-- http://www.phpmyadmin.net
--
-- Хост: localhost
-- Время создания: Апр 03 2012 г., 09:58
-- Версия сервера: 5.1.61
-- Версия PHP: 5.3.3-7+squeeze8

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;

--
-- База данных: `garmin`
--

-- --------------------------------------------------------

--
-- Структура таблицы `Garmin_Activities`
--

CREATE TABLE IF NOT EXISTS `Garmin_Activities` (
  `ID_training` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Уникальный номер тренировки в системе, он же соответствует индексному полю в таблице Garmin_Laps_training, поле уникально для каждой тренировки',
  `ProductID_device` text COLLATE utf8_bin NOT NULL COMMENT 'Идентификатор продукта Garmin примененного для создания записи о тренировке',
  `UnitId_device` int(10) NOT NULL COMMENT 'Идентификатор устройства in Garmin',
  `Name_device` text COLLATE utf8_bin NOT NULL COMMENT 'Название устройства Garmin',
  `Laps_counter` int(3) NOT NULL COMMENT 'Количество совершенных кругов за тренировку по данному идентификатору.',
  `Activity_Sport` text COLLATE utf8_bin NOT NULL COMMENT 'Вид спорта на тренировке, велосипед, бег и т.д.',
  PRIMARY KEY (`ID_training`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Сводная системная таблица всех тренировок' AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `Garmin_Activities`
--


-- --------------------------------------------------------

--
-- Структура таблицы `Garmin_Activities_Laps`
--

CREATE TABLE IF NOT EXISTS `Garmin_Activities_Laps` (
  `SyncTrainingLaps_ID` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Уникальный номер соответствия тренировки и ее кругов.',
  `Number_training_ID` int(11) NOT NULL COMMENT 'Номер тренировки в системе',
  `Lap_number_sys_ID` int(11) NOT NULL COMMENT 'Номер круга в системе',
  `Lap_number_inTrainingID` int(11) NOT NULL COMMENT 'Номер круга внутри Тренировки',
  PRIMARY KEY (`SyncTrainingLaps_ID`),
  UNIQUE KEY `Number_training_ID` (`Number_training_ID`),
  UNIQUE KEY `Lap_number_sys_ID` (`Lap_number_sys_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Таблица соответствия Тренировки и ее Кругов.' AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `Garmin_Activities_Laps`
--


-- --------------------------------------------------------

--
-- Структура таблицы `Garmin_Laps`
--

CREATE TABLE IF NOT EXISTS `Garmin_Laps` (
  `ID_trainings_Lap_inSys` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Индекс совпадает с индексом в таблице Activities И соответсвует одной тренировке как минимум из одного круга, идентификатор указывает на набор кругов по сути',
  `StartTime_Lap` text COLLATE utf8_bin NOT NULL COMMENT 'Время начала круга.',
  `TotalTimeSeconds_onLap` decimal(8,3) NOT NULL COMMENT 'Продолжительность круга',
  `AverageHeartRateBpm_onLap` tinyint(3) DEFAULT NULL COMMENT 'Средний пульс на круге, может быть пустым если пульсометр был не одет.',
  `MaximumHeartRateBpm_onLap` tinyint(3) DEFAULT NULL COMMENT 'Максимальное значение пульса на круге. Может быть Null если датчик отсутствовал.',
  `DistanceMeters_onLap` decimal(13,6) NOT NULL COMMENT 'Дистанция круга',
  `AverageSpeed_onLap` decimal(6,3) NOT NULL COMMENT 'Средняя скорость на круге',
  `MaximumSpeed_onLap` decimal(9,6) NOT NULL COMMENT 'Максимальная скорость на коуге',
  `Intensity_onLap` text COLLATE utf8_bin NOT NULL COMMENT 'Интенсивность на круге, правда пока не очень понятно для чего это....',
  PRIMARY KEY (`ID_trainings_Lap_inSys`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Таблица с данными о кругах и сопутствующих кругу данных' AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `Garmin_Laps`
--


-- --------------------------------------------------------

--
-- Структура таблицы `Garmin_Trackpoints`
--

CREATE TABLE IF NOT EXISTS `Garmin_Trackpoints` (
  `Lap_Trackpoints_number_ID` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер набора трекпонитов связанный с уникальным номером круга в системе.',
  `Trackpoint_Time` text COLLATE utf8_bin NOT NULL COMMENT 'Время трекпоинта',
  `Trackpoint_LatitudeDegrees` decimal(9,7) NOT NULL COMMENT 'Указывает на широту точки с точностью до 7 знаков после запятой',
  `Trackpoint_LongitudeDegrees` decimal(9,7) NOT NULL COMMENT 'Долготоа трекпоинта',
  `Trackpoint_DistanceMeters` decimal(10,3) NOT NULL COMMENT 'Расстояние в метрах от начала трека до текущего трекпоинта.',
  `Trackpoint_HeartRateBpm` tinyint(3) DEFAULT NULL COMMENT 'Пульс на данном трекпоинте',
  `Trackpoint_in_treaning_ID` int(5) NOT NULL COMMENT 'Номер трэкпоинта внутри текщего круга.',
  PRIMARY KEY (`Lap_Trackpoints_number_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Таблица с трекпоинтами' AUTO_INCREMENT=1 ;

--
-- Дамп данных таблицы `Garmin_Trackpoints`
--


--
-- Ограничения внешнего ключа сохраненных таблиц
--

--
-- Ограничения внешнего ключа таблицы `Garmin_Activities_Laps`
--
ALTER TABLE `Garmin_Activities_Laps`
  ADD CONSTRAINT `Garmin_Activities_Laps_ibfk_1` FOREIGN KEY (`Number_training_ID`) REFERENCES `Garmin_Activities` (`ID_training`) ON DELETE CASCADE ON UPDATE NO ACTION;

--
-- Ограничения внешнего ключа таблицы `Garmin_Laps`
--
ALTER TABLE `Garmin_Laps`
  ADD CONSTRAINT `Garmin_Laps_ibfk_1` FOREIGN KEY (`ID_trainings_Lap_inSys`) REFERENCES `Garmin_Activities_Laps` (`Lap_number_sys_ID`) ON DELETE CASCADE ON UPDATE NO ACTION;

--
-- Ограничения внешнего ключа таблицы `Garmin_Trackpoints`
--
ALTER TABLE `Garmin_Trackpoints`
  ADD CONSTRAINT `Garmin_Trackpoints_ibfk_1` FOREIGN KEY (`Lap_Trackpoints_number_ID`) REFERENCES `Garmin_Laps` (`ID_trainings_Lap_inSys`) ON DELETE CASCADE ON UPDATE NO ACTION;

[drBatty]

Таблицы InnoDB с применением внешних ключей, с ними как рас сложно, я не совсем понимаю, правильно ли я их понимаю эти внешние ключи

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

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

причём тут InnoDB??

Прежде чем забивать туда вручную данные, массив данных не малый, Мне бы хотелось, чтобы вы глянули мою БД, на предмет избыточности и логичности. А так же правильности применения/понимания в моем случае механизма InnoDB.

всё неправильно.
Вам надо спроектировать вашу БД так, что-бы её было удобно удалять/вставлять/просматривать. Причём на данном этапе всякие внутренние типы вас меньше всего волновать должны. Проблема в том, что я не знаю точно постановку задачи, и не очень хочу в неё вдаваться :-)
А вот вы - знаете. Но у вас нет опыта. Потому единственный возможный для вас метод (ну кроме покупки готового движка) - получить требуемый опыт. Есть только один путь: это создавать таблицы, и писать к ним код. Если что-то не получается, то одно из двух:
1. вы не знаете как составить простой (а значит правильный и быстрый) SQL запрос.
2. ваша БД спроектирована неудачно.
В любом случае вам следует обратится к _общей_ литературе по реляционным СУБД, т.е. изучать "просто SQL", а не конкретную реализацию таблиц MySQL. Как оно там внутри устроено - вопрос десятый на самом деле. Не вижу причин, которые помешают вам сменить тип таблиц, если оно будет надо. Или даже вообще сменить тип СУБД, к примеру может вам лучше будет SQLite, или ещё что-то(может PostgreSQL). SQL оно и в Африке SQL, и зная общие принципы нетрудно будет в этом всём разобраться.

PS: совсем не обязательно вводить 100500 значений. Даже наоборот - не нужно. Достаточно десятка, что-бы понять смысл всего этого. Просто надо помнить, что в RL их будет 100500, и например перебирать их по одному будет дооолгооо. А вот одним запросом - быстро и хорошо. Ну и совсем хорошо, если они удачно проиндексированы, но это не важно, ибо индекс можно в любой момент создать/удалить.

[taaroa]

предлагаю перенести часть темы туда → Проекты Нашего Форума

[sash-kan]

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

как мне кажется, что-то здесь лишнее·

давайте с архитектурной точки зрения рассмотрим структуру базы·
1. какие сущности должны храниться в базе?
насколько я понимаю, примерно такие:
1.1. пользователи
1.2. тренировки
1.3. круги
1.4. замеры (trackpoints)
сущности связаны ключами отношением один-ко-многим (у каждого пользователя — свои тренировки, у каждой тренировки — свои круги, у каждого круга — свои замеры)·
пользователи уже есть (в drupal-е или что вы там собираетесь использовать в качестве фундамента), поэтому остаётся три сущности·
2. нужны ли в предложенном списке отдельные сущности для тренировок и кругов?
мне кажется, это просто специфика программы конкретного устройства, которым вы располагаете·
у вас нет возможности получить информацию из принципиально других устройств, служащих тем же целям? (наверняка ведь "garmin навигатор" совсем не уникален)
3. нужна ли сущность "устройство" (именно как отдельная сущность)? и нужна ли _вообще_ информация об устройстве?

[Stasroot1]

Таблицы InnoDB с применением внешних ключей, с ними как рас сложно, я не совсем понимаю, правильно ли я их понимаю эти внешние ключи

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

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

причём тут InnoDB??

Прежде чем забивать туда вручную данные, массив данных не малый, Мне бы хотелось, чтобы вы глянули мою БД, на предмет избыточности и логичности. А так же правильности применения/понимания в моем случае механизма InnoDB.

всё неправильно.
Вам надо спроектировать вашу БД так, что-бы её было удобно удалять/вставлять/просматривать. Причём на данном этапе всякие внутренние типы вас меньше всего волновать должны. Проблема в том, что я не знаю точно постановку задачи, и не очень хочу в неё вдаваться :-)
А вот вы - знаете. Но у вас нет опыта. Потому единственный возможный для вас метод (ну кроме покупки готового движка) - получить требуемый опыт. Есть только один путь: это создавать таблицы, и писать к ним код. Если что-то не получается, то одно из двух:
1. вы не знаете как составить простой (а значит правильный и быстрый) SQL запрос.
2. ваша БД спроектирована неудачно.
В любом случае вам следует обратится к _общей_ литературе по реляционным СУБД, т.е. изучать "просто SQL", а не конкретную реализацию таблиц MySQL. Как оно там внутри устроено - вопрос десятый на самом деле. Не вижу причин, которые помешают вам сменить тип таблиц, если оно будет надо. Или даже вообще сменить тип СУБД, к примеру может вам лучше будет SQLite, или ещё что-то(может PostgreSQL). SQL оно и в Африке SQL, и зная общие принципы нетрудно будет в этом всём разобраться.

PS: совсем не обязательно вводить 100500 значений. Даже наоборот - не нужно. Достаточно десятка, что-бы понять смысл всего этого. Просто надо помнить, что в RL их будет 100500, и например перебирать их по одному будет дооолгооо. А вот одним запросом - быстро и хорошо. Ну и совсем хорошо, если они удачно проиндексированы, но это не важно, ибо индекс можно в любой момент создать/удалить.

Да таблицы по умолчанию сделать конечно проще, но почему я привлекаю именно InnoDB? Так как полагаю, что смогу построить транзакционный запрос к БД, и если что то пойдет не так как надо, то транзакция откатиться и данные будут не записаны, целостность данных будет сохранена. Естественно транзакционный запрос мне построить пока сложнее чем множество запросов к разным таблицам простого типа, таких как INSERT UPDATE DELETE..., А так же таблицы InnoDB позволят удалять данные каскадом, и если что то не пошло как положено, то данные так же не будут удалены, т.е. целостность будет сохранена.
Просто в моем случае если вася в итоге удалит свою тренировку, и по какой то причине (например комп с PHP на сервере у хостера завис) PHP код будет выполнен не полностью, и часть команд в SQL отправиться, часть нет, в итоге например данные о тренировке удаляться, а данные о кругах, пренадлежавших этой тренировке остануться в БД как мусор, и хуже того, могут стать частью тренировки другого пользователя, или того же пользователя, но частью следующей тренировки, что не допустимо. Ясное дело, что проверку целостности данных каждый рас можно вешать на PHP, но почему бы не доверить эту работу серверу баз данных.

MySQL так как это стандарт в моей системе к которой в последствии буду адаптировать механизм, т.е. к Drupal-у.

Внутренние типы меня на данном этапе почти не волнуют, если я сомневаюсь во внутреннем типе, оставляю как есть, а вот если точно знаю, что у меня будет писаться число с запятой, а там еще 6 знаков, то можно и специально тип указать - своего рода проверка на уровне БД. Проверку на уровне PHP соответственно уже можно пропустить. Наверное.

По поводу количества тестовых записей. Понятное дело что писать туда массив из файла приведенного в начале теммы не разумно на данном этапе, туда надо писать данные о разных тренировках, с небольшим количеством кругов (1-3) и с не большим количеством трекпоинтов (3-5) вот и вырисовывается внушительный набор вводимых вручноую пока данных.

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

[Stasroot1]

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

как мне кажется, что-то здесь лишнее·

давайте с архитектурной точки зрения рассмотрим структуру базы·
1. какие сущности должны храниться в базе?
насколько я понимаю, примерно такие:
1.1. пользователи
1.2. тренировки
1.3. круги
1.4. замеры (trackpoints)
сущности связаны ключами отношением один-ко-многим (у каждого пользователя — свои тренировки, у каждой тренировки — свои круги, у каждого круга — свои замеры)·
пользователи уже есть (в drupal-е или что вы там собираетесь использовать в качестве фундамента), поэтому остаётся три сущности·
2. нужны ли в предложенном списке отдельные сущности для тренировок и кругов?
мне кажется, это просто специфика программы конкретного устройства, которым вы располагаете·
у вас нет возможности получить информацию из принципиально других устройств, служащих тем же целям? (наверняка ведь "garmin навигатор" совсем не уникален)
3. нужна ли сущность "устройство" (именно как отдельная сущность)? и нужна ли _вообще_ информация об устройстве?

По порядку.

1. Пользователи уже есть, да. Они в Drupal-e. Да сущьности связаны как дерево, один ко многим, вы правильно все понимаете.

2. Да специфика программы у каждого устройства есть (отличается между сериями устройств, т.е. разницу между разными устройствами серии garmin edge705 я не нашел, так же как и не нашел разницы между устройствами серии garmin 305, а вот разница между 705 и 305 есть) Специфика в том, что xml файлы с историей тренировок формируются чуть по разному и имеют разное расширение. А суть данных одинаковая. Эту проблему будем решать на уровне PHP разбором этих самых файлов, получением данных и отправке этих данных в соответствующие таблицы БД. По принципу: если файл с расширением *,a делаем так, если с расширением Б делаем так то, если иначе выводим сообщение о не поддержке такого формата, но это еще далеко, просто иметь ввиду.

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

Нужны ли в предложенном списке отдельные сущьности? Думаю да так как: спортсмен на разных тренировках может пользоваться разными устройствами, редко но такое бывает. Так же на основании этих данных в дальнейшем предполагаю проводить проверку подлинности устройства, т.е. за конкретным спортсменом крепиться конкретное устройство, и только с него он может заносить данные или крепиться несколько устройств. Тут еще надо поразмыслить, но скорее всего эти данные лучше хранить в специализированной таблице а не в таблице, например, про пользователя в системе Drupal. Но на данном этапе думаю часть данных о тренировке о круге можно для упрощения разработки исключить из набора необходимых данных, так сказать чтобы таблица была поменьше. Однако мне представляется возможным на уровне БД разрешить значение NULL на данном этапе, оставив сущьности в структуре БД и не удалять их из структуры предложенной мной чуть выше.

Однако у меня тоже есть сомнения по структуре, я например не очень представляю куда было бы логично записать данные о количестве кругов в тренировке, которое я вывел в отдельную таблицу, образовав тем самым дополнительную сущьность - уникальный круг в системе. Это я про таблицу: Garmin_Activities_Laps. Не появляется ли избыточность данных хранимых в БД, вроде нет, но и не совсем уверен в этом. Так же эту таблицу я привлекаю для как бы синхронизации что ли, Чтобы через эту таблицу проводить транзакционный запрос, т.е. в ней как бы собираются сводные данные (тренировка+круг+точка (точка не реализована)) Это для обеспечения целостности данных при внесении записи в таблицу о тренировке, а так же для предотвращения возможности внесения данных о круге или трекпоинте для не существующей в таблице о тренировках тренировки отдельным запросом SQL. Скорее всего я сильно усложняю задачу на данном этапе...

По второму пункту вроде все.

3. По этой части частично ответил во втором пункте. Добавляю: считаю что нужна так как не хочу отделять эту сущьность на уровень Drupal. Так как сначала хочу добиться работы отдельно от друпала и пока без примитивной пользовательской части, в последствии примитивненькую табличку соответствия пользователя и тренировки сделаем так, чтобы систему могли протестировать разные пользователи разных устройств уже в боевом режиме. Только потом адаптировать систему к Drupal. Думаю в этом мне смогут помочь члены сообщества Drupal как российского так и международного, слава богу с языком уже проблем почти нет. Разве что разговаривать на нем пока плохо получается, практики мало... :-( Извиняюсь за отход от темы.

Прикрепил на всякий случай файл с устройства Garmin 305 (как наручные часы) у меня к справке велокомпьютер считается (edge705).

Вот так как то постарался все описать что у меня в мозгах думается... Надеюсь не сильно запутанно. Спасибо за то, что принимаете участие и тратите на это свое драгоценное время. С уважением.

[sash-kan]

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

никуда не надо записывать, ибо это будет нарушение реляционной модели·
если эта цифра требуется, просто получаете count записей, удовлетворяющих условию (в предложенном мною дальше наброске: "select count(*) from l where tid=<ид.тренировки>;")

вот я примерно набросал ключевую информацию: https://docs.google.com/spreadsheet/ccc?key...VGtFdlViMTVWaUE
в таблицах перечислены только связующие поля·
названия таблиц и полей, конечно, условны, просто покороче выбрал·

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

особняком получается таблица с устройствами·
привязывать устройства имеет смысл, как я понимаю, к тренировкам (или надо предусмотреть ситуацию, когда в одной тренировке разные круги фиксируются разными устройствами? тогда foreign key did надо переместить в таблицу кругов)·

[Stasroot1]

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

никуда не надо записывать, ибо это будет нарушение реляционной модели·
если эта цифра требуется, просто получаете count записей, удовлетворяющих условию (в предложенном мною дальше наброске: "select count(*) from l where tid=<ид.тренировки>;")

вот я примерно набросал ключевую информацию: https://docs.google.com/spreadsheet/ccc?key...VGtFdlViMTVWaUE
в таблицах перечислены только связующие поля·
названия таблиц и полей, конечно, условны, просто покороче выбрал·

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

особняком получается таблица с устройствами·
привязывать устройства имеет смысл, как я понимаю, к тренировкам (или надо предусмотреть ситуацию, когда в одной тренировке разные круги фиксируются разными устройствами? тогда foreign key did надо переместить в таблицу кругов)·

По поводу нарушения реляционной модели... Предложенный вами вариант мне тоже очень понравился! Данные о количестве кругов в тренировке действительно лишние! Вот я и чувствовал что как то оно к избыточности тянет. Спасибо.

Ключевую информацию по ссылке сейчас посмотрю, очень интересен ваш подход.

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

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

Пошел по вашей ссылке, прочту, пойму, отпишусь.

[Stasroot1]

Пошел по вашей ссылке, прочту, пойму, отпишусь.

Посмотрел вроде все очень понятно, завтра попробую сделать используя предложенную вами структуру БД на своем компе и посмотреть еще рас.

У меня есть пара вопросов по структуре связанных с внешними ключами и первичными. Эти вопросы я оставил в том файле, на который вы дали мне ссылку, т.е. я его маленько отредактировал своими вопросами. Связаны они скорее с тем что я пока не до конца понимаю механизм ссылочной целостности и то, как он работает. Мне например ЧУВСТВУЕТСЯ, что при удалении из нашей БД записи о какой то тренировке (из таблицы t) все данные относящие ся к этой тренировке (tid) не будут удалены автоматом использующим возможности InnoDB. А так же не приведет ли удаление из таблицы u (пользователи users, в вашем документе не указана но предполагается) пользователя создавшего эту тренировку самой тренировки и данных к ней относящихся? Данные о его тренировке ДОЛЖНЫ ОСТАВАТЬСЯ В БД.

Пойду еще почитаю информацию относительно ссылочной целостности и реализации в InnoDB от MySQL5, а то плаваю слишком сильно...

[sash-kan]

при удалении из нашей БД записи о какой то тренировке (из таблицы t) все данные относящие ся к этой тренировке (tid) не будут удалены автоматом использующим возможности InnoDB. А так же не приведет ли удаление из таблицы u (пользователи users, в вашем документе не указана но предполагается) пользователя создавшего эту тренировку самой тренировки и данных к ней относящихся? Данные о его тренировке ДОЛЖНЫ ОСТАВАТЬСЯ В БД

в документации о foreign keys всё довольно подробно расписано·
как вы этот foreign key опишите, так и будет себя вести сервер·
описывать ключи можно прямо в команде create table (там есть примеры) или отдельно (уже после создания таблицы), как в выложенном вами ранее дампе (alter table имя add constraint …)·

Специфика в том, что xml файлы с историей тренировок формируются чуть по разному и имеют разное расширение. А суть данных одинаковая. Эту проблему будем решать на уровне PHP разбором этих самых файлов, получением данных и отправке этих данных в соответствующие таблицы БД. По принципу: если файл с расширением *,a делаем так, если с расширением Б делаем так то, если иначе выводим сообщение о не поддержке такого формата, но это еще далеко, просто иметь ввиду.

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

[Stasroot1]

Специфика в том, что xml файлы с историей тренировок формируются чуть по разному и имеют разное расширение. А суть данных одинаковая. Эту проблему будем решать на уровне PHP разбором этих самых файлов, получением данных и отправке этих данных в соответствующие таблицы БД. По принципу: если файл с расширением *,a делаем так, если с расширением Б делаем так то, если иначе выводим сообщение о не поддержке такого формата, но это еще далеко, просто иметь ввиду.

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

Я предполагал сделать так: пользователь системы загружает на сайт (в систему) файл с тренировкой. Он в нем совершенно не разбирается и даже посмотреть что там в этом файле зачастую не может, по этому мы сами принимаем файл в систему и средствами системы определив расширение запускаем парсер и данные отправляем в БД.

Ваш подход я так понял аналогичен по части загрузки файла пользователем и отличается в части парсинга... Т.е. по вашему мы сначала парсим файл и совсем не важно какое у него расширение, ведь они все по сути xml... Правильно я вас понял?

Такой подход вызывает у меня опасения связанные с отсутствием опыта в такого рода проектах, опасение в том, что в ходе парсинга НАВЕРНОЕ будет образовываться массив с данными и отличающимися в зависимости от названия модели устройства с разными именами элементов этого массива.
Например элемент про средний пульс в 705 устройстве записывается в теги:

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

<AverageHeartRateBpm>
<Value>118</Value>
</AverageHeartRateBpm>

а в устройстве 305 записывается так:

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

<Cadence>0</Cadence>

ноль так как пульсометр например на тренировке был не одет.

Просто размышления...

Сейчас сделаю БД описанную вами в документе по ссылке выше.

[drBatty]

Да таблицы по умолчанию сделать конечно проще, но почему я привлекаю именно InnoDB? Так как полагаю, что смогу построить транзакционный запрос к БД, и если что то пойдет не так как надо, то транзакция откатиться и данные будут не записаны, целостность данных будет сохранена.

ну я-бы не стал так беспокоится о сохранности данных: если у вас есть две таблицы A и B, причём записи в B привязаны к записям в A (т.е. в таблице B есть поле idA), то если вы удаляете запись в A №777, и после этого удаляете все записи в B с idA = 777, то даже в очень маловероятном случае зависания/отключения хостинга у вас останутся "сиротки" в B, которые вам совсем не помешают при доступе к B через A, ну и при доступе к B через B вы можете предварительно этих сироток почистить(после сбоя), или например просто их игнорировать. С другой стороны, я почему-то думаю, что InnoDB вам совсем не поможет при аварии. Всё равно БД наверняка побьётся, и вам придётся её восстанавливать ручками. ИМХО надёжнее всё равно обеспечить возможность существования "сироток", по той простой причине, что они у вас с намного большей вероятностью появятся из за ошибок в коде, а не из за аварий на сервере. Тоже самое касается и при доступе "многие ко многим", когда несколько элементов из A связаны с несколькими элементами из B через ещё одну таблицу C.

Всё вышесказанное - ИМХО. Может кто и поправит мой бред... Заранее благодарен.

[sash-kan]

Т.е. по вашему мы сначала парсим файл и совсем не важно какое у него расширение, ведь они все по сути xml... Правильно я вас понял?

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

[Stasroot1]

Т.е. по вашему мы сначала парсим файл и совсем не важно какое у него расширение, ведь они все по сути xml... Правильно я вас понял?

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

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

Набросал БД указав первичные ключи и уникальные. Тут я кажется ошибся... с уникальными ключами.
Делал запрос такой:

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

INSERT INTO `garmin2`.`trackpoints` (`pid` , `lid`)
VALUES ('1', '1'), ('2', '1')

Ошибка такая:

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

#1062 - Дублирующаяся запись '1' по ключу 'lid'

Т.е. для такого рода полей надо ставить не уникальное значение а просто INDEX? Без индекса нет возможности сделать вторичный ключ.

Сама структура БД в прикрепленном файле. Рядом файл с данными для БД.

[Stasroot1]

Да таблицы по умолчанию сделать конечно проще, но почему я привлекаю именно InnoDB? Так как полагаю, что смогу построить транзакционный запрос к БД, и если что то пойдет не так как надо, то транзакция откатиться и данные будут не записаны, целостность данных будет сохранена.

ну я-бы не стал так беспокоится о сохранности данных: если у вас есть две таблицы A и B, причём записи в B привязаны к записям в A (т.е. в таблице B есть поле idA), то если вы удаляете запись в A №777, и после этого удаляете все записи в B с idA = 777, то даже в очень маловероятном случае зависания/отключения хостинга у вас останутся "сиротки" в B, которые вам совсем не помешают при доступе к B через A, ну и при доступе к B через B вы можете предварительно этих сироток почистить(после сбоя), или например просто их игнорировать. С другой стороны, я почему-то думаю, что InnoDB вам совсем не поможет при аварии. Всё равно БД наверняка побьётся, и вам придётся её восстанавливать ручками. ИМХО надёжнее всё равно обеспечить возможность существования "сироток", по той простой причине, что они у вас с намного большей вероятностью появятся из за ошибок в коде, а не из за аварий на сервере. Тоже самое касается и при доступе "многие ко многим", когда несколько элементов из A связаны с несколькими элементами из B через ещё одну таблицу C.

Всё вышесказанное - ИМХО. Может кто и поправит мой бред... Заранее благодарен.

Я могу ошибаться но по моему сделать запрос на удаление записи N777 из таблици A проще чем сделать запрос на удаление из таблицы А а затем на удаление из таблицы Б соответствующих записям из А. По моему php кода будет меньше а значит вероятность совершить в нем ошибку уменьшается. К тому же зачастую php выполняется на одном сервере а БД на другом, это значит, что я как бы распределяю нагрузку между этими частями. Мне представляется что применение InnoDB не только позволит улучшить целостность данных, но и повысит производительность системы при больших нагрузках. Мне ПРЕДСТАВЛЯЕТСЯ более правильным использовать те возможности которые предоставляет БД, главное правильно ее спроектировать и правильно расставить ключи и действия по ним в случае удаления/обновления.

Если я ошибаюсь или заблуждаюсь, прошу меня поправить. Момент по количеству данных: одна 2-х часовая тренировка это 7200 записей только о трекпоинтах. Лично я делаю например примерно 5-6 часов тренировки. Я МС, думаю уровнем повыше делают поинтенсивнее и побольше, главное тут побольше, так как интенсивность это только данные для внесения, а больше или меньше это количество для внесения в БД.

Где больше вероятность что будет потеряна часть данных? При создании записи через PHP несколько рас в виде огромного массива данных или при формировании этого массива один рас, а дальше все на БД ложиться?

[Stasroot1]

По сообщению номер 50...

сменил индекс с уникального на простой и данные по тому запросу благополучно внеслись в соответствующую таблицу. Сейчас поправлю остальные индексы, которые я поставил в уникальный. Понятно почему он не может быть уникальным, так как одной записи по lid соответствует множество записей tid... а значит там не может быть уникального. Правильно понимаю?


UPD: написал не правильно, надо было писать так: одной записи по tid соответствует множество записей lid...

На ошибку указал sash-kan в сообщении 55.

[drBatty]

Я могу ошибаться но по моему сделать запрос на удаление записи N777 из таблици A проще чем сделать запрос на удаление из таблицы А а затем на удаление из таблицы Б соответствующих записям из А.

я не о том: логично сделать таблицу со спортсменами, и таблицу с тренировками. Каждая тренировка будет привязанная к конкретному спортсмену. Я говорю о случае, когда вам надо удалить спортсмена, и все его тренировки. Это, видимо, очень редкий случай. После него можно _всегда_ выполнять удаление "сироток", т.е. тренировок, в которых "никто" не участвовал (мы-же сначала удаляем спортсмена, а потом тренировки, и тут ВНЕЗАПНО происходит авария на сервере).

ИМХО плохо делать только таблицу с тренировками, в которых проставлены и поле с спортсменом, и у вас ещё поле с устройствами. Причина в том, что для каждого спортсмена нужно хранить уникальную информацию (имя например с фамилией, г.р. и прочее), и если у вас одна таблица, придётся всё это дублировать в каждой строке. В итоге БД будет в разы больше, и соответственно в разы медленнее.

[Stasroot1]

Я могу ошибаться но по моему сделать запрос на удаление записи N777 из таблици A проще чем сделать запрос на удаление из таблицы А а затем на удаление из таблицы Б соответствующих записям из А.

я не о том: логично сделать таблицу со спортсменами, и таблицу с тренировками. Каждая тренировка будет привязанная к конкретному спортсмену. Я говорю о случае, когда вам надо удалить спортсмена, и все его тренировки. Это, видимо, очень редкий случай. После него можно _всегда_ выполнять удаление "сироток", т.е. тренировок, в которых "никто" не участвовал (мы-же сначала удаляем спортсмена, а потом тренировки, и тут ВНЕЗАПНО происходит авария на сервере).

ИМХО плохо делать только таблицу с тренировками, в которых проставлены и поле с спортсменом, и у вас ещё поле с устройствами. Причина в том, что для каждого спортсмена нужно хранить уникальную информацию (имя например с фамилией, г.р. и прочее), и если у вас одна таблица, придётся всё это дублировать в каждой строке. В итоге БД будет в разы больше, и соответственно в разы медленнее.

Обдумываю.
А пока на данный момент есть такое вот положение дел:
прикладываю архив со структурой БД и данными в отдельных файлах.

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

Так же креплю картинку с тем как БД сейчас выглядит (схема)

start_schema_data_.tar.gz

(13.54 КБ) 30 скачиваний

drBatty, прикрепил схему, где там будет дублирование ФИО например? ФИО будет храниться только в users таблице, в таблице с тренировками будет только идентификатор пользователя, создавшего эту тренировку.

[sash-kan]

одной записи по lid соответствует множество записей tid

не уловил, извините·
в таблице тренировок primary key — это идентификатор тренировки; и, как primary key, он, естественно, уникален·
в таблице кругов каждая запись привязывается к конкретной тренировке; записей, привязанных к одной и той же тренировке, естественно, может быть больше одной·
отношение «один-ко-многим»: одна тренировка — много кругов·

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

[sash-kan]

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

ну вот в обоих ваших файлах присутствует тэг creator, в нём тэг name, а там уже название устройства: "EDGE705" и "Forerunner305"·
найти эти строки — это уже дело техники·

можно привлечь «тяжёлую артиллерию» — какую-нибудь php-шную библиотеку для работы с xml·
можно привлечь «малую артиллерию» — sed/grep/xmllint/tidy и т. д. и т. п.
можно обойтись своими силами — сделать то же, что и «малая артиллерия», но на php·

[Stasroot1]

одной записи по lid соответствует множество записей tid

не уловил, извините·
в таблице тренировок primary key — это идентификатор тренировки; и, как primary key, он, естественно, уникален·
в таблице кругов каждая запись привязывается к конкретной тренировке; записей, привязанных к одной и той же тренировке, естественно, может быть больше одной·
отношение «один-ко-многим»: одна тренировка — много кругов·

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

Извиняюсь, не правильно написал, хотел написать так:
одной записи по tid соответствует множество записей lid - буквы в спешке перепутал и смысл того что писал сменился на радикально - не правильный. Спасибо что указали, там в том сообщении подправлю. UPD записью.

[drBatty]

Так же креплю картинку с тем как БД сейчас выглядит (схема)

ну нормально всё ИМХО.

Глубокого погружения сюда я и не требую, так как у меня нет на это ни малейшего права и основания

вы меня неправильно поняли: дело в том, что удачно спроектировать БД может только тот, кто досконально разбирается в сути вопроса. Например: вы храните спортсменов и тренировки в разных таблицах. ИМХО это правильное решение. Однако. Если в таблице спортсменов только имя, и всё, и по сути задачи ничего туда добавится не может в принципе (у нас это не так конечно), то есть смысл добавить это имя в таблицу тренировок, и вообще ликвидировать таблицу спортсменов. Запросы тогда будут сильно проще, например запрос удаления спортсмена "Сидоров" - DELETE FROM trainings WHERE uname = 'Сидоров'; И будут работать атомарно в любой нормальной СУБД. Я слабо разбираюсь в спорте, однако знаю, что у каждого спортсмена в команде есть ещё и номер. Вот если этот номер тоже надо сохранять, то возникают проблемы - во первых дублирование информации (нам постоянно придётся в каждой строчке писать не только что это Сидоров, но и ещё, что его номер 7), во вторых индекс нам тоже придётся делать не простой, а зависимый от двух полей сразу. Это конечно можно делать, но зачем? Намного меньше и быстрее будет индекс, где каждому спортсмену будет назначен уникальный цифровой идентификатор (НЕ спортивный номер, а primary key из СУБД)

ЗЫЖ а что такое upas в таблице users?
И что такое pid в таблице trackpoints? ИМХО в последней должно находится просто время, когда спортсмен эту точку проходил. Или там должно быть два поля: время и расстояние от начала круга, или просто расстояние, если точки записываются регулярно, в известные моменты времени. Первый и третий вариант более предпочтителен, и даже если у вас второй (и время и расстояние нерегулярное), есть смысл рассчитать (интерполировать) промежуточные точки так, что-бы или время, или расстояние были регулярными отсчётами, тогда их разницу и начальное значение можно будет хранить в таблице кругов, ну а на выводе всё это будет очень просто восстановить (нам всё равно потребуются такие аффинные преобразования точек для рисования графика. Ну а два аффинных преобразования можно сделать одним, т.ч. затрат времени на эти вычисления не будет. При вводе будут, но парсинг съест намного больше, т.ч. не критично. За то таблица trackpoints будет компактной и быстрой, что для вас, видимо, весьма важно).

[sash-kan]

И что такое pid в таблице trackpoints? ИМХО в последней должно находится просто время, когда спортсмен эту точку проходил.

можно я отвечу? ведь именно я это поле предложил·
так как гранулярность времени (в двух образцовых файлах) — одна секунда, то в базе запросто может встретиться более одной записи с одинаковым временем·
т.е. для уникальности надо делать составной индекс·
и он будет включать (в том числе) и вводимые данные·
насколько я помню, ни в реляционной теории, ни в практике реализаций разных субд, никаких противопоказаний ни по поводу составных индексов, ни по поводу включения в индекс самих данных, не имеется·
просто я лично предпочитаю делать все primary key из одного (автоинкрементного) поля·
привычка такая; стиль, если желаете·
именно так я и предложил в своём наброске схемы·
на исключительном применении такого подхода ни в коем разе не настаиваю, конечно же·

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

[drBatty]

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

конечно нет, Но очевидно, что лишнее поле в данных в полтора раза увеличивает объём таблицы, и в полтора раза уменьшает скорость (было 2 поля, стало 3). А это не просто таблица, как я понимаю, именно на эту таблицу будет приходится более 90% объёма всей БД и столько же ресурсов. ЕМНИП на каждый круг там 7000+ отсчётов?

ИМХО, раз уж гранулярность в 1 сек задана по ТЗ, её просто следует понизить до 0.1 секунды. В этом случае мы можем сделать поле уникальным - даже если время совпадает, мы можем попросту увеличить его на 1/10. Этой гранулярности с signed int в 32 бита (как сейчас тип INT в MySQL) хватит почти на 7 лет. ИМХО более чем достаточно для данной задачи (уже сейчас многие компьютеры полностью 64х битные, и уж за 7 лет в MySQL уж точно введут нативный и быстрый INT64). Конечно возникает также проблема ошибки - в _крайне маловероятном_ случае совпадения 10 отсчётов по времени, время уходит на 1 секунду вперёд. Очевидно, такое возможно лишь в случае проведения 10 тренировок _одновременно_, что ИМХО в данной задаче невозможно. К тому же, даже если такое произойдёт, то на график это повлияет незаметно (1 точка чуть сдвинется, и то при сильном разрешении), а на статистику например среднего времени не повлияет вовсе.

просто я лично предпочитаю делать все primary key из одного (автоинкрементного) поля·
привычка такая; стиль, если желаете·

я _полностью_ с вами согласен - это поле почти всегда не занимает места и ресурсов, и сильно помогает в составлении запросов. Но в данном конкретном случае полей всего два, и добавлять третье ИМХО дорого. Если снизить гранулярность до 1/10 секунды, то поле времени как раз и можно задавать таким ключом, ведь никто не мешает нам задать primary key явно? А если такой уже есть (что мало вероятно), то можно его не задавать вовсе, и повторить запрос INSERT - он автоматически задастся на 0.1 сек больше. Т.е. мы получим и primary key, и временную метку в одном флаконе :)

sash-kan вы надеюсь понимаете, что я так подробно не лично для вас расписал (: