Форум истории автоспорта > Исследовательская лаборатория
Инструменты. База данных
Владимир Коваленко:
"Аксессовский" файл у меня остался, его можно дорабатывать в любое время.
Либо я не умею объяснять (а это очень возможно, учитывая то, сколько мне нервов пришлось потратить на упрощенной истории), либо подход действительно настолько революционный, что людям сложно перестроить мышление в нужном направлении, но я вот даже не знаю, с чего начать. Мне кажется, я уже миллион раз об этом говорил, поэтому нахожусь в некоторой растерянности.
Суть в том, чтобы получить универсальную БД для любого типа автомотоспортивных мероприятий. Я не проводил глубокий анализ всех возможных варинтов, но с теми, с которыми я часто имею дело в своих интересах, существующие базы данных в силу своей архитектуры оптимально справиться не смогут, насколько я могу судить.
Например, клубные соревнования в Гудвуде. Каждое состоит из нескольких гонок. Некоторые автомобили стартуют в нескольких гонках за день под одним и тем же номером. Если следовать традиционной схеме, которой, как мне кажется, придерживаются создатели всех БД, то обязательно должно быть деление на категории, классы и серии. Либо на первом уровне, либо на втором. То есть сначала ты должен выбрать категорию, потом тебе открывается список лет или сразу список гонок. Либо ты заходишь в год, потом выбираешь категорию (класс, серию), и потом вываливается список гонок.
При этом каждый заезд - это отдельное мероприятие. Представим, что некий спортивный "Лотос" под номером 12 стартовал в трёх гонках в Гудвуде: в гандикапе, в заезде для спортивных автомобилей до 1,5 литров и в гонке свободной формулы. Для него в базе данных будут три одинаковых записи. Автомобиль один, гонщик один, а записи три. Это неэффективно. Как оптимизировать? Сделать одну общую запись на всё соревнование, к которой привязывать конкретные заезды.
Другой пример. В соответствии с современным пониманием подразумевается, что вот есть гонка, и у ней её есть разные предварительные заезды. Поэтому надо вспомнить максимальное количество возможных видов заездов и расположить всю эту линейку в таблице результатов. Будет очень много столбцов. Даже если это домонстрационный заезд, надо тоже предусмотреть такую колонку. Поэтому на всю БД может быть с десяток таких заездов, но соответствующее поле будет болтаться во всех десятках или сотнях тысячах таблиц. Это неэффективно. Как оптимизировать? Сделать каждый заезд самостоятельной таблицей. Участники в ней будут браться из общего списка для соревнования, и нужны будут пара столбцов для результатов: время (или, допустим, количество пройденных кругов) или причина схода.
В необходимости принять соревнование в качестве второго уровня (после года) я убедился в процессе работы над своим архивом. Когда я, в соответствии с современным взглядом на автогонки, пытался делить гонки на отдельные мероприятия, возникали несоответствия. Например, упрощенная история говорит, что на Пасху в Гудвуде была очень крутая гонка класса формула №1 на приз Гловера. Ну, это же Ф1. Это очень круто. Хорошо, у меня есть папочка для этой гонки. Потоя появляются фотографии с этих же соревнований, но с гонок в других классах. Это же не супер-пупер-Ф1, поэтому ими загрязнять священную папочку мы не будем, а поместим в отдельную. Будут, например, 195х.04.хх_Glover_Trophy и 195х.04.хх_Goodwood_other (ну, условно). Хорошо. Будем считать, что "Приз Гловера" - это главная гонка, а остальные - гонки поддержки. Это искажение, но нам же надо к чему-то привязаться. Потом выясняется, что Майк Хоторн стартовал не только в "Призе Гловера", а ещё в паре гонок. И вот у меня есть портрет Хоторна, сделанный в этот день. Формально его надо поместить в обе папки, потому что неизвестно, к какой гонке отнести. Идиотизм ситуации очевиден. Гонщик был в тот день на трассе и участвовал в программе. Поэтому его присутствие должно быть привязанно ко всей програме, а не к конкретной гонке. Поэтому папочка нужна одна - для соревнования.
Ещё много менее значимых обстоятельств сводятся именно к формату соревнования как второго уровня БД. Это фундаментальный принцип. В нём есть есть нерешённые вопросы. Например, как быть с многодневным форматом? Два варианта: либо на втором уровне - соревнование с границаи дат, на третьем уровне - конкретные дни, на четвёртом - заезды в конкретный день; либо на втором уровне - каждый день, а на третьем - заезды. Второй вариант выглядит менее удачным, потому что в списке соревнований тогда будет не просто ралли "Монте-Карло", а 1 день РМК, 2 день РМК и т.д. Это не есть правильно.
Итак, фундаментальная особенность - это соревнование в качестве второго уровня БД.
Алексей Грушко:
Это всё понятно и хорошо. Но вопрос в другом - для чего тебе эта база данных? Вот я когда делал техзадание для сайта, сформулировал, что я хочу получать, помимо таблиц с результатами конкретного заезда, результаты гонщика во всех его гонках и чемпионатах, а также списки соревнований по годам, трассам, странам и категориям. При необходимости можно добавить и автомобили, и заявителей, но мне пока это не надо.
Владимир Коваленко:
1. Для выборок по результатам гонщиков и автомобилей. Полный расклад по всем соревнованиям, в которых стартовали. Это для публикаций.
2. Для идентификации фотографий. Если вижу на фото "Лотос" под номером 12 в Гудвуде, пусть БД выдаст весь список возможных вариантов.
Алексей Рогачев:
В последние полтора года я значительно доработал свою базу данных - помимо чисто программных усовершенствований СУБД, добавил в саму базу несколько новых таблиц, а кое-что, наоборот, удалил. В порядке обмена опытом делюсь схемой обновленной базы: http://www.ussr-autosport.ru/images/db_scheme.png.
Алексей Рогачев:
Некоторые комментарии к схеме.
1. Поля Gap, Speed и FLSpeed в таблице raceresults на первый взгляд могут показаться избыточными - ведь очень легко рассчитать отставание от победителя, среднюю скорость и скорость быстрейшего круга прямо в ходе формирования запроса, опираясь на данные о дистанции, длине круга и времени участников. Но я работаю чаще всего с неполными данными (главным образом из публикаций в газетах и журналах). Например, указана средняя скорость (к тому же очень приблизительно, округленная до 1 км/ч), но при этом протяженность дистанции неизвестна. Вот и приходится заводить избыточные поля в таблице.
2. Разделение дней, месяцев и годов в таблице drivers - также вынужденный шаг по причине неполноты информации. Чаще всего известен только год рождения или смерти спортсмена; в некоторых анкетах участников я встречал только год и месяц рождения без указания числа. А формат даты в Paradox не позволяет оставлять часть даты пустой или вводить значения вроде 00.00.1956. Вот и пришлось разделить каждую дату на три поля. Для таблицы events аналогичный вопрос не стоит, так как дата проведения соревнований известна в 90% случаев точно, а в остальных случаях ее можно вычислить по косвенным данным (например, по дате выхода газет, в которых есть заметки об этих соревнованиях).
3. Поле Sex по логике строения базы данных должно было бы находиться в таблице drivers, но дело в том, что сведений о гонщиках, выходящих за рамки имени и фамилии, у меня мало. Получается, что в таблице drivers содержится имен намного меньше, чем встречается в raceresults (на данный момент - 1943 и 3518 соответственно). Так что если вдруг потребуется выборка данных о женщинах в гонках, я полезу прежде всего в результаты гонок. А значит, полю Sex место именно в этой таблице.
4. В таблице teamresults хранятся командные результаты как отдельных соревнований, так и многоэтапных чемпионатов. В обоих случаях записи имеют одинаковую структуру: место, команда, сумма очков, члены команды. Поэтому проще оказалось свести все это в одну таблицу и связать ее как с events, так и с championships. При запросе командных результатов отдельных соревнований отбор идет по полю IDEvent, а при запросе командных результатов многоэтапного чемпионата - по полю IDChampionship.
5. Наличие поля Reliability в таблице chresults вызвано тем, что иногда я сам рассчитываю суммы очков по имеющимся результатам гонок, если в моем распоряжении нет официальных итогов чемпионата. В этих-то случаях и ставится пометка "недостоверно" в поле Reliability (точнее, поле имеет логический тип, то есть значение устанавливается равным false, а в СУБД для удобства используется выпадающий список с пунктами "достоверно" и "недостоверно").
6. Стартовая решетка кодируется следующим образом: через дефис два числа и буква. Первое число - количество мест в нечетных рядах, второе - количество мест в четных рядах, буква обозначает направление счета мест в рядах: "л" - слева направо, "п" - справа налево. Например, на Невском кольце традиционно стартовое поле соответствовало схеме "4-3-п".
7. Здесь в структурах таблицах lapcharts и laptimes для экономии места сведены вместе однотипные поля с данными о номерах участников и результатах на круге. На самом деле в lapcharts тридцать пять таких полей, а в laptimes - тридцать. Если попадется какая-нибудь гонка с числом кругов более тридцати, для которой известны результаты отдельных кругов, количество полей может еще увеличиться.
Навигация
Перейти к полной версии