Форум истории автоспорта > Исследовательская лаборатория

Инструменты. База данных

<< < (3/43) > >>

Алексей Рогачев:
Вот структура моей БД:

Про недостатки расскажу завтра.

Алексей Рогачев:
Итак, обещанный рассказ о недостатках. Таковых я в своей базе данных насчитываю шесть:
1. ID гонки. У меня он числовой, шестизначный, например 741601 значит "1974 год, шестнадцатые соревнования сезона, первая гонка". Задумывал я эти ID с тем расчетом, чтобы они не только служили ключом таблицы, но по ним можно было также задавать год при создании запросов, например, 1974 год кодировался бы как ">740000 and <750000". Это, разумеется, работает, но я тогда как-то не сообразил, что гораздо проще и естественнее будет работать с полем "Дата проведения". В итоге это привело к тому, что создать запрос на результаты какой-нибудь конкретной гонки очень сложно: надо или лезть в таблицу "Гонки" и искать там вручную нужное значение ID, или писать в запросе полное название гонки, например "Гонки на приз "Янтарная "Волга""" (со всеми кавычками). Выходом из положения могло бы стать создание составного ключа в таблице "Гонки", а именно состоящего из трех полей: "ID-год", "ID-соревнования", "ID-гонка". Тогда вместо 741601 эти три поля содержали бы такие значения: 74, ЯВ, 01. "ЯВ" - это "Янтарная "Волга"", и такие двух- или трехбуквенные обозначения можно было бы придумать для всех соревнований. Их легко запомнить, и тогда запрос на результаты той гонки создать было бы очень легко, задав значения 74 и ЯВ в соответствующих полях конструктора запросов. Возможно, тогда я еще просто не понимал, что ключ может быть составным, да и сейчас, хотя эта идея и реализована в таблице "Результаты отдельных заездов", я отношусь к составному ключу весьма настороженно...
2. Место. В таблице "Результаты гонок" пришлось установить для этого поля не числовое, а текстовое значение, чтобы можно было вписывать в него такие обозначения, как НФ, НС, НК и ДК. В результате нельзя составить запрос типа: "выбрать гонщиков, занявших места с четвертого и ниже". В отличие от предыдущего случая, этот вопрос встал передо мной сразу же при создании таблицы, но найти разумный выход из положения я не сумел и поэтому вынужден был сделать поле текстовым. Да и сейчас не знаю, как поступить. Можно было бы, конечно, сделать два поля, одно из которых будет текстовым, а другое - числовым (в нем все сошедшие, дисквалифицированные, не стартовавшие кодировались бы нулем), но это только увеличит объем БД и сделает ее более громоздкой.
3. Результаты чемпионатов СССР. Таблица нужная, без нее никуда. Но чемпионаты-то эти далеко не всегда были многоэтапными, порой они состояли из одной-единственной гонки, а значит, в этих случаях таблица "Результаты чемпионатов СССР" попросту дублирует записи в таблице "Результаты гонок", и при пополнении БД информацией приходится их вводить дважды. Это проблема фундаментальная, на стадии создания БД я ее не предвидел, потому что тогда таблицу с результатами чемпионатов еще и не задумывал вовсе.
4. Быстрейшие круги в гонках. Порой случалось так, что быстрейший круг в гонке показывали двое, а то и трое гонщиков (при хронометраже с точностью до 0,1 с это случалось не так уж и редко), а до 1959 года экипаж состоял из двух человек. В таких случаях в поле "Быстрейший круг (имя)" приходится писать два имени, а в поле "Быстрейший круг (фамилия)" - две фамилии. Это делает невозможным выбор по запросу одной из этих фамилий.
5. Общее время гонки приходится задавать в секундах, а не в часах, минутах и секундах, потому что в Access я попросту не нашел такого формата поля.
6. Соответствия между временем, скоростью, отставанием от лидера и дистанцией. По-хорошему надо было бы связать эти поля, чтобы значение одного рассчитывалось автоматически по значениям других. Я думал на этим, но тут сыграла роль специфика данных, с которыми я работаю. Порой я знаю скорость, но не знаю дистанцию и время; знаю время, но не знаю скорость и дистанцию; знаю отставание от лидера, но не знаю времени лидера. Мастер подстановок эти пробелы, боюсь, не переварил бы. Поэтому при занесении в БД гонок, о которых имеется много информации, вплоть до времени каждого из участников, приходится выполнять все расчеты вручную, а при изменении одного из параметров пересчитывать все остальные. Иногда бывает и так, что из-за неточности или противоречивости данных скорость, время и дистанция не соответствуют друг другу.Sourceress38732,7761921296

Александр Готвянский:
 
--- Цитата: Sourceress --- Итак, обещанный рассказ о недостатках. Таковых я в своей базе данных насчитываю шесть:
 
 
2. Место. В таблице "Результаты гонок" пришлось установить для этого поля не числовое, а текстовое значение, чтобы можно было вписывать в него такие обозначения, как НФ, НС, НК и ДК. В результате нельзя составить запрос типа: "выбрать гонщиков, занявших места с четвертого и ниже". В отличие от предыдущего случая, этот вопрос встал передо мной сразу же при создании таблицы, но найти разумный выход из положения я не сумел и поэтому вынужден был сделать поле текстовым. Да и сейчас не знаю, как поступить. Можно было бы, конечно, сделать два поля, одно из которых будет текстовым, а другое - числовым (в нем все сошедшие, дисквалифицированные, не стартовавшие кодировались бы нулем), но это только увеличит объем БД и сделает ее более громоздкой.
 

--- Конец цитаты ---

 
Вмешаюсь и я. Опыт с Access имел небольшой, но в универе для лучшего понимания БД просто для себя пытался составлять себе базы данных с футбольными результатами, а этим летом пытался упорядочить свою музыкальную колекцию. Рекомендую сделать для себя простенькую базу небольшого объема для понимания основных принципов построения и поджидающих в будущем ошибок. Потом просто будет легче.
 
Для указания всяких НС, НК, НФ и др. предлагаю просто присвоить им числовые индексы типа -1, -2 и т. д. Это не нарушит логики таблицы и в то же время позволит присвоить полю тип "Числовой"

Алексей Рогачев:
Черт побери!! Все гениальное просто!!

Александр Готвянский:
  Не надо аплодисментов. Я вот только что подумал, что эти цифры будут вылазить перед обладателем первых мест, поскольку они меньше. Лучше наверное заменить их на, например, 101,102 и т.д. Все равно таких финишных позиций не бывает. Но попробуй и первый вариант. Может тебе и так сойдет, я же не знаю твоих запросов.

Навигация

[0] Главная страница сообщений

[#] Следующая страница

[*] Предыдущая страница

Перейти к полной версии