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

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Инструменты. База данных
« : Января 14, 2006, 10:27:01 »
Необходимость составления и использования базы данных по автомобильным соревнованиям становится уже очень острой, и я пытаюсь найти подходящее решение этой проблемы. Простейший вариант - "экселевская" таблица. Но она получится весьма громоздкой и не будет обладать некоторыми весьма полезными функциями. Базу данных более высокого уровня, говорят, может позволить создать "Майкрософт Аксесс", но у меня не получается разобраться с возможностями этой программы. Кто-нибудь имеет опыт работы с ней?
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #1 : Января 14, 2006, 10:33:27 »
У меня есть такой опыт. Примерно года два назад начал работу над двумя базами данных в Access - по советским кольцевым гонкам и рекордным заездам. Продолжаю ее и сейчас, по мере накопления сведений.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #2 : Января 14, 2006, 11:33:16 »
Некоторое время назад я начал приставать к Валере (pLuto) с просьбой помочь в выборе способа создания базы данных. Он попытался объяснить мне, что инструменты создания БД могут быть разные, но прежде всего надо продумать структуру БД. На этом месте я и застрял. Правда, кое-что полезное по этому поводу я нашёл на "Ностальгии": The ulimate database?
Там приведена схема баз данных со связями между ними. Правда, автор темы задумался об абсолютной БД, а у меня цели пока попроще, хотя надо всегда смотреть вперёд и предусматривать варианты развития БД.
Пока что мне нужны БД по соревнованиям, гонкам и результатам в гонках. Суть в том, чтобы всегда можно было бы сделать выборку по любому из полей таблицы (год, трасса, страна, соревнования, гонка, категория, класс, гонщик, заявитель, автомобиль и т.д.). Должен признать, что я не могу в точности очертить свои пожелания, потому что для этого мне надо знать возможность тех или иных существующих программ.
На этом этапе я застрял и с "Аксессом". Я никак не могу понять, что же он может. Я пробовал читать всякие пояснялся и объяснялки, но они написаны людьми, которые знают все возможности программы и стараются эти знания структурировать. Обычный подход, и он неудобен тем, что общая структура какой-либо программы новичку до лампочки, ему, который видит программу впервые, надо обяъснить основы на немного другим способом.
В "Аксессе" я не понимаю практически ничего. В "Экселе" просто: вот тебе таблица - заполняй. В "Аксессе" всё несколько сложнее. В чём суть этих усложнений? Какую задачу решали разработчики программы? Какие возможно открываются при таком способе построения таблиц? В чём он вообще заключается?
У меня сложилось такое впечатление, что там существуют базовые таблицы соответствий, в которых каждому появляющемуся затем в БД понятию, значению, названию и т.п. соответствует свой индекс. Упрощенно говоря, для БД по "Формуле-1" 2005 года есть таблица, в которой названию "Феррари" присвоен индекс 1, "Мак-Ларену" - 2, "Рено" - 3 и т.д. И в самой БД в ячейках столбца "Команда" будут на самом деле не сами названия, а индексы, а по ним название будет браться из базовой таблицы. Так или нет? Это было бы вполне логично для ументшения объёма БД.
Если обратиться конкретно к программе, то присоздании новой БД предлагаются три варианта: создание таблицы в режиме конструктора, с помощью мастера и путём ввода данных. Последний режим наиболее понятен, но тогда чем всё это дело отличается от "Экселя"?
Возможно, все эти вопросы кажутся глупыми, но уж больно я всё по-своему воспринимаю. От этого никуда не деться.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #3 : Января 14, 2006, 12:47:38 »
Ух, сколько вопросов-то...  Пока что могу сказать только одно: есть такое понятие "нормализованная база данных". То есть, например, если ты в одной таблице "Результаты гонок", в столбце "Команда" методично пишешь "McLaren" в каждой записи, соответствующей результатам гонщиков этой команды, то такая база данных не будет нормализованной, а если ты обозначишь "McLaren", скажем, индексом M, а в связанной таблице "Команды" сделаешь запись, что M - это команда "McLaren", да еще и добавишь какие-нибудь необходимые тебе сведения по этой команде, то это будет нормализованная БД. Как будто к такой нормализации должен стремиться каждый разработчик.
Создавать таблицы в Access лично мне легче при помощи конструктора, где сначала задается общая структура таблицы и типы данных для каждого поля, а затем эта пустая таблица заполняется данными. Если оказывается, что при создании структуры что-нибудь не предусмотрено или задано неправильно, всегда можно вернуться в конструктор и изменить параметры, при этом уже введенные данные, как правило, не теряются.
Запросы в БД - это, собственно, то, ради чего ее и стоит делать. Вместо того, чтобы долго и нудно перебирать свои веб-странички за семнадцать сезонов в поисках результатов, скажем, Энна Гриффеля, я просто открываю базу данных и в уже имеющемся созданном ранее шаблоне запроса задаю "Гриффель". Часы поиска вручную заменяются одним кликом мыши. Но и работа по созданию базы данных - это работа адская, честно скажу. Например, когда я вводил в свою БД информацию по сезону 1977 года, это потребовало в общей сложности создания примерно полутора тысяч новых записей во всех таблицах. И это один только сезон с двумя десятками гонок! А теперь представь, что ты собираешься сделать БД по всей истории мирового автоспорта. На такую работу уйдет несколько лет, даже если посвящать ей абсолютно все свободное время.
Для примера могу здесь разместить схему своей базы данных, но предупреждаю сразу: это далеко не идеал, и многие ее недостатки, не замеченные мною на начальной стадии работы, мешают мне сейчас весьма заметно. Но начинать все делать заново желания нет абсолютно никакого.Sourceress38732,5688310185

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #4 : Января 14, 2006, 13:41:28 »
Размести и, если возможно, как раз о недостатках расскажи. Это полезный опыт.
Я попробую пояснить, какого рода таблицы меня интересуют в данный момент. Мой интерес распространяется на период до начала 60-х годов. Это как раз то самое время, о котором я говорю, что тогда всё было по-другому. На самом деле сборные соревнования существуют до сих пор и никогда не исчезали, но сейчас просто принято некоторым их тогдашних гонок, входивших в состав сборных соревнований, придавать особое значение; а многие другие, имевшие значения тогда, но, "к несчастью", не имеющие в своих характеристиках "волшебных" слов, просто игнорируются.
В общем, я бы сказал, что список гонок в хронологическом порядке должен быть двухуровневым. На первом уровне указываются сборные соревнования, на втором - конкретные заезды, из которых они состояли. Скажем, какой-нибудь британский "большой приз" состоял из главной гонки и гонок поддержки. В таблице первого уровня указывается дата и характеристика всего соревнования (англичане называют это meeting). На втором - список всех гонок этого соревнования. Как правило, существовали какие-то ключевые гонки, венчавшие весь соревновательный день. Но не всегда они давали характеристику всему соревнованию. Скажем, "Международный приз КБГ" был главной гонкой всего соревнования, и другие заезды характеризовались именно через главную гонку, например: "В гонке в 500-кубовом классе во время соревнований "Международного приза" победил Мосс". А вот соревнования в Гудвуде всегда были "сборной солянкой" разнообразных гонок в разных категориях и классах. Гонки на приз Гловера или Вудкота были, несомненно, главными, но сами соревнования были известны только как пасхальные, осенние, весенние и т.п. Поэтому на первом уровне БД должно быть обозначение: "Пасхальные гонки БАРК". На втором уровне - полный список гонок.
Я ещё только занимаюсь составлением чернового списка послевоенных британских гонок, а с довоенными уже немного позанимался. Скажем, список гонок в Донингтоне 1933 года.
25.03.33 Donington      D&DMC meeting (7 races)
                           Event One 850cc u/s or s/c
                           Event Two 850cc s/c & 1100cc u/s (two heats)
                           Event Three 850cc s/c
                           Event Four                              1500cc u/s
                           Event Five 1500cc u/s (two heats)
                           Event Six 1500cc u/s or s/c
                           Event Seven 1500cc in any trim (ie Formule Libre)
