Автор Тема: Инструменты. База данных  (Прочитано 99077 раз)

Оффлайн Владимир Коваленко

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #200 : Августа 28, 2015, 06:42:29 »
Сложнее решить, как суммировать все виды тренировочных и соревновательных заездов. Ведь у нас были:
- два полуфинала + финал;
- два полуфинала + агрегатированный по их сумме результат;
- предквалификация;
- пятничная тренировка;
- субботняя тренировка;
- иногда две пятничные тренировки и одна субботняя;
- были тренировки и в день перед гонкой;
- собственно гонка;
- спринт;
- гонка с обратным расположением на решетке;
Как вот это все структурировать? Какими должны быть формы для "универсальной гонки"? Как узнать, какие таблицы (виды тренировок и гонки) заполнять для Большого приза Бельгии 1984 года и какие для Большого приза Макао 1985 года в Ф3? А какие для "Милле Милья" 1927 года, коль скоро БД планируется быть универсальной по всему автоспорту?


Вот это всё не так должно быть. Лёша Грушко в своё время тоже предлагал универсальную форму в виде таблицы со множеством таких столбцов: 1, 2, 3, n тренировка и т.д. Это всё лишнее.


На первом уровне базы данных - год. На втором - соревнование, то есть комбинация трассы и даты. На третьем - заезд, то есть комбинация соревнования и мероприятия по номеру программы. Вот и всё. Этот заезд может быть чем угодно, хоть парадом "Мини" с мистером Бином. Заезды - это не колонки для списка участников, а строчки в хронологии. Принципиально другой подход к архитектуре.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

Оффлайн Влад Шайхнуров

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 3 305
  • Карма 1033
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #201 : Августа 28, 2015, 07:10:47 »
Мне для понимания того, как ты представляешь структуру БД, надо задать еще кучу вопросов. Но сейчас надо бежать. Так что вечером.
Tempora mutantur et nos mutamur in illis. Audiatur et altera pars. Nolite judicare et non judicabimine
Homines non odi , sed ejus vitia.

Оффлайн Владимир Коваленко

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #202 : Августа 28, 2015, 07:20:06 »
А ты лучше почитай эту тему с самого начала.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

Оффлайн Алексей Грушко

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 4 136
  • Карма 485
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #203 : Августа 28, 2015, 11:42:35 »
Я тоже пошёл по пути упрощения и отказался от многих параметров, а также принял решение делать базу данных сразу онлайн. Вот пример как в идеале должна выглядеть таблица с результатами гонки - http://racingstat.com/category/2013-6-hours-of-spa-francorchamps
Но если каких-то полей нет ни одного гонщика, колонка просто не отображается.
Но ещё я понял, что заполнение этой базы данных - очень геморное дело, и делаю я это от случаю к случаю.
Если человек эмоционален, это еще не означает, что он не прав

Оффлайн Влад Шайхнуров

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 3 305
  • Карма 1033
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #204 : Августа 28, 2015, 23:50:33 »
А ты лучше почитай эту тему с самого начала.
Читал, разумеется. Написано много умных и не очень вещей. Но по большому счету последнее сообщение относится к 2008 году. С тех пор много воды утекло и у тебя могло многое поменяться как в требованиях к базе, так и в представлениях о ее структуре.
Я к чему это все. Правильно Алексей написал: сделать базу - это одна проблема, заполнять ее - другая. Можно сделать "индивидуальную" БД для одного компьютера, которую будет вести один пользователь. Все на том же Access. И фотографии подвязывать, и любые документы или ссылки к любому событию. Все будет классно, но заполнять ее будет только один человек. Участие других возможно, но для этого надо предусмотреть процедуру импорта из заполненных другими участниками процесса заранее заданных шаблонов.
Второй вариант - это онлайн БД. Это MySQL. Вещь классная, мощная. Но тут нужен действительно специалист.
Так вот, если тебя устроит БД на Acess, то я готов сделать таковую. Пусть не быстро, пусть месяцев за пять-шесть, но сделаем. Что касается БД на MySQL, то последний раз я занимался этим лет десять назад, сделал пару простеньких площадок для интернет-торговли. И был-то не слишком опытным специалистом, а сейчас еще и забыл все, что знал. 
Tempora mutantur et nos mutamur in illis. Audiatur et altera pars. Nolite judicare et non judicabimine
Homines non odi , sed ejus vitia.

Оффлайн Владимир Коваленко

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #205 : Августа 29, 2015, 01:23:16 »
Я отказался от "Аксесса" в пользу онлайн-базы именно по той причине, что заполнять надо коллективно. Интерес к написанию БД имеет Фёдор Бакулов, мы с ним давно это обсуждали, но прямо сейчас ему пока некогда.


