Подумал, что ежели создавать базу данных игр...
Кто бы что предложил?
К примеру не совсем понятно как хранить запись об игре, ведь команды две
И с точки зрения объектной модели, толи дублировать поля, толи в один столбец напихать шоб потом в запросах "или" не плодить
Во вложении пример данных с сайта Кулички

А че тут думать:
дата игры, ID команды1, ID команды2, счет, что-то еще...

Сначала надо зафиксировать статику - время, место, турнир, тур, судейская коллегия, тренеры, состав команд. Далее зарегистрировать все важные события: замены, карточки, удаления, голы. Также желательно указать, где можно найти видео или куда обращаться за таковым. Всё остальное - где и как хранить инфу об игре - непринципиально. мтд

Да! Правильно. К моей структуре БД добавить ID записи (это в "взрослых" БД само заставляется), и к ней привязать дополнительные таблички - типа [ID игры, кол карточек команды 1, кол карточек команды 2], можно добавить поле "№ команды" ) - 1, или 2, тогда можно сократить кол полей вдвое. Все это хорошо, но чем правильнее БД, тем неприятнее строить селекты из нее, геморнее...

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

Foxtrot
Подумал, что ежели создавать базу данных игр...

Конкретно футбола, или "произвольных"?

Foxtrot
К примеру не совсем понятно как хранить запись об игре, ведь команды две

Да хоть десять, какая разница то? Сыгранная игра это одна сущность, а команда - совсем другая. И ассоциация между ними с заданной кардинальностью (можно замутить даже типа "строго 2-к-1"). Выяснив все "атрибуты" которые мы хотим учитывать уже можно поделить их по "владеющим" сущностям - кто к "игре" привязан, кто к "команде", кто к "голу", кто к "нарушению" и т.п. Глубина проработки может быть разной - от пяти-десяти сущностей "на всё", до нескольких тысяч - например если попутно отслеживать индивидуально игроков, их карьеру, физические данные, погоду во время матчей, место проведения, число болельщиков для обоих команд, телеаудиторию/трансляции по странам и т.п. Тут можно описывать столько всего... главное вовремя остановиться

Foxtrot
И с точки зрения объектной модели, толи дублировать поля, толи в один столбец напихать шоб потом в запросах "или" не плодить

В объектной модели нет ни полей ни столбцов (кстати, в реляционной, на логическом уровне тоже. "Столбцов" же вообще нет нигде кроме электронных таблиц Ну это так, к слову). И "запросов" в ней тоже нет

> К примеру не совсем понятно как хранить запись об игре, ведь команды две
Да хоть десять, какая разница то

В футболе не более 2х команд в игре, и не предвидится изменений в этом (до 3х и более) в ближайшие десятилетия. Поэтому, для сокращения количества табличек можно и подумать о "двойных" полях, типа набраных очков, или карточек (ID игры, карточек1 I, карточек2 I), а не таблички Карточки {ID игры, ID команды, желтых карточек}, правда надо соблюдать некое правило "что есть команда №1, а что есть №2". Кстати, это соображение и ломает все это ("первый" и "второй") построение ) Надо делать как ИК сказал, на произвольное кол. команд

of63
Надо делать как ИК сказал, на произвольное кол. команд

Есть и еще причина. Проектирую БД, для любой отрасли, всегда стоит смотреть рядом.
И если для футбола, спректирована правильно, легко потом все это воткнуь в байдарки и каноЭ )))
Ну и еще чутка заработать)))

продолжим
Как хранить результат?
К примеру если есть таблица хронологии матча, т.е. кто на какой минуте забил и тд. Каждый раз суммировать голы или хранить отдельно? Если всеже отдельно, то в каком виде? В символьном, числовом, может вообще в одной ячейке=одним числом?

Таблицу событий:
ИД команды1, ИД команды 2, событие, датавремя, что-то еще

Foxtrot
продолжим
Как хранить результат?
К примеру если есть таблица хронологии матча, т.е. кто на какой минуте забил и тд. Каждый раз суммировать голы или хранить отдельно? Если всеже отдельно, то в каком виде? В символьном, числовом, может вообще в одной ячейке=одним числом?

Поначалу подумал попал в Курилку.
Глянул - не ошибся ли. Но нет вроде, и темы старые рядом.

А в чем вообще проблемы - все элементарно же, как на складе: приход-расход, кладовщик такой-то.
Т.е. однозначно - Справочник команд, Справочник игроков, Справочник городов (стадионов) - с их уникальными id, ну также и собственно Журнал событий.
В котором столбцы: ID места события, ID команды1, ID команды2, Результат события, Дата-время (или дата и время) события.
Все остальное в принципе потом легко вычисляемо.
Результат события мне кажется проще сделать в два числовых столбца. Легче потом вычислять будет.