13.05.33 Donington      D&DMC meeting (7 races)
                           Event One MG Midgets & Austin 7s u/s
                           Event Two MG Magnas, Wolseley Hornets, Singer Nines and Rileys other than Brooklands models
                           Event Three 850cc in any trim
                           Event Four 1500cc u/s
                           Event Five 850cc s/c & 1100cc u/s
                           Event Six 1500cc u/s
                           Event Seven 1500cc u/s or s/c
19.08.33 Donington      D&DMC meeting (9 races)
                           Event One 850cc Sports Cars
                           Event Two MG Magnas, Wolseley Hornets, Singer Nines and Rileys other than Brooklands models
                           Event Three                             850cc s/c or u/s
                           Event Four 1500cc u/s Sports cars
                           Event Five                              850cc s/c, 1100cc u/s
                           Event Six                               1500cc s/c or u/s
                           Event Seven 1500cc s/c or 2500cc u/s
                           Event Eight 3000cc u/s or 2500cc s/c
                           Event Nine 3000cc u/s or s/c
07.10.33 Donington      D&DMC meeting (6 races)
                           Event One 850cc
                           Event Two 1100cc
                           Event Three 1500cc u/s
                           Event Four Invitation, up to 3000cc
                           Event Five 3000cc
                           Event Six 1500cc s/c 2500cc u/s


Строчка с датой - это характеристика первого уровня, то есть описание всего соревнования. Ниже идут списки конкретных гонок. Мне надо, чтобы в БД сначала открывались только списки соревнований, а списки гонок можно было бы открыть дополнительно. Не уверен, что правильно выразил свою мысль.
Попробую так. В главной таблице будет указано:
25.03.33 Donington      D&DMC meeting (7 races)
13.05.33 Donington      D&DMC meeting (7 races)
19.08.33 Donington      D&DMC meeting (9 races)
07.10.33 Donington      D&DMC meeting (6 races)

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

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #5 : Января 14, 2006, 14:03:07 »
Цитата: Владимир Коваленко
Мне надо, чтобы в БД сначала открывались только списки соревнований, а списки гонок можно было бы открыть дополнительно. Не уверен, что правильно выразил свою мысль.

