Мне надо, чтобы в БД сначала открывались только списки соревнований, а списки гонок можно было бы открыть дополнительно. Не уверен, что правильно выразил свою мысль.
Итак, обещанный рассказ о недостатках. Таковых я в своей базе данных насчитываю шесть:
2. Место. В таблице "Результаты гонок" пришлось установить для этого поля не числовое, а текстовое значение, чтобы можно было вписывать в него такие обозначения, как НФ, НС, НК и ДК. В результате нельзя составить запрос типа: "выбрать гонщиков, занявших места с четвертого и ниже". В отличие от предыдущего случая, этот вопрос встал передо мной сразу же при создании таблицы, но найти разумный выход из положения я не сумел и поэтому вынужден был сделать поле текстовым. Да и сейчас не знаю, как поступить. Можно было бы, конечно, сделать два поля, одно из которых будет текстовым, а другое - числовым (в нем все сошедшие, дисквалифицированные, не стартовавшие кодировались бы нулем), но это только увеличит объем БД и сделает ее более громоздкой.
Мой шестизначный ID устроен так, что ограничения, в него заложенные, ни в коей мере мешать не могут. Суди сам: годы, которые будут представлены в БД, целиком относятся к XX веку, значит, двух первых цифр вполне хватит. Больше двух с небольшим десятков соревнований за сезон в СССР не проводилось никогда, значит, тоже достаточно двух цифр. И, наконец, каждое из этих соревнований включало в себя максимум десять гонок - еще две цифры. С этим как раз все в порядке. Счетчики в качестве ключа я стараюсь, наоборот, не использовать именно потому, что значение не несет никакого смысла и лишь увеличивает объем базы данных впустую. А если бы я в таблице "Гонки" поставил счетчик в качестве ключа, запрос на результаты гонки вообще стал бы кошмаром, потому что пришлось бы набирать в запросе полное длинное название гонки, со всеми запятыми и кавычками. Идея составного значимого ключа, который бы служил основой для запросов, пришла мне в голову слишком поздно...
Но все-таки осмелюсь дать тебе совет: когда связываешь два поля в разных таблицах, лучше называй его одинаково и в той, и в другой - для пущей ясности.
А че тут велосипед изобретать?
Чтоб отовсюду доступно было - только сайт.
Если сайт - то Mysql + php + домен + программист
Вот и все. Че еще?
Пусть ищут себе программера и делают. самим им не сделать (судя по их уровню
общения на форуме).
Если access - то проблема с обновлением: им придется достаточно часто
выкладывать свою базу, а вам (тебе в том числе) придется все время эти
обновления скачивать.
К тому же, в первом случае можно работу по заполнению базы разделить: скажем
есть 4 добросовестных человека, вот они каждый в базу и вносят добавления. У
каждого свой логин/пасс, права, обязанности и т.д.
Могут поискать готовые движки, но по-моему навряд ли найдут - т.к. ваша
дрянь узкоспециализированная.
Да, между прочим, твой давнишний совет по SQL-овскому оператору LIKE в Access не действует. Почему - не знаю...
| Условие на значение поля | Сообщение об ошибке |
| Like "K???" | Значение должно содержать четыре знака и начинаться с буквы K. |
| Условие на значение поля | Сообщение об ошибке |
| Alike "K___" | Значение должно содержать четыре знака и начинаться с буквы K. |
В принципе, на этапе создания таблиц всё оказалось подозрительно несложно, так что я подумываю о расширении всей базы данных до "идеального" варианта, включающего в себя и результаты гонок, и параметры автомобилей, и информацию о гонщиках. Всё это можно заложить заранее, а потом только заполнять.
Единственная опасность - чего-то не предусмотреть и затем потерять часть информации при преобразованиях.
Я не знаю, насколько ты знаком с принципами реляционных баз данных (я сам, к слову, только разбираюсь), но удобство такой БД заключается в том, что огромные объёмы информации можно хранить в одном месте, не заботясь о красоте и удобстве их использования. Структрура отдельных таблиц может быть какой угодно, а отображение нужной информации определяется запросами. Один раз сделал запрос - и по нему будет выводиться только та информация, которая нужна.
В обычных таблицах для этого надо создавать отдельные таблицы с повторением данных.
В той БД, которую я хотел бы создать, нужно заложить максимум необходимых данных, а потом постепенно заполнять её.
Единственная опасность - чего-то не предусмотреть и затем потерять часть информации при преобразованиях.Да. Это основная проблема при разработке структуры базы данных.
Значит, есть смысл не заботиться о красоте кода? Пусть будет счётчик - и хрен с ним?
Пока не разобрался, как делать то, о чём ты говорил про заполнение при скрытом поле кода, но разберусь.
2. Имена и фамилии гонщиков. Разнести их по разным полям? То есть один столбец - имя, другой - фамилия? В принципе, это было бы удобно для сортировки. Вопрос опять-таки в том, можно ли при необходимости объединить две записи в одну. Пока ещё не искал ответ на этот вопрос.можно склеить две и более записи в одну, указав соответствующие поля определенной команде...
Только покопавшись в ней, именно по гонщикам я нашел некоторые непонятности. У гонщика поле "имя гонщика" текстовое, а при этом есть отдельный справочник "имена и названия", в котором имена уже структурируются. Если хочется, чтобы эти таблицы были связаны - придется менять структуру и имя/фамилию любого гонщика сначала заносить в справочник, а потом уже из справочника выбирать при заполнении таблицы "гонщики".
... для того, чтобы выбирать значения из связанной таблицы, необходимо использовать инструмент "Подстановка". Когда редактируешь поле - обрати внимание, что снизу есть еще одна закладка с таким названием и попробуй посмотреть хелп по ней, там всё очень подробно расписано.
Фактически, раз у тебя создан справочник имен и фамилий, то в любой таблице, где у тебя используются хоть какие-то имена и фамилии, необходимо предусмотреть поля для хранения индекса имени и индекса фамилии из справочника (т.е. поля "Код имени"). Сами же имена и фамилии будут храниться только в одном единственном месте. И тут всплывают сразу две проблемы. Проблема №1 заключается в том, что ты не знаешь точно, сколько имен-фамилий будет у гонщика. В том плане, что гонщика могут звать ведь и "Остап Сулейман Берта Мария". Если ты хранишь это в одном поле имени - то замечательно, а если хочешь в разных и собирать полное имя из кусочков - то получается отношение между таблицами "многие ко многим", которое разрешается только через промежуточную таблицу. Это реализуемо, но требует определенных действий.
Проблема №2 - я, честно говоря, уже давно не следил за темой имен, поэтому не знаю - сошлись вы на том, что используете для перевода исторически сложившуюся транскрипцию или забиваете на нее и переводите всегда однозначно. Самый популярный пример первого - это "Джордж Харрисон и Гарри Гаррисон". Если нужна реализация такого варианта - тогда в таблице имен придется хранить два отдельных варианта с одинаковым оригинальным именем и разными переводами. Что усложняет ее заполнение и приводит к путанице. Забить на сложившуюся же транскрипцию - технически упрощает решение, но с точки зрения удобства восприятия - может создать проблемы.
Цитата: pLutoФактически, раз у тебя создан справочник имен и фамилий, то в любой таблице, где у тебя используются хоть какие-то имена и фамилии, необходимо предусмотреть поля для хранения индекса имени и индекса фамилии из справочника (т.е. поля "Код имени"). Сами же имена и фамилии будут храниться только в одном единственном месте. И тут всплывают сразу две проблемы. Проблема №1 заключается в том, что ты не знаешь точно, сколько имен-фамилий будет у гонщика. В том плане, что гонщика могут звать ведь и "Остап Сулейман Берта Мария". Если ты хранишь это в одном поле имени - то замечательно, а если хочешь в разных и собирать полное имя из кусочков - то получается отношение между таблицами "многие ко многим", которое разрешается только через промежуточную таблицу. Это реализуемо, но требует определенных действий.
Ага, я понял. Значит, в таблице вместо поля "Имя гонщика" в текстовом формате должно быть поле "Код имени" в числовом?
А промежуточная таблица - это таблица для составных имён? Тогда совсем фигня запутанная получится.
Из-за особенностей построения данного вида баз данных колонка с названием трассы в оригинале будет в любом случае, но её можно будет не отображать в этой таблице.
Насчёт длин круга, в принципе, есть возможность сделать формулы для пересчёта. Длина в милях может пригодиться при использовании публикаций с неметрическими данными.
В принципе это я и имел в виду. Строить базу данных и осуществлять поиск не по оригинальному названию (переводу) несколько сложнее.
Желательна формула для пересчета и возможность переключения, как для заведения данных, так и для просмотра в двух системах, но чтобы постоянно отображалась - одна. Понимаю, что это чуть сложнее, но приятней для пользования.
Как программер, я бы мог многое подсказать и, возможно, что-нибудь и сделать. Проблема в том, что я не могу понять как должен выглядеть сайт-архив. Какие разделы и т.д.? Речь идёт о некоей базе - как она должна выглядеть (в смысле интерфейс - поля ввода, селекторы и т.д.) и в каком виде выдавать результаты запросов?
Да, есть ещё поле(столбец) с названием соревнования, по которому ты и сможешь выбрать потом из базы необходимые тебе гонки и сформировать список/таблицу/etc.
Разбивать массив данных на простые таблицы стоит до поры до времени - пока это обоснованно.Мне один человек, который их разрабатывает периодически сказал примерно так.
Должна быть одна большая - основная таблица, в которой нужно предусмотреть все возможные поля для решаемой задачи. Причем "вся соль" в том, что в ней большинство полей хранится в виде кодов - они быстрее обрабатываются и занимают меньше места в памяти.
И остальные маленькие, где каждому коду соотвестывует конкретное значение.
Я хочу заложить возможность заносить в БД технические характеристики, а в стародавние времена автомобили одной модели могли различаться даже такими серьёзными деталями, как тип подвески (у одной - "балка", у другой - труба де Диона). Поэтому каждое шасси стоит определять конкретно.
Тут ещё такой вопрос. При абсолютной оптимизации надо разделить марку автомобиля ("Мазерати"), модель (250Ф) и номер шасси (не говоря уж о номере двигателя). Можно ли какими-либо операциями собирать в одну ячейку данные из нескольких? Чтобы, например, из "Мазерати" и "250Ф" можно было бы получить "Мазерати 250Ф".Я не понял суть вопроса. Что в твоем понимании значит "собирать"? Получать в одной ячейке выводимого на экран результата совокупность данных из нескольких полей таблицы? При самостоятельной разработке СУБД - да, есть такое понятие "вычисляемое поле", то есть такое, значение которого получается из других полей таблицы по заданному тобой алгоритму. Наверняка в Access должно быть что-нибудь подобное.
1. Ты делаешь выборку из результатов и делаешь вывод, что1. Именно для выборки, причем максимально быстрой и с возможностью построения сложных запросов и вывода на экран в удобной форме и делается БД. Иначе все можно было бы сохранять в текстовом виде.
2. ...
3. а вышеуказанные модели автомобилей потенциально были лучшими среди современников, но не показали результатов из-за проблем с доводкой. Такие вещи статистическая обработка отвергает, потому что основана исключительно на цифрах.
4. ...Тренировки...
Сайт - это простой набор веб-страниц, а не база данных.
1. Именно для выборки, причем максимально быстрой и с возможностью построения сложных запросов и вывода на экран в удобной форме и делается БД. Иначе все можно было бы сохранять в текстовом виде.
И второй вопрос. Не увидел названий команд в твоей базе. Это намеренное умалчивание?
Мой вопрос больше касался тех ситуаций, когда в разных источниках приводятся разные данные:
- в источнике 1) : "Феррари-100"
- в источнике 2) : "Феррари-101"
Какой выбрать? Один из двух, а второй указать в примечании (и источники).
И второй вопрос. Не увидел названий команд в твоей базе. Это намеренное умалчивание?
В материнские таблицы внесу такую запись как "Нет данных" для тех случаев, когда точной информации действительно нет, а что-то вписать надо.
Я предусматриваю указание следующей информации о трассах в БД.Да.
Какие ещё данные можно представить в "карточке" трассы? Схему, указание страны. Кнопку для выборки из БД по данной трассе. Что ещё?
gp2
Кроме всего перечисленного у трассы есть официальное название, которое тоже со временем может изменяться.
Я предусматриваю указание следующей информации о трассах в БД.
1. Полное официальное название трассы, например: "Автодром имени Жиля Вильнёва".
2. Полное официальное название в оригинале. Для вышеуказанной трассы с ходу назвать не могу, но пусть будет Gilles Villeneuve Circuit.
3. Условное название, то есть то, которое можно было бы использовать в обиходе без потери смысла. В данном примере - просто "Монреаль". Другой пример: "Валенсия ("Рикардо Тормо")" и "Валенсия (городская)".
4. Условное название по-английски (Montreal).
...
Получается, все параметры (поля) можно разделить на две группы: основные и дополнительные. Основные - это поля, напрямую влияющие на идентификацию трассы. Это официальное название, а также название, которое я назвал условным. То есть, если у трассы длинное название, которое неудобно использовать каждый раз, для него выбирается более короткое название, которое и в обиходе используется достаточно часто.
Также к соновным параметрам можно отнести длину трассы и её тип (линейная, линейно-кольцевая, кольцевая, подъём, спринт); возможно - годы функционирования и направление движения.
Дополнительные параметры не влияют на идентификацию трассы, и выборка по ним, как правило, особого смысла не имеет. Это и уже обсуждавшаяся ширина трассы, и перепады высот, и количество поворотов.
Если я правильно понял, 3 пункта соответствуют трём абзацам объяснения:
1Основные - это поля, напрямую влияющие на идентификацию трассы. Дополнительные параметры не влияют на идентификацию трассы.
2. и выборка по ним, как правило, особого смысла не имеет. Это и уже обсуждавшаяся ширина трассы, и перепады высот, и количество поворотов.
1. Ты делаешь БД ТОЛЬКО для задачи идентификации трасс или для накопления/систематизации/ и дальнейшего хранения, использования и модификации информации о трассах?
Я бы предложил немного другую структуру.
1-й вариант - Справочник Автомобиль (комбинация Марка + Модель + Шасси + Двигатель).
При этом в справочнике Автомобиль можно указать только Марку, например Maserati.
(http://s22.postimg.org/4qu0t46fh/image.jpg) (http://postimg.org/image/4qu0t46fh/)
Затем когда станет известна модель и Двигатель - можно дополнить.
При этом в справочниках может соблюдаться иерархия. Т.е. Модель подчинена конкретной Марке, а Двигатель и Шасси либо конкретной Модели, либо конкретной Марке (например, дял случаев, когда конкретный номер двигателя устанавливался на несколько разных Моделей).
Соответственно в данных о соревновании достаточно будет указать ссылку на справочник Автомобили.
(http://s3.postimg.org/75a0vw28v/1957.jpg) (http://postimg.org/image/75a0vw28v/)
2-й вариант - указывать Марку, Модель, Шасси и Двигатель непосредственно в данных о соревновании. Т.е. вместо колонки "Автомобиль" будет четыре колонки: Марка, Модель, Шасси, Двигатель. Иерархия при этом также может остаться.
И самое сложное именно в том, чтобы учесть все ньюансы и все данные, и так называемые сложные случаи: вроде тех, когда гонщики менялись машинами.
Я бы предложил немного другую структуру.
1-й вариант - Справочник Автомобиль (комбинация Марка + Модель + Шасси + Двигатель).
При этом в справочнике Автомобиль можно указать только Марку, например Maserati.
(http://s22.postimg.org/4qu0t46fh/image.jpg) (http://postimg.org/image/4qu0t46fh/)
Затем когда станет известна модель и Двигатель - можно дополнить.
При этом в справочниках может соблюдаться иерархия. Т.е. Модель подчинена конкретной Марке, а Двигатель и Шасси либо конкретной Модели, либо конкретной Марке (например, дял случаев, когда конкретный номер двигателя устанавливался на несколько разных Моделей).
Соответственно в данных о соревновании достаточно будет указать ссылку на справочник Автомобили.
(http://s3.postimg.org/75a0vw28v/1957.jpg) (http://postimg.org/image/75a0vw28v/)
2-й вариант - указывать Марку, Модель, Шасси и Двигатель непосредственно в данных о соревновании. Т.е. вместо колонки "Автомобиль" будет четыре колонки: Марка, Модель, Шасси, Двигатель. Иерархия при этом также может остаться.
Я сам не специалист, но грамотные люди мне объяснили, что делать большую таблицу как в "Экселе" с многократно повторяющимися значениями - неправильно. Суть оптимизации и заключается в том, чтобы в базе данных были только индексы, а соответствующие им данные брались из справочников. Это называется реляционная база данных. Я этому верю и другие варианты не рассматриваю.
1. Хорошо, если так... .И самое сложное именно в том, чтобы учесть все ньюансы и все данные, и так называемые сложные случаи: вроде тех, когда гонщики менялись машинами.1. В этом проблемы нет, это я предусмотрел.
2. Для каждого соревнования будет список участников. Не заявочный, а именно участников, то есть комбинаций гонщик + автомобиль. Надо учитывать и варианты, когда гонщик садился в чужой автомобиль и делал пару кругов по трассе, как, например, Мосс на "Скарабе" в Монако. Это было неофициально, но есть фотографии. Этот факт надо зафиксировать в БД, а уж выводить или нет и где выводить - это вопрос другой.
2. "Комбинации" - это уже итоговый вариант вывода на экран.
Но изначально должны быть маленькие таблички и некая общая их структура.
Сложнее решить, как суммировать все виды тренировочных и соревновательных заездов. Ведь у нас были:
- два полуфинала + финал;
- два полуфинала + агрегатированный по их сумме результат;
- предквалификация;
- пятничная тренировка;
- субботняя тренировка;
- иногда две пятничные тренировки и одна субботняя;
- были тренировки и в день перед гонкой;
- собственно гонка;
- спринт;
- гонка с обратным расположением на решетке;
Как вот это все структурировать? Какими должны быть формы для "универсальной гонки"? Как узнать, какие таблицы (виды тренировок и гонки) заполнять для Большого приза Бельгии 1984 года и какие для Большого приза Макао 1985 года в Ф3? А какие для "Милле Милья" 1927 года, коль скоро БД планируется быть универсальной по всему автоспорту?
А ты лучше почитай эту тему с самого начала.Читал, разумеется. Написано много умных и не очень вещей. Но по большому счету последнее сообщение относится к 2008 году. С тех пор много воды утекло и у тебя могло многое поменяться как в требованиях к базе, так и в представлениях о ее структуре.
Если поймёте, чего я хочу, и предложите более эффективный вариант,В плане создания БД самое главное - представить как все должно работать и точно описать. Все остальное - только вопрос исполнения. Современные инструменты создания БД дают широчайшие возможности. Другое дело, что БД должна быть еще и максимально рациональной, без лишних связей и индексов, таблиц и повторяющихся данных. Но это - вопрос предварительной проработки.
Здесь немного в другом проблема. "Бухтением" я бы это не назвал. Архитектура БД должна быть должна быть проработана еще до начала ее создания. И оформлена в виде очень четкого технического задания. Вариант "сперва начнем делать, а потом поймем, что нам надо" имеет право на существование, но БД разрастается , обрастает ненужными таблицами, связями,индексами. И в случае сбоя порой разобраться, что случилось - затруднительно.