|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
22.01.2014, 20:21
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
Добрый вечер. Проектирую ДБ «Футбольные клубы». Получилась такая вот физическая модель. Подскажите, что по вашему мнению не так, что исправить, что добавить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2014, 20:43
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
Include.nv, Для PHONE я бы выбрал CHAR/VARCHAR - там может быть несколько форм записи с пробелами/скобками/тире/кодами стран и регионов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2014, 21:08
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
DarkMasterInclude.nv, Для PHONE я бы выбрал CHAR/VARCHAR - там может быть несколько форм записи с пробелами/скобками/тире/кодами стран и регионов. Тоже про это думал. Спасибо. Может есть еще какие-нибудь замечания? Я вот думал, надо ли разбивать адрес на отдельные поля Страна, Город и т.д. Но думаю, в данной БД в этом нет смысла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2014, 21:25
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nv, А что, у клуба всегда ровно одна команда? Или в этой задаче это не важно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2014, 21:45
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nv, у футболистов бывают псевдонимы. футболисты играют в игре определенные периоды времени либо всю игру. у тебя этого нет. голы - где голы, удаления, карточки, штрафные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2014, 22:10
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
miksoftInclude.nv, А что, у клуба всегда ровно одна команда? Или в этой задаче это не важно? В данной задаче это не важно. MasterZivInclude.nv, у футболистов бывают псевдонимы. футболисты играют в игре определенные периоды времени либо всю игру. у тебя этого нет. голы - где голы, удаления, карточки, штрафные? Статистику не затрагиваем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 10:32
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nv, Футболист может переходить из клуба в клуб и, наверное, нужно знать когда он перешел и когда за какой клуб играет.... Еще не понятно как хранится результат игры (поле варчар?) как запросы на победителя и счет строить? (тут можно было бы для оппонентов игр сделать отдельную табличку с game_id с записью на каждого оппонента, признаком что он победил, проиграл, ничья и сколько голов забил) И что такое табличка Positions? не совсем понятен ее смысл.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 10:53
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
И команда всего одна в клубе, и даже статистику мы не берем... детский сад какой-то. Как минимум, игрок может одновременно быть членом нескольких команд - допустим, своего клуба и сборной страны или олимпийской сборной. Собственный Id в таблице участников игр не нужен - композитного Game + Person будет достаточно. Если я правильно понял, что позиция - это вратарь/форвард/полузащитник, то может ли этот атрибут меняться со временем, и если да, как вы собираетесь хранить его историю? А может, позиция меняется в зависимости от конкретного матча (в футболе, наверное, вряд ли, а за все остальные виды спорта не уверен) - тогда надо дублировать этот атрибут в GamePlayers. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 12:15
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
Include.nvПроектирую ДБ «Футбольные клубы». <...> В данной задаче это не важно. <...> Статистику не затрагиваем.Огласите весь список, пожалуйста. Что важно, что не важно. Сейчас при отсутствии конкретных требований вы можете на любые замечания и предложения отвечать "это не важно", и смысла предлагать вам что-то нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 13:23
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nv, По самой схеме -- у тебя в некоторых таблицах лишние суррогатные ключи. Например, в играх Id лишний не нужен, достаточно идов двух комманд и номера тура или даты игры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 13:39
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
MasterZivInclude.nv, По самой схеме -- у тебя в некоторых таблицах лишние суррогатные ключи. Например, в играх Id лишний не нужен, достаточно идов двух комманд и номера тура или даты игры. А можно огласить критерии "лишности" суррогатного ключа? У таблицы Games есть подчиненная таблица - этого, по-Вашему, недостаточно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 14:10
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
rockclimberInclude.nvПроектирую ДБ «Футбольные клубы». <...> В данной задаче это не важно. <...> Статистику не затрагиваем.Огласите весь список, пожалуйста. Что важно, что не важно. Сейчас при отсутствии конкретных требований вы можете на любые замечания и предложения отвечать "это не важно", и смысла предлагать вам что-то нет. Имелось в виду, что добавить или исправить для ДАННЫХ таблиц. lLocustЕще не понятно как хранится результат игры (поле варчар?) как запросы на победителя и счет строить? (тут можно было бы для оппонентов игр сделать отдельную табличку с game_id с записью на каждого оппонента, признаком что он победил, проиграл, ничья и сколько голов забил) Здесь вы правы, не додумал. Но думаю стоит сделать просто поле типа enum('Win', 'Draw', 'Loss'). Тогда мы сможем легко находить нужные результаты. Правда тогда не понятно, если играют два клуба между собой, то надо ли для каждого добавлять данные в таблицу Games? Получится избыточность. lLocustИ что такое табличка Positions? не совсем понятен ее смысл.... Позиции игроков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 14:14
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
Include.nvНо думаю стоит сделать просто поле типа enum('Win', 'Draw', 'Loss'). Тогда мы сможем легко находить нужные результаты. Ну а так же хранить счет игры в другом поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 15:33
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nvlLocustЕще не понятно как хранится результат игры (поле варчар?) как запросы на победителя и счет строить? (тут можно было бы для оппонентов игр сделать отдельную табличку с game_id с записью на каждого оппонента, признаком что он победил, проиграл, ничья и сколько голов забил) Здесь вы правы, не додумал. Но думаю стоит сделать просто поле типа enum('Win', 'Draw', 'Loss'). Тогда мы сможем легко находить нужные результаты.Нужно сделать 2 поля, количество голов с каждой стороны. И (или) в таблице GamePlayers хорошо бы писать, сколько голов забил игрок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 16:17
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
alexeyvgИ (или) в таблице GamePlayers хорошо бы писать, сколько голов забил игрок. И в чьи ворота :)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 16:18
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nv lLocustИ что такое табличка Positions? не совсем понятен ее смысл.... Позиции игроков. Позиции игроков в кманде - могут меняться. Самое главное - позиции в мачте могут отличаться от позиций в команде, и их может быть несколько :). И самое-самое главное - зачем вообще нужны позиции :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 16:20
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Include.nvЗдесь вы правы, не додумал. Но думаю стоит сделать просто поле типа enum('Win', 'Draw', 'Loss'). Тогда мы сможем легко находить нужные результаты. Правда тогда не понятно, если играют два клуба между собой, то надо ли для каждого добавлять данные в таблицу Games? Получится избыточность. ('Winner - 1', 'Winner - 2', 'Draw') ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 16:30
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
alexeyvgInclude.nvпропущено... Здесь вы правы, не додумал. Но думаю стоит сделать просто поле типа enum('Win', 'Draw', 'Loss'). Тогда мы сможем легко находить нужные результаты.Нужно сделать 2 поля, количество голов с каждой стороны. И (или) в таблице GamePlayers хорошо бы писать, сколько голов забил игрок. Как я понимаю статистика по игрокам не важна ))) А с точки зрения проектирования такая реализация имеет место быть, но я бы так не делал! Т.к. в таблице игры хранится id одной команды и id второй команды, т.е. запросы на то где играла команда будут выглядеть так: Код: plsql 1. еще ничего (кроме того что index range scan летит нахрен и лучшее что можно добиться это index full scan), а если нужно знать когда она выиграла? Код: plsql 1. Уже геморройнее. А если нужно узнать соотношение забитых/пропущенных голов? (даже писать не хочется....) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 16:48
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
lLocust, Делается вьюшка с UNION, разворачивающая матчи относительно второй стороны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 17:15
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
АнатоЛойalexeyvgИ (или) в таблице GamePlayers хорошо бы писать, сколько голов забил игрок. И в чьи ворота :)...Кстати да, это важно :-) Я вообще хотел написать, что нужно в GamePlayers писать, за какую команду играл игрок. Но допустим, игроки не могут переходить из команды в команду. И даже в этом случае нужно писать, в какие ворота гол, потому что есть автоголы :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 18:01
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Встречное предложение. На схеме ключевые атрибуты, опущены почти все названия и прочие атрибуты, не влияющие на связывание таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 18:19
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Кот Матроскин, Приседания вокруг изначально неправильно спроектированной базы...... АнатоЛой, А вот так мне нравится, даже придираться не хочется ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 18:28
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Кот МатроскинMasterZivInclude.nv, По самой схеме -- у тебя в некоторых таблицах лишние суррогатные ключи. Например, в играх Id лишний не нужен, достаточно идов двух комманд и номера тура или даты игры. А можно огласить критерии "лишности" суррогатного ключа? У таблицы Games есть подчиненная таблица - этого, по-Вашему, недостаточно? Критерий простой -- можно и без него. Подчинённая таблица -- это не обязательное условие для того, чтобы применять доп. суррогатный ключ. я должен был оговориться, что, конечно, это не является грубой ошибкой, скорее, дело вкуса. Но "не умножай" должно тоже действовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 18:40
|
|||
|---|---|---|---|
|
|||
Физическая модель |
|||
|
#18+
MasterZivКот Матроскинпропущено... А можно огласить критерии "лишности" суррогатного ключа? У таблицы Games есть подчиненная таблица - этого, по-Вашему, недостаточно? Критерий простой -- можно и без него. По этому критерию он "лишний" в 99% таблиц - там ведь найдется естественный ключ, который в принципе можно сделать первичным. Выкиньте ID из Clubs - там ключом можно сделать название (или название + город, или названия + город + страна - в данном случае неважно) Суррогат делается не из логической необходимости (иначе он не суррогат, по определению), а для технического удобства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2014, 21:49
|
|||
|---|---|---|---|
Физическая модель |
|||
|
#18+
Кот МатроскинMasterZivпропущено... Критерий простой -- можно и без него. По этому критерию он "лишний" в 99% таблиц - там ведь найдется естественный ключ, который в принципе можно сделать первичным. Выкиньте ID из Clubs - там ключом можно сделать название (или название + город, или названия + город + страна - в данном случае неважно) Суррогат делается не из логической необходимости (иначе он не суррогат, по определению), а для технического удобства. При отрисовке "логических схем" (термин из PowerDesigner) поля внешних ключей отсутствуют - использовать суррогаты ни к чему. Но: 1) часто в команде встречаются аналитики/разработчики, которые "мыслят" только "физической схемой" - они привыкли видеть все поля реальной таблицы из БД :(; 2) при работе с физической схемой составные первичные ключи из нескольких полей только усложняют (увеличивают количество) полей (и отображаемой информации); 3) бывает, что в процессе разработки (дай Бог), а то уже и эксплуатации (sick!), естественный ключ оказывается не совсем первичным; при правильном подходе не самая большая проблема, но таки кропотливая работа по изменениям. Поэтому часто пользуюсь физической схемой, при этом использование суррогатного ключа с нормальным названием позволяет проще анализировать отдельно взятую таблицу с полями для внешних ключей... Да и как показала практика - особых хлопот в реализации суррогатные ключи не доставляют... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1540999]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
166ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 29ms |
| total: | 302ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