Понимаешь, собственно исходные таблицы в базе данных предназначены не столько для непосредственного просмотра, сколько для создания на их основе запросов. Если ты хочешь просто просматривать таблицы, то лучше использовать Excel - проще и меньше возни, а функции фильтров и поиска там, кажется, тоже имеются. Так что сначала, прежде чем браться за создание БД, сформулируй себе цели: какую информацию она должна включать, какие типы запросов на основе этой информации ты собираешься строить, какая степень подробности тебе необходима. Главное - типы запросов. Будут ли это просто списки гонок сезона, результаты отдельных гонок, выборки по конкретным гонщикам, автомобилям или командам, статистика по числу побед или, например, пройденных в гонках кругов? В зависимости от задач, которые ты будешь ставить, и будет определяться структура твоей будущей БД. Как говорил на четвертом курсе наш препод по предмету "Базы данных", это называется "концептуальный уровень создания БД", и он непременно должен быть самым первым. Так что давай следовать канонам, а не пытаться бросаться сразу в омут Sourceress38732,0610648148

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #6 : Января 14, 2006, 14:06:01 »
Давай следовать канонам, кто ж спорит? Итак, что такое вообще запросы?
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #7 : Января 14, 2006, 14:20:28 »
Не уверен, что способен дать исчерпывающе правильное определение, - может, pLuto сможет, если сюда заглянет? Но я попробую. Запрос - это команда выбрать из базы данных и вывести для просмотра в виде таблицы некоторые сведения, условия отбора которых задает сам пользователь. При этом выданная пользователю конечная таблица вовсе не обязательно должна состоять из столбцов одной-единственной исходной таблицы БД - это могут быть данные, взятые из разных таблиц, которые в структуре базы данных связаны между собой.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #8 : Января 14, 2006, 14:23:17 »
Понял. Буду думать.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

Оффлайн Валерий Лутошкин

  • Участник
  • *
  • Сообщений: 82
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #9 : Января 14, 2006, 16:08:02 »
Я вообще редко сюда заглядываю...
Но определение Алексея с моей кочки зрения абсолютно правильное, единственное уточнение - что потенциально непрофессионал может не понять: "вывести для просмотра в виде таблицы" - это не обязательное действие. Результат может и в памяти осесть и потом как-то разбираться программным кодом.
Подробнее о запросах и о построении баз данных можно прочитать в старой канонической книге Мартина Грубера "Понимание SQL". Книга гениальная. Начало там рассчитано на неподготовленных людей (хотя и с техническим складом ума), поэтому, думаю, первые пару-тройку глав для общего понимания концепции Владимиру будет прочитать нелишним. К Access оно не привязано совсем, но, думается мне, это не страшно.
http://doc.marsu.ru/lang/sql/sql2/index.html - вот здесь она в текстовом виде вся.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #10 : Января 14, 2006, 16:52:40 »
Вот структура моей БД:

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

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #11 : Января 15, 2006, 05:57:40 »
Итак, обещанный рассказ о недостатках. Таковых я в своей базе данных насчитываю шесть:
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

Оффлайн Александр Готвянский

  • Опытный участник
  • **
  • Сообщений: 439
  • Карма 34
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #12 : Января 15, 2006, 16:55:31 »
 
Цитата: Sourceress
Итак, обещанный рассказ о недостатках. Таковых я в своей базе данных насчитываю шесть:
 
 
2. Место. В таблице "Результаты гонок" пришлось установить для этого поля не числовое, а текстовое значение, чтобы можно было вписывать в него такие обозначения, как НФ, НС, НК и ДК. В результате нельзя составить запрос типа: "выбрать гонщиков, занявших места с четвертого и ниже". В отличие от предыдущего случая, этот вопрос встал передо мной сразу же при создании таблицы, но найти разумный выход из положения я не сумел и поэтому вынужден был сделать поле текстовым. Да и сейчас не знаю, как поступить. Можно было бы, конечно, сделать два поля, одно из которых будет текстовым, а другое - числовым (в нем все сошедшие, дисквалифицированные, не стартовавшие кодировались бы нулем), но это только увеличит объем БД и сделает ее более громоздкой.
 

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

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #13 : Января 15, 2006, 17:17:03 »
Черт побери!! Все гениальное просто!!

Оффлайн Александр Готвянский

  • Опытный участник
  • **
  • Сообщений: 439
  • Карма 34
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #14 : Января 15, 2006, 17:43:42 »
  Не надо аплодисментов. Я вот только что подумал, что эти цифры будут вылазить перед обладателем первых мест, поскольку они меньше. Лучше наверное заменить их на, например, 101,102 и т.д. Все равно таких финишных позиций не бывает. Но попробуй и первый вариант. Может тебе и так сойдет, я же не знаю твоих запросов.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #15 : Января 15, 2006, 17:49:52 »
Да нет, я-то оставлю у себя все как есть, потому что в таблице "Результаты гонок" уже больше пяти тысяч записей, и вводить новое поле и заполнять его вручную будет очень уж трудоемко  А вот для вновь создаваемой БД такой подход может здорово пригодиться.