Crispy
все элементарно же, как на складе: приход-расход, кладовщик такой-то

Кто кладовщик здесь?
Интерпретация приход-расход тут есть однозначная?
Там в приход-расход числа с двумя после запятой (типа точки).
Здесь очки - разница забитых-пропущенных, всего забитых, личная встреча
В мелочах прячется дьявол.
Склад - сложное, а это фигня. А вот в фигне и спрятано для этого с виду нехорошего, пока не читал Булгакова, субъекта

Ydin
Поначалу подумал попал в Курилку.

Тоже. Но нигде у Фокстрота не сказано, что это не про Фокс.
Презумпция. О том, как написать на Фоксе.
И Курилка отпадает. А Полит Форум ваашче ни причем

of63
В футболе не более 2х команд в игре, и не предвидится изменений в этом (до 3х и более) в ближайшие десятилетия.

Это на самом деле не столь важно. "Проведенная игра" в любом случае отдельная сущность от "участвующих команд" - и будут они там отмечены через 2 атрибута "Принимающая команда" и "Гостевая команда", либо же через ассоциативную сущность (коллекцию "участвующие команды" в ООП языках) - вопрос более тонкого проектирования, т.е. не первый.

of63
Поэтому, для сокращения количества табличек

Зачем? Какова цель "сокращения количества табличек"? Смешать людей и коней, королей и капусту
Объектов/сущностей/таблиц должно быть не "побольше" и не "поменьше" - их должно быть ровно столько, сколько надо Без смешивания 100500 атрибутов в одну сущность, и без безумного разделения всего и вся на бинарные отношения (таблицы из 2 полей - которые в теории позволяют "собрать" потом воедино всё что угодно - путём гигантского числа "соединений" таких "предельно нормализованных таблиц").

of63
можно и подумать о "двойных" полях, типа набраных очков, или карточек (ID игры, карточек1 I, карточек2 I)

Ага, и потом ругаться на SQL, который ну никак не хочет легко и просто посчитать, к примеру, сколько за турнир/этап набрала карточек та или иная команда Вообще-то нарушение имеет свои атрибуты (жёлтая или красная карточка), может быть интересна временная метка этого нарушения (на какой минуте), и главное - нарушение связывает "игру" и только ОДНУ "команду" (и даже более тонко - игроков, а не всю команду. Хотя в хокее интереснее, там и "взаимные удаления" бывают - типа нарушение одно, а виновных два, а то и вся команда, если это драка ), а не обе. Вот "гол" - он связывает игру и обе команды, заодно и кучу участвующих игроков - пасующего, забивающего, вратаря-дырку - ну и тоже имеет свои атрибуты - и время, и всякие признаки "со штрафного/с углового/с пенальти", автогол опять таки Для расширенных "текстовых трансляций" и для серьёзных исследований может быть надо ещё и указывать в какую часть ворот попал мяч (чтобы потом считать статистику попаданий "в девятку" отдельных игроков, например).
Кстати, начать формализацию можно и с чтения этих самых "текстовых трансляций" - там как раз ключевые понятия и все основные моменты присутствуют.





Исправлено 1 раз(а). Последнее : Igor Korolyov, 04.07.18 14:00

Таблицы:
Команды: ID,Name,FullName, PlayersID, ... (тренеры, массажисты, болельщики, споносоры, пресса, история команды, ... )
Игроки (PlayersID): ID,Name,FullName, ...
...

Ydin
Склад - сложное, а это фигня.

Мини-склад. Ну или мини-фигня, кто как пожелает.

В общем любая, на первый взгляд элементарная задача, со временем превращается... в 1С )))

И кстати да (у Игоря выше) про удаление (либо еще замену) игроков - можно добавить еще 2 столбца.
В первом - ID удаляемого (заменяемого) игрока.
Во втором - заменяющего игрока. Т.е., если второй столбец пустой - было удаление, если непустой - замена. И наоборот - при возвращении игрока в игру, первый столбец пустой.

А так, понемногу, действительно может обрасти до чего-то уже не столь "мини".

Ну так и про отвод судей тоже забыли...

Crispy
Мини-склад. Ну или мини-фигня, кто как пожелает.

Это такой в этой фразе прием на непредсказуемость в контексте ранее сказанного.
Прощальный фол, типа я нафигачил, но желаю Вам всего самого наилучшего.
В переводе, в глубине души чувствую, что она, моя душа, может против фразы этой.
Но призывает ее хотя бы как-то отмазать.
Типа, Crispy, чего ты так по-мелкому там, где нет у тебя мотива...