Вопрос в другом: будет ли это коллективный проект или индивидуальный. Я имею в виду то, что я в любом случае буду это делать и именно так, как вижу. И подозреваю, что не всем такая структура по душе. Возможно, не все просто её понимают. Так вот, если будет понимание и желание работать вместе, то добро пожаловать. Можно обсуждать конкретные решения.


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


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

Оффлайн Влад Шайхнуров

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 3 305
  • Карма 1033
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #206 : Августа 29, 2015, 01:34:57 »
Здесь немного в другом проблема. "Бухтением" я бы это не назвал. Архитектура БД должна быть должна быть проработана еще до начала ее создания. И оформлена в виде очень четкого технического задания. Вариант "сперва начнем делать, а потом поймем, что нам надо" имеет право на существование, но БД разрастается , обрастает ненужными таблицами, связями,индексами. И в случае сбоя порой разобраться, что случилось - затруднительно.
У меня есть один компьютерный гений, Серега "Лом". Работает начальником департамента в российском MySAP. Когда я бы не просил его что-нибудь для меня сделать, он всегда говорил: "Я - тупой! Ты мне должен четко сказать, где должна быть кнопочка и что должно произойти при ее нажатии. Какие данные надо выбрать и в каком порядка расставить. Если ты доверяешь все решать мне самому - то и дело будешь иметь с тем, что я сам наделаю на свое усмотрение."
Tempora mutantur et nos mutamur in illis. Audiatur et altera pars. Nolite judicare et non judicabimine
Homines non odi , sed ejus vitia.

Оффлайн Влад Шайхнуров

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 3 305
  • Карма 1033
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #207 : Августа 29, 2015, 01:49:15 »
Если поймёте, чего я хочу, и предложите более эффективный вариант,
В плане создания БД самое главное - представить как все должно работать и точно описать. Все остальное - только вопрос исполнения. Современные инструменты создания БД дают широчайшие возможности. Другое дело, что БД должна быть еще и максимально рациональной, без лишних связей и индексов, таблиц и повторяющихся данных. Но это - вопрос предварительной проработки.
Tempora mutantur et nos mutamur in illis. Audiatur et altera pars. Nolite judicare et non judicabimine
Homines non odi , sed ejus vitia.

Оффлайн Владимир Коваленко

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #208 : Августа 29, 2015, 01:59:02 »
Здесь немного в другом проблема. "Бухтением" я бы это не назвал. Архитектура БД должна быть должна быть проработана еще до начала ее создания. И оформлена в виде очень четкого технического задания. Вариант "сперва начнем делать, а потом поймем, что нам надо" имеет право на существование, но БД разрастается , обрастает ненужными таблицами, связями,индексами. И в случае сбоя порой разобраться, что случилось - затруднительно.


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

Оффлайн Влад Шайхнуров

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 3 305
  • Карма 1033
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #209 : Августа 29, 2015, 02:04:03 »
Интересно, и я думаю, что мог бы помочь тебе сделать эффективную БД.  Более того, пока Федор занят, можно попробовать обкатать схему на Access. Принципы одинаковы. А потом отработанную архитектуру перенести на MySQL.
Что касается заполнения, то на настоящий момент  я готов поучаствовать. Что будет через энное время, когда база заработает - не знаю.
Tempora mutantur et nos mutamur in illis. Audiatur et altera pars. Nolite judicare et non judicabimine
Homines non odi , sed ejus vitia.

Оффлайн Владимир Коваленко

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #210 : Августа 29, 2015, 06:05:01 »
"Аксессовский" файл у меня остался, его можно дорабатывать в любое время.


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



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


Например, клубные соревнования в Гудвуде. Каждое состоит из нескольких гонок. Некоторые автомобили стартуют в нескольких гонках за день под одним и тем же номером. Если следовать традиционной схеме, которой, как мне кажется, придерживаются создатели всех БД, то обязательно должно быть деление на категории, классы и серии. Либо на первом уровне, либо на втором. То есть сначала ты должен выбрать категорию, потом тебе открывается список лет или сразу список гонок. Либо ты заходишь в год, потом выбираешь категорию (класс, серию), и потом вываливается список гонок.


При этом каждый заезд - это отдельное мероприятие. Представим, что некий спортивный "Лотос" под номером 12 стартовал в трёх гонках в Гудвуде: в гандикапе, в заезде для спортивных автомобилей до 1,5 литров и в гонке свободной формулы. Для него в базе данных будут три одинаковых записи. Автомобиль один, гонщик один, а записи три. Это неэффективно. Как оптимизировать? Сделать одну общую запись на всё соревнование, к которой привязывать конкретные заезды.