Оффлайн Валерий Лутошкин

  • Участник
  • *
  • Сообщений: 82
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #16 : Января 16, 2006, 06:13:01 »
Мне не кажется хорошей идеей использовать в качестве _идентификатора_ чего-либо значимые параметры. Потому что практически невозможно предсказать, в каком месте нехватит заложенных в идентификатор ограничений на то или иное значение.
С моей кочки зрения наилучшее решение - когда именно идентификатор внутри базы - это простое поле Counter, т.е. уникальный неповторяющийся цифровой счетчик, значения которого присваиваются автоматически.
Дата, соревнование и прочие записи, которые, как я понял, использовались в ID, должны просто храниться в отдельных полях и, соответственно, ссылаться на конкретные ID (опять же, счетчики) в других базах.
Тогда любая реструктуризация базы (необходимость которой существует _всегда_) не приведет к катастрофическим последствиям.
Хотя это, конечно, мое кочкообразное суждение :) Но выстраданное достаточно большим опытом проектирования.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #17 : Января 16, 2006, 11:18:24 »
Пускай вас не смущает отсутствие моих комментариев - я читаю и перевариваю, но пока с трудом.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #18 : Января 16, 2006, 12:55:41 »
Мой шестизначный ID устроен так, что ограничения, в него заложенные, ни в коей мере мешать не могут. Суди сам: годы, которые будут представлены в БД, целиком относятся к XX веку, значит, двух первых цифр вполне хватит. Больше двух с небольшим десятков соревнований за сезон в СССР не проводилось никогда, значит, тоже достаточно двух цифр. И, наконец, каждое из этих соревнований включало в себя максимум десять гонок - еще две цифры. С этим как раз все в порядке. Счетчики в качестве ключа я стараюсь, наоборот, не использовать именно потому, что значение не несет никакого смысла и лишь увеличивает объем базы данных впустую. А если бы я в таблице "Гонки" поставил счетчик в качестве ключа, запрос на результаты гонки вообще стал бы кошмаром, потому что пришлось бы набирать в запросе полное длинное название гонки, со всеми запятыми и кавычками. Идея составного значимого ключа, который бы служил основой для запросов, пришла мне в голову слишком поздно...

Оффлайн Сергей Блинов

  • Опытный участник
  • **
  • Сообщений: 108
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #19 : Января 16, 2006, 13:49:10 »
Тоже немножко прокомментирую:
1. ID - согласен с pLuto. Конечно можно позабивать и со смыслом номера, но можно запутаться и случайно присвоить одинаковые номера.
2. Суть структуры в чем, в том, что показываются связи между различными таблицами данных, которые в свою очередь являются самостоятельными источниками. Если с помощью правильно построенных запросов(отчетов, форм и т.п.) можно вывести таблицу "Результаты чемпионатов СССР", тогда эта таблица и не нужна.
3. Можно выполнять запросы "по содержанию", т.е. если есть в графе БК 2 фамилии запрос на 1 из них, уже будет удовлетворять условию отбора. В крайнем случае можно использовать поиск по маске *name*.
4. Для времени можно придумать вывод в форму (все равно так смотреть результаты удобнее) с приведением к виду чч.мм:сс делением без остатка на 3600 и 60 соответственно
5. Результат гонки есть прохождение определенной дистанции за определенное время, поэтому для отставших менее чем на круг определенно надо задавать временем, среднюю скорость, отставание в сек от лидера расчитывалось машиной. Здесь я имею ввиду что лучше забивать в таблицы минимум данных, которые могли бы быть получены автоматически.
6. Отрицательные номера лучше, кто знает вдруг появится необходимость протоколировать соревнования с большим кол-вом участников. Можно будет отсортировать по маске.
Сергей Блинов

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #20 : Января 16, 2006, 14:06:22 »
1. Как можно ввести одинаковые значения в ключевое поле? Access тут же выдаст сообщение, что значения поля повторяются.
2. Если бы все чемпионаты СССР состояли из одной гонки, таблица не была бы нужна, но ведь чемпионаты-то были как многоэтапные, так и одноэтапные...
3. Можно подробнее? Что такое запрос по содержанию и как он строится в Access?
4. Форм у меня в БД нет - возни много, а толку мало. Все равно они мне не нужны (по крайней мере, на данный момент, когда база данных еще очень далека от завершения).
5. Все верно, лучше минимум данных, остальное вычисляется автоматически. Но я уже писал выше, что те данные, с которыми я работаю, не дают мне возможности автоматизировать вычисления.Sourceress38733,952650463

Оффлайн Валерий Лутошкин

  • Участник
  • *
  • Сообщений: 82
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #21 : Января 17, 2006, 10:30:09 »
Цитата: Sourceress
Мой шестизначный ID устроен так, что ограничения, в него заложенные, ни в коей мере мешать не могут. Суди сам: годы, которые будут представлены в БД, целиком относятся к XX веку, значит, двух первых цифр вполне хватит. Больше двух с небольшим десятков соревнований за сезон в СССР не проводилось никогда, значит, тоже достаточно двух цифр. И, наконец, каждое из этих соревнований включало в себя максимум десять гонок - еще две цифры. С этим как раз все в порядке. Счетчики в качестве ключа я стараюсь, наоборот, не использовать именно потому, что значение не несет никакого смысла и лишь увеличивает объем базы данных впустую. А если бы я в таблице "Гонки" поставил счетчик в качестве ключа, запрос на результаты гонки вообще стал бы кошмаром, потому что пришлось бы набирать в запросе полное длинное название гонки, со всеми запятыми и кавычками. Идея составного значимого ключа, который бы служил основой для запросов, пришла мне в голову слишком поздно...

Я о чем и говорю - для текущих задач этого индекса хватает, но если тебе когда-нибудь захочется расширить базу - да тривиально добавить туда 19 или 21 век - то ты уже натыкаешься на концептуальную невозможность этого. Если ты уверен на 100%, что никогда не захочешь расширить свою базу и эта база никогда не будет включена в чужие как подмножество - тогда конечно. Но такая уверенность - штука крайне редкая.
А про запрос на результат гонки - не понял. Ты же знаешь дату ее проведения, почему ты не делаешь запрос по дате? Я уж не говорю про ключевое слово NEAR, которое позволяет искать по части поля (например, по части названия).
В современных условиях, когда размер - далеко не самый определяющий параметр, экономить на спичках (т.е. на счетчиках) я бы таки не стал. Хотя каждому свое, конечно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #22 : Января 17, 2006, 12:54:03 »
Раз меня интересует исключительно советский автоспорт, то шестизначный индекс вполне удовлетворяет этим условиям. Дореволюционными и нынешними российскими гонками заниматься не планирую - это стопроцентно. Первыми давно уже занимается другой человек, ну а на нынешний автоспорт и без меня знатоки найдутся.
Запрос на результаты гонки подразумевает, что мне надо найти их, зная только год и название гонки. Не могу же я знать даты всех проведенных гонок! А с использованием NEAR вышел некоторый облом. Какой там синтаксис выражения с его использованием?

Оффлайн Валерий Лутошкин

  • Участник
  • *
  • Сообщений: 82
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #23 : Января 18, 2006, 06:05:59 »
Сорри, про NEAR я прогнал - потерял мысль. Конечно же, имелся в виду оператор LIKE.
WHERE (DATE BETWEEN 19550101 AND 19551231) AND (NAME LIKE '%КУБОК%')
выдаст все гонки 1955 года, в названии которых присутствует слово КУБОК.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #24 : Января 18, 2006, 10:32:55 »
Насколько я понимаю, это часть запроса, составленного на SQL... А  конструктор запросов в Access подобное выражение поймет?

Оффлайн Сергей Блинов

  • Опытный участник
  • **
  • Сообщений: 108
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #25 : Января 18, 2006, 11:15:42 »
В Access запросы можно писать и на SQL. Нужно только привести запрос к данному виду (выбрать в меню).Sergey38735,8349189815
Сергей Блинов

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #26 : Января 18, 2006, 11:19:15 »
Это я знаю, но уж больно неохота связываться с SQL, раз есть конструктор...

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #27 : Января 28, 2006, 08:37:58 »
Почитал я Валерину книжку, посмотрел на дискуссию, посоображал маленько и решил, что чего-то понял и пора приступать к работе.
Для начала мне надо немного - только списки гонок, но надо заранее заложить в БД возможность безболезненного расширения путём добавления новых таблиц.
Как я понял, в любой таблице всегда существует столбец с уникальными данными, которые нигде больше не повторяются. Остальные данные в строке могут появляться несколько раз в БД. Скажем, если это название трассы, то повторяющимися данными будет название страны и местонахождение.
"Нюрбургринг"         Нюрбург     Германия
"Хоккенхаймринг"      Хоккенхайм  Германия
"Монжуик"             Барселона   Испания
"Каталунья Монтмело"  Барселона   Испания

Поэтому сначала надо всё продумать, решить какие данные в таблице будут повторяющимися и следать для них отдельные таблицы, из на которые просто делать типа ссылок. В приведённом примере надо сделать две таблицы: для городов и стран. В таблице городов могут быть такие поля, как страна, координаты и, возможно, что-то ещё. Поскольку названия городов могут и совпадать, их не получится принять в качестве ключевых слов, поэтому в таблице будет отдельный, ключевой столбец с идентификатором, уникальный для данной совокупности "город-страна-координаты".
В таблице стран может быть только один столбец - с названием страны. Больше от неё ничего не надо.
Таким образом, составляя каталог трасс, мы будем одновременно заполнять три таблицы, но это будет не утроение работы, а упрощение с точки зрения перспективы. Вносим в таблицу стран Германию и обращаемся к таблице городов, в которую вносим Нюрбург и делаем связь с названием страны в соответствующей таблице. Правильно я мыслю?
Теперь заполняем главную таблицу, трасс, и вносим в неё название трассы и тут же связываем его с таблицей городов, из которой добывается, при необходимости, город и дальше по связи - название страны.
Название трассы может повторяться, особенно, если у ней нет названия, а есть описание (типа четвертьмильный трек где-нибудь на городской ярмарке в Айдахо); либо параметры трассы могут меняться, и столбец с названием трассы может оказаться не уникальным. Уникальным оказывается сочетания нескольких параметров. Для каждого их них просто присваивается идентификатор. Это и есть ключевое поле.
Скажем, идентификатор 001 - это сочетания названия "Нюрбургринг" и длины одного из вариантов, возьмём 22 км. 002 - это "Нюрбургринг" и 4,5 км, 003 - это "Нюрбургринг" и 20 км. В зависимости о того, на каком варианте трассы проводится гонка, мы ставим в поле "Трасса" идентификатор 001, 002 или 003. То есть реально в ячейках будут идентификаторы, а для поля будет задана связь с таблицей трасс, и если мне надо будет посмотреть список гонок в каком-то году (это мы не обсуждались, но такая БД будет строиться по такому же принципу), база будет по связям обращаться к нужным идентификаторам и вытаскивать из различных мест нужные названия.
Правильно я мыслю?
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

Оффлайн Александр Готвянский

  • Опытный участник
  • **
  • Сообщений: 439
  • Карма 34
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #28 : Января 28, 2006, 12:40:09 »
В общем да. А в частностях я и сам не разбираюсь

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #29 : Января 28, 2006, 13:43:53 »
Начал разбираться конкретно в работе "Аксесса".
"Создание таблицы с помощью мастера", как мне кажется, не подходит. Теоретически там можно найти поля, которые полходят под ситуацию, но на самом деле лучше всё делать самому. Поэтому лучше использовать конструктор?
Делаю первую таблицу - "Страна". В ней пока одно поле, с названием страны. Нужен ли дополнительный идентификатор, или само название может служить идентификатором? Может ли идентификатор быть криллическим? Если нет, то название страны не подходит. Можно в качестве идентификатора воспользоваться международными кодами (RUS, AUT, D, F и т.д.)? Что надо делать, чтобы оставить в будущем возможность добавлять поля (скажем, может понадобиться добавлять названия этой страны на разных языках)?
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #30 : Января 28, 2006, 16:04:41 »
Я не совсем все-таки понял, что ты писал в предыдущем сообщении. Гораздо более понятно было бы, если бы ты начертил схему связи таблиц, которые ты хочешь делать, и выделил бы в них ключевые поля (подобно схеме на предыдущей странице темы). Тогда вникнуть в суть твоих идей стало бы куда проще, ergo, дать совет - тоже проще. Пока что могу с уверенностью сказать насчет таблицы стран. Ясно, что здесь связь будет типа "один-ко-многим", значит, поле, по которому будет осуществляться связь (какое бы ты ни выбрал - международный код или что-нибудь еще), должно быть ключевым в таблице стран. Поля в будущем можно добавлять практически без ограничений - конструктор таблиц это позволяет сделать без труда.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #31 : Января 28, 2006, 23:40:16 »
Ключевое поле может быть на кириллице?
И если в таблице гонок мне нужны поля трасс и стран, а страны связаны уже с таблицей трасс, то можно ли делать связь из таблицы гонок только с таблицей трасс, чтобы при этом автоматически отображалась страна?
Попробую начертить схему.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #32 : Января 29, 2006, 03:51:07 »
Кажется, кириллица вполне может быть использована для ключевого поля... Ну да, точно, я же использовал ее для ID автомобилей в таблице "Автомобили". И ничего - работает!
А на второй вопрос смогу ответить, скорее всего, лишь имея перед глазами предполагаемую схему твоих данных... Так что ждем-с

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #33 : Января 29, 2006, 04:03:16 »
Да вот, рисую.
Кстати, Валера, помнишь, как ты мне пытался объяснять, что прежде чем создавать базу данных, надо хорошо продумать всю структуру, а я никак не мог этого понять. Я этого не понимал, потому что не понимал сам принцип построения бад данных из отдельных таблиц для уникальных данных. То есть создаются отдельные таблицы для стран, городов, трасс, гонщиков, автомобилей и т.п., а собственно та БД, ради которой всё это затевается - это совокупность ссылок из общей таблицы на поля и ячейки частных. Вот тут действительно надо сначала чётко представить структуру.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #34 : Января 29, 2006, 05:09:07 »
Получилось вот что:

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

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #35 : Января 29, 2006, 05:36:57 »
Понятно пока что только одно: похоже, ты так и не сумел понять, что, как правило, связи между таблицами в базах данных - это связи типа "один-ко-многим" или "много-к-одному", а говоря иначе, в одной из двух связанных таблиц поле, по которому осуществляется связь, обязательно должно быть ключевым. У тебя же связь по ключу не осуществляется нигде, а все связи - типа "многие-ко-многим"... Черт, не могу более понятно объяснить... pLuto, помоги, а?

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

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

Оффлайн Валерий Лутошкин

  • Участник
  • *
  • Сообщений: 82
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #37 : Января 30, 2006, 09:01:59 »
Да, для того, собственно, и вводятся идентификаторы, чтобы их использовать в других таблицах. Во-первых, уменьшаются размеры баз (вместо строкового поля в 255 байт хранится одно-двух-четырехбайтное поле ID), во-вторых, изменение в таблице-справочнике (например, исправление опечатки в названии трассы) не ведет за собой необходимость изменений где-то еще.
Так что если перерисовать твой рисунок так, чтобы стрелки везде начинались от "Идентификатор", то будет вполне удобоваримо.
Правда, не совсем понял смысл выделения "Названия соревнований" и "Названия гонок" в отдельные таблицы - может быть много гонок/соревнований с одинаковыми названиями?
Выделение отдельной таблицы "Даты" тоже, думаю, нецелесообразно.
Сразу еще рекомендую не называть в каждой таблице поле "Идентификатор", а называть его, например, ID_страны, ID_класса и так далее. Иначе потом запутаешься в результирующих таблицах. Вообще, надо стараться не создавать в разных таблицах полей с одинаковыми названиями - если, как раз, они не связаны с другими полями с этим же названием.  Т.е., например, в таблице гонки должны быть поля:
ID_гонки (счетчик, ключевое), Дата_гонки, ID_трассы, ID_соревнования, ID_названия, ID_категории, ID_класса, Дистанция, Количество_кругов.
Сама таблица по большей части будет состоять из чисел - значений ключей других таблиц.

Оффлайн Валерий Лутошкин

  • Участник
  • *
  • Сообщений: 82
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #38 : Января 30, 2006, 09:03:26 »
Кстати, какой был день недели в тот или иной день - можно получить стандартными функциями Access, соответственно, хранить в базе это значение нецелесообразно совсем.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #39 : Января 30, 2006, 09:50:10 »
Насчёт названий соревнований и гонок. Во все времена существовала практика проводить в один день несколько гонок для разных классов. Традиционная трактовка истории автоспорта подразумевает рассмотрение каждого класса в отрыве от общей ситуации, а если посмотреть шире, то окажется, что существовали регулярные соревнования, которые имели свои традиции. Скажем, соревнования в Гудвуде или в Бруклендсе в пасхальный понедельник или в августовский выходной. Из года в год они проходили в один и тот же день и становились особым явлением. Поэтому в таблице названий соревнований должны быть и пасхальные, и августовские соревнования, и соревнования в подарочный день в Брэндс-Хэтч, и недели скорости в Ницце или Дайтоне.
А вот в составе этих соревнований были традиционные гонки. Скажем, "Приз Ричмонда" в пасхальных соревнованиях в Гудвуде сначала разыгрывался для машин "формулы-1", а "Кубок Лаванта" - 1100-кубовых; когда в 1952-53 годах "формула-1" была в забвении, в этом классе гонку ещё проводили, но "Кубок Лаванта" "повысили" до "формулы-2", а так как этот класс в 1953 оказался высшим, этот приз повысился до самого высокого статуса и в 1954 году остался в этом статусе, только формула была другая - первая.
В общем, я вижу смысл в том, чтобы списки традиционных гонок составлять. И это я ещё не упоминал основу основ традиционной трактовки - "большие призы".
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #40 : Февраля 12, 2006, 02:14:12 »
А вот такой вариант понятен?
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #41 : Февраля 12, 2006, 18:01:31 »
Ух... Я честно пытался вникнуть в столь запутанную структуру, но мозгов не хватило  Похоже, ты хочешь все и сразу. А не проще ли было бы составить сначала две-три основные таблицы, связать их, внести в каждую по десятку тестовых записей и испытать на этом "макете" все виды запросов, какие он может обеспечить? Если все работает, пристрой следующую табличку, снова пробные записи и пробные запросы с использованием этой новой таблички. И так далее. Понимаешь, тут есть риск с ходу потеряться во всей этой паутине связей и самому забыть, как устроена твоя база данных. Хотя это я рассуждаю со своей точки зрения; тебе-то, как творцу всего этого, наверняка схема понятна. Но все-таки осмелюсь дать тебе совет: когда связываешь два поля в разных таблицах, лучше называй его одинаково и в той, и в другой - для пущей ясности.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #42 : Февраля 12, 2006, 22:36:19 »
Цитата: Sourceress
Но все-таки осмелюсь дать тебе совет: когда связываешь два поля в разных таблицах, лучше называй его одинаково и в той, и в другой - для пущей ясности.