Другой пример. В соответствии с современным пониманием подразумевается, что вот есть гонка, и у ней её есть разные предварительные заезды. Поэтому надо вспомнить максимальное количество возможных видов заездов и расположить всю эту линейку в таблице результатов. Будет очень много столбцов. Даже если это домонстрационный заезд, надо тоже предусмотреть такую колонку. Поэтому на всю БД может быть с десяток таких заездов, но соответствующее поле будет болтаться во всех десятках или сотнях тысячах таблиц. Это неэффективно. Как оптимизировать? Сделать каждый заезд самостоятельной таблицей. Участники в ней будут браться из общего списка для соревнования, и нужны будут пара столбцов для результатов: время (или, допустим, количество пройденных кругов) или причина схода.


В необходимости принять соревнование в качестве второго уровня (после года) я убедился в процессе работы над своим архивом. Когда я, в соответствии с современным взглядом на автогонки, пытался делить гонки на отдельные мероприятия, возникали несоответствия. Например, упрощенная история говорит, что на Пасху в Гудвуде была очень крутая гонка класса формула №1 на приз Гловера. Ну, это же Ф1. Это очень круто. Хорошо, у меня есть папочка для этой гонки. Потоя появляются фотографии с этих же соревнований, но с гонок в других классах. Это же не супер-пупер-Ф1, поэтому ими загрязнять священную папочку мы не будем, а поместим в отдельную. Будут, например, 195х.04.хх_Glover_Trophy и 195х.04.хх_Goodwood_other (ну, условно). Хорошо. Будем считать, что "Приз Гловера" - это главная гонка, а остальные - гонки поддержки. Это искажение, но нам же надо к чему-то привязаться. Потом выясняется, что Майк Хоторн стартовал не только в "Призе Гловера", а ещё в паре гонок. И вот у меня есть портрет Хоторна, сделанный в этот день. Формально его надо поместить в обе папки, потому что неизвестно, к какой гонке отнести. Идиотизм ситуации очевиден. Гонщик был в тот день на трассе и участвовал в программе. Поэтому его присутствие должно быть привязанно ко всей програме, а не к конкретной гонке. Поэтому папочка нужна одна - для соревнования.


Ещё много менее значимых обстоятельств сводятся именно к формату соревнования как второго уровня БД. Это фундаментальный принцип. В нём есть есть нерешённые вопросы. Например, как быть с многодневным форматом? Два варианта: либо на втором уровне - соревнование с границаи дат, на третьем уровне - конкретные дни, на четвёртом - заезды в конкретный день; либо на втором уровне - каждый день, а на третьем - заезды. Второй вариант выглядит менее удачным, потому что в списке соревнований тогда будет не просто ралли "Монте-Карло", а 1 день РМК, 2 день РМК и т.д. Это не есть правильно.


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

Оффлайн Алексей Грушко

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 4 136
  • Карма 485
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #211 : Августа 29, 2015, 07:10:18 »
Это всё понятно и хорошо. Но вопрос в другом - для чего тебе эта база данных? Вот я когда делал техзадание для сайта, сформулировал, что я хочу получать, помимо таблиц с результатами конкретного заезда, результаты гонщика во всех его гонках и чемпионатах, а также списки соревнований по годам, трассам, странам и категориям. При необходимости можно добавить и автомобили, и заявителей, но мне пока это не надо.
Если человек эмоционален, это еще не означает, что он не прав

Оффлайн Владимир Коваленко

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #212 : Августа 29, 2015, 07:24:37 »
1. Для выборок по результатам гонщиков и автомобилей. Полный расклад по всем соревнованиям, в которых стартовали. Это для публикаций.


2. Для идентификации фотографий. Если вижу на фото "Лотос" под номером 12 в Гудвуде, пусть БД выдаст весь список возможных вариантов.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

Оффлайн Алексей Рогачев

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #213 : Июля 29, 2020, 14:45:29 »
В последние полтора года я значительно доработал свою базу данных - помимо чисто программных усовершенствований СУБД, добавил в саму базу несколько новых таблиц, а кое-что, наоборот, удалил. В порядке обмена опытом делюсь схемой обновленной базы: http://www.ussr-autosport.ru/images/db_scheme.png.

Оффлайн Алексей Рогачев

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #214 : Июля 30, 2020, 10:51:18 »
Некоторые комментарии к схеме.

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 - тридцать. Если попадется какая-нибудь гонка с числом кругов более тридцати, для которой известны результаты отдельных кругов, количество полей может еще увеличиться.