А так как одно из связываемых полей всегда - идентификатор, то вместо названия поля везде будут названия идентификаторов?
Возможно, проще будет понять всё это, если напомнить, что всё это безобразие задумано ради двух основных таблиц, расположенных в левой верхней части, в которых должна быть информация о соревнованиях и гонках. Представь себе где-нибудь в журнале список соревнований: дата, трасса, соревнование. "Соревнование" - это несколько гонок, проводимых в один день. Вот, скажем, как на этапах чемпионата СССР или "Кубка дружбы". Зачастую необязательно знать списки гонок, надо посмотреть или отсортировать лишь соревнования. Но также надо иметь и использовать информацию о конкретных гонках: дата, трасса, название или описание гонки, категория, класс, количество кругов, дистанция.
Вот, это две остальные таблицы, остальные - это таблицы для полей с повторяющейся информации. Они нужны для того, чтобы заполнить эти основные таблицы.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #43 : Февраля 13, 2006, 03:06:38 »
Может, в схеме БД стоит что-то выделять цветами для пущей наглядности?
Я представил англоязычный вариант схемы в теме The ulimate database? и получил кое-какие дельные отклики. Аллен Браун ещё дал ссылку на тему Scribble, Scribble, Scribble.
Один из его советов - собирать нужную информацию в текстовом формате, находить в ней самые необычные и сложные случаи и строить БД с их учётом. Логично.
Ещё я не задумывался о сревнованиях, длившихся несколько дней. Это тоже надо учесть.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #44 : Февраля 19, 2006, 09:25:14 »
Прочёл эти темы, и в них упоминаются язык SQL и формат XML. Я плохо представляю, о чём идёт речь, но хочу понять, есть ли смысл мне разбираться в этих языках-форматах, либо достаточно освоить "Аксесс". Кто-нибудь может пояснить?
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

Оффлайн Сергей Блинов

  • Опытный участник
  • **
  • Сообщений: 108
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #45 : Февраля 20, 2006, 11:10:36 »
Как мне один друг программист написал, заранее прошу прощения за стиль
Цитата: Will
А че тут велосипед изобретать?
Чтоб отовсюду доступно было - только сайт.
Если сайт - то Mysql + php + домен + программист
Вот и все. Че еще?
 
Пусть ищут себе программера и делают. самим им не сделать (судя по их уровню
общения на форуме).
 
Если access - то проблема с обновлением: им придется достаточно часто
выкладывать свою базу, а вам (тебе в том числе) придется все время эти
обновления скачивать.
 
К тому же, в первом случае можно работу по заполнению базы разделить: скажем
есть 4 добросовестных человека, вот они каждый в базу и вносят добавления. У
каждого свой логин/пасс, права, обязанности и т.д.
 
Могут поискать готовые движки, но по-моему навряд ли найдут - т.к. ваша
дрянь узкоспециализированная.
Сергей Блинов

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

  • Администратор
  • Опытный участник
  • *****
  • Сообщений: 22 586
  • Карма 2113
    • Просмотр профиля
    • История автоспорта
Re: Инструменты. База данных
« Ответ #46 : Февраля 20, 2006, 12:47:34 »
Стиль пока не имеет значения, если есть полезные мысли, а они сейчас очень нужны.
Значит, нужно искать программиста среди "формулистов". Но ему всё равно надо будет дать уже готовую структуру.
Если кто-то чего-то не может, не умеет или не понимает, он доказывает, что это никому не нужно и даже вредно.

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #47 : Мая 19, 2006, 12:08:04 »
Вопрос к pLuto: если прописывать в BDE алиас к базе данных, сделанной в Access, обязательно ли задавать в ODBC Administrator имя пользователя и пароль? Если их не задавать, сделанное в C++ Builder приложение все равно требует их ввода при каждом подключении к базе данных. В принципе ничего страшного, но надоедает просто. Если есть способ от этого избавиться, напиши, плиз, как это сделать.
 
Еще вопрос. Допустим, я создаю в C++ Builder приложение, которое через Query делает запрос к базе данных (по нескольким таблицам сразу) и выдает полученную таблицу в DBGrid. Имеют ли эти компоненты какое-нибудь свойство, позволяющее автоматически подсчитать количество записей в получаемой таблице?
 
Да, между прочим, твой давнишний совет по SQL-овскому оператору LIKE в Access не действует. Почему - не знаю...Sourceress38856,8780092593

Оффлайн Александр Амецинский

  • Опытный участник
  • **
  • Сообщений: 162
  • Карма 0
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #48 : Мая 19, 2006, 12:32:28 »
Цитата: Sourceress
Да, между прочим, твой давнишний совет по SQL-овскому оператору LIKE в Access не действует. Почему - не знаю...

Можно попробовать регулярные выражения...
Правда не знаю, есть что-то подобное в Access...AlexF138856,8877893519

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

  • Историк
  • Опытный участник
  • ****
  • Сообщений: 1 755
  • Карма 264
    • Просмотр профиля
Re: Инструменты. База данных
« Ответ #49 : Мая 19, 2006, 13:17:13 »
Вот такие глюки и заморочки "аксессовского" интерфейса меня уже слегка достали, потому-то и решил попробовать написать приложение, которое бы позволило выполнять хотя бы самые основные вещи, которые я делаю со своей БД, не запуская при этом сам Access. На работе я часто имею дело с C++ Builder, в нем и начинаю сейчас понемногу экспериментировать. Там, кстати, оператор LIKE работает как часы. Еще интересно, что если в компонент Query скопировать уже готовый текст запроса на SQL из Access, работать он не будет! А если тот же самый запрос сочинить в C++ Builder вручную, все в порядке. Видимо, тут дело в какой-то разнице между "борландовским" и "мелкомягким" стандартами SQL.