powered by simpleCommunicator - 2.0.27     © 2024 Programmizd 02
Map
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / проектирование БД
58 сообщений из 58, показаны все 3 страниц
проектирование БД
    #40067738
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго времени суток!
Столкнулся с такой задачей: есть сущности Пользователи, Игроки, Команды. Игрок может быть заявлен в нескольких Командах, при этом и Игрок и Команда являются пользователем. Помогите спроектировать схему такой БД, я накидал, но не уверен, что верно.
...
Рейтинг: 0 / 0
проектирование БД
    #40067745
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
Помогите спроектировать схему такой БД, я накидал, но не уверен, что верно.
На первый взгляд всё правильно.
Попросите модератора перекинуть топик в Проектирование БД, тут это не совсем по теме.

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
проектирование БД
    #40067768
зачем _id в TeamPlayers ?
почему к Users стрелки в обе стороны?
...
Рейтинг: 0 / 0
проектирование БД
    #40067772
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нарисуй в нормальной нотации - ERD или UML. А то у тебя черти что и ничего не понятно. Может это просто такая нотация, что я вообще не знаю.
...
Рейтинг: 0 / 0
проектирование БД
    #40067777
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fkthat,

да это был быстрый набросок... Переделал, убрал id из сущности TeamPlayers
...
Рейтинг: 0 / 0
проектирование БД
    #40067780
ИВП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТС путает понятие Сущности и Отношения (таблицы).
Сам написал yozziесть сущности Пользователи, Игроки, Команды.
А кружочки (обязательность) и перпендикуляры (необязательность) на концах связей вроде используются в ER-диаграммах при задании связей между сущностями .
Если это ER-диаграмма, то никакой сущности TeamPlayers быть не может - должна быть связь "Многие ко Многим" между сущностями Игроки и Команды (таблица появится позже).
Если это схема данных (прямоугольники - таблицы (отношения)), то зачем обязательность и необязательность на концах связей?

бабушкин зайчикзачем _id в TeamPlayers ?
А кому от него хуже? В соседнем топике много про это писали.

Ну и название топика очень оригинальное.
...
Рейтинг: 0 / 0
проектирование БД
    #40067783
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ИВП,

Кхм.. я думал, что сущность и есть таблица... выходит, что это схема данных, хотя опять же, я думал, что ER диаграмма и должна отображать модель данных :)
...
Рейтинг: 0 / 0
проектирование БД
    #40067784
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozziя думал, что сущность и есть таблица...

"Сущность" - понятие логической модели.
"Таблица" - понятие физической модели.
Они не всегда соотносятся как 1:1 поэтому теоретики их разделяют.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
проектирование БД
    #40067788
сущности в приложении
таблицы в БД
ИВП
А кому от него хуже? В соседнем топике много про это писали.

это ~5 лишних байт на каждую строку
...
Рейтинг: 0 / 0
проектирование БД
    #40067806
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
Столкнулся с такой задачей:

Начало правильное, но постановки самой задачи нет...
yozzi
есть сущности Пользователи, Игроки, Команды. Игрок может быть заявлен в нескольких Командах, при этом и Игрок и Команда являются пользователем.

Это не постановка задачи - это ваше личное видение решения проблемы, которое вы предлагаете обсудить без самой постановки задачи.
Вопрос:
yozzi
при этом и Игрок и Команда являются пользователем

Пользователем чего ?

Я лично вообще ничего не понял... вы можете по русски сказать, например хочу сделать учет коней и жокеев на скачках... нужно считать забеги, места и т.д.
...
Рейтинг: 0 / 0
проектирование БД
    #40067809
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
да это был быстрый набросок... Переделал, убрал id из сущности TeamPlayers

Идея в целом верна, но с cardinality беда везде. У тебя для одного UserType может быть 0-∞ Users. Для Player и Team всегда есть один User (тут все верно), но для одного User может быть только 0-1 Player или 0-1 Team. Остальное все, вроде бы, ОК.
...
Рейтинг: 0 / 0
проектирование БД
    #40067810
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
при этом и Игрок и Команда являются пользователем


А это из серии:
Смешались в кучу кони, люди... (из Бородино)
Пользователи БД - это люди (грубо говоря) допущенные к информации БД и это не обязательно игроки (это могут быть администраторы, менеджеры, операционисты, которые имеют разные права и обязанности по ведению и сопровождению БД)... ну и естественно сами игроки по решению администратора могут быть допущены к информации как пользователи (с правами только просмотр - иначе это будет полный бардак)...
Ну, чтобы было понятнее - если в кадровой учетной системе предприятия зарегистрирована уборщица, то это не означает, что ей нужно автоматически выдать логин и пароль для доступа к самой учетной системе...
...
Рейтинг: 0 / 0
проектирование БД
    #40067856
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
Это не постановка задачи - это ваше личное видение решения проблемы, которое вы предлагаете обсудить без самой постановки задачи.
vmag
Пользователи БД - это люди (грубо говоря) допущенные к информации БД и это не обязательно игроки (это могут быть администраторы, менеджеры, операционисты, которые имеют разные права и обязанности по ведению и сопровождению БД)... ну и естественно сами игроки по решению администратора могут быть допущены к информации как пользователи

Ты не находишь, что ты сейчас и сам предлагаешь свое
vmag
личное видение решения проблемы
просто выдуманное из головы :)
...
Рейтинг: 0 / 0
проектирование БД
    #40067986
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat,

Не нахожу, то что 2+2=4 придумал не я, если кто то не видит 2+2 это его проблема
...
Рейтинг: 0 / 0
проектирование БД
    #40067988
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat,

А что касается тупого решения в лоб по псевдопостановке задачи, то достаточно трёх таблиц со второй картинки справа: игроки + команды + связующая, нужно только в игроки добавить поля логин и пароль...
Таким образом любой игрок автоматически становится пользователем, а так как любая команда состоит из множества игроков - пользователей, то и команда по факту пользователь. Это азы абстрактной алгебры.... И да симметрия в этом случае не работает. Наличие логина и пароля на команду не обеспечивает отдельных игроков привилегиями пользователя если они не входят ни в одну команду
...
Рейтинг: 0 / 0
проектирование БД
    #40067993
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
А что касается тупого решения в лоб по псевдопостановке задачи, то достаточно трёх таблиц со второй картинки справа: игроки + команды + связующая, нужно только в игроки добавить поля логин и пароль... Таким образом любой игрок автоматически становится пользователем, а так как любая команда состоит из множества игроков - пользователей, то и команда по факту пользователь. Это азы абстрактной алгебры.... И да симметрия в этом случае не работает. Наличие логина и пароля на команду не обеспечивает отдельных игроков привилегиями пользователя если они не входят ни в одну команду

Я не понял вообще ничего (видать, для меня твоя абстракная алгебра слишком абстракная), но ОК, будь по твоему.
...
Рейтинг: 0 / 0
проектирование БД
    #40067997
vmag
а так как любая команда состоит из множества игроков - пользователей, то и команда по факту пользователь

крутая логика...
но нет, спасибо
пусть лучше мыши отдельно, а зёрна отдельно
...
Рейтинг: 0 / 0
проектирование БД
    #40068060
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
бабушкин зайчик
пусть лучше мыши отдельно, а зёрна отдельно


ага, а если команда поедет на поезде, то нужно выдать логин и пароль еще и поезду...
...
Рейтинг: 0 / 0
проектирование БД
    #40068074
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
ага, а если команда поедет на поезде, то нужно выдать логин и пароль еще и поезду...

Поезда уже давно поддерживают вход по логину и паролю.
...
Рейтинг: 0 / 0
проектирование БД
    #40068136
vmag, откуда вообще у команды взялся логин и пароль?
команда - это набор юзеров (включая владельца) и вот у них есть л/п, а команде то он зачем
...
Рейтинг: 0 / 0
проектирование БД
    #40068176
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
бабушкин зайчик,

Давайте попробую объяснить, почему я так решил сделать, ну и вобщем задачу. Я разрабатываю информационную систему для команд и игроков, и хотел бы, чтобы можно было регистрировать и новые команды и новых игроков, ну и соответственно входить под ними в систему, у команды свой логин для входа, у игрока - свой. Можно конечно добавить на форме входа выпадающий список «войти как...» и в зависимости от этого решать кто это, игрок или команда, но мне это решение не нравится.

Возможно, я намешал сильно... может тогда подскажите, как можно продумать? Может, конечно, стоит использовать такую роль как «администратор команды» у пользователя, но если этот администратор тоже будет игроком? В таком случае нужно, чтобы у пользователя были роли и «игрок» и «администратор команды», так будет правильнее?
...
Рейтинг: 0 / 0
проектирование БД
    #40068190
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
бабушкин зайчик
команда - это набор юзеров (включая владельца) и вот у них есть л/п, а команде то он зачем


алилуя... не прошло и недели как дошло... раз 5-10 перечитал топик ?
...
Рейтинг: 0 / 0
проектирование БД
    #40068193
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
Может, конечно, стоит использовать такую роль как «администратор команды»

Ничего в этом сложного. Всего лишь добавить в отношение "TeamPlayers" атрибут "роль". Логин для команды и вправду как-то криво - это будет как та бригада Стаханова, которая вся спускалась в шахту под его логином

И еще. Правильней отделить логин/пароль в отдельное отношение "Credentials" и для него тоже сразу предусмотреть субклассирование. Вход потенциально может быть не только по логину и паролю, да и вообще credentials это сама по себе отдельная сущность.
...
Рейтинг: 0 / 0
проектирование БД
    #40068199
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
Возможно, я намешал сильно... может тогда подскажите, как можно продумать? Может, конечно, стоит использовать такую роль как «администратор команды» у пользователя, но если этот администратор тоже будет игроком? В таком случае нужно, чтобы у пользователя были роли и «игрок» и «администратор команды», так будет правильнее?


по уму админы БД независимы и продвинуты (и лучше когда их 1-2, тогда можно понять с кого спросить за косяки) и если даже дать всем капитанам команд права админов, большая вероятность, что половина из них скажет мне это и нафик не уперлось... читать инструкции, что-то заводить, корректировать, я даже не знаю с какой стороны подойти к компу, которого у меня кстати и нет, кому нужно - пусть и ковыряет эту БД, ну а просто зайти и посмотреть раз в месяц что и как я наверно смогу ...
...
Рейтинг: 0 / 0
проектирование БД
    #40068217
yozzi
бабушкин зайчик,

Давайте попробую объяснить, почему я так решил сделать, ну и вобщем задачу. Я разрабатываю информационную систему для команд и игроков, и хотел бы, чтобы можно было регистрировать и новые команды и новых игроков, ну и соответственно входить под ними в систему, у команды свой логин для входа, у игрока - свой. Можно конечно добавить на форме входа выпадающий список «войти как...» и в зависимости от этого решать кто это, игрок или команда, но мне это решение не нравится.

Возможно, я намешал сильно... может тогда подскажите, как можно продумать? Может, конечно, стоит использовать такую роль как «администратор команды» у пользователя, но если этот администратор тоже будет игроком? В таком случае нужно, чтобы у пользователя были роли и «игрок» и «администратор команды», так будет правильнее?

нет у команд никаких логинов/паролей, есть владелец команды и он юзер
также как и все члены команды (он также может быть членом и играть в ней)
а роли - это система авторизации , там роли юзеров и группы правил, вот через неё все доступы и реализуются
...
Рейтинг: 0 / 0
проектирование БД
    #40068218
vmag
бабушкин зайчик
команда - это набор юзеров (включая владельца) и вот у них есть л/п, а команде то он зачем


алилуя... не прошло и недели как дошло... раз 5-10 перечитал топик ?

а что дошло то? очевидно было всегда
...
Рейтинг: 0 / 0
проектирование БД
    #40068300
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fkthat,

я верно все понял? роль правильно будет в этой же таблице PlayerTeams хранить? А token также в Credentials может быть или для него отдельную таблицу лучше, типа Sessions?
...
Рейтинг: 0 / 0
проектирование БД
    #40068301
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag,

а причем админы бд? под админами команды я подразумевал персонал команды, у которых только возможность подтверждать игрока в команду, ну и еще какие либо подобные действия
...
Рейтинг: 0 / 0
проектирование БД
    #40068304
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yozzi
fkthat,

я верно все понял? роль правильно будет в этой же таблице PlayerTeams хранить? А token также в Credentials может быть или для него отдельную таблицу лучше, типа Sessions?
...
Рейтинг: 0 / 0
проектирование БД
    #40068312
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
а причем админы бд? под админами команды я подразумевал персонал команды, у которых только возможность подтверждать игрока в команду, ну и еще какие либо подобные действия


Хорошо...
- база пустая, кто первоначально внесет капитанов-админов (и будет это делать потом) при наличии интерфейса с правами доступа ?
- кто будет вносить игроков: фио, год рождения, и прочую лабуду... если половина из них откажется это делать?
- кто будет подтверждать игроков в команду и подобные действия, если капитан скажет идите вы все в .ОПУ, у меня тренировки с 6 утра до ночи...

Хотя споры тут похоже бесполезны, делайте, практика покажет...
и я бы вернул _id в TeamPlayers как было у вас изначально:
Это не тот случай чтоб экономить 5 байт на строку, похоже вы частенько будете ковырять эту таблицу,
по этому стоя на суррогатном ключе будет проще идентифицировать запись перед DELETE и UPDATE
...
Рейтинг: 0 / 0
проектирование БД
    #40068324
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag
- база пустая, кто первоначально внесет капитанов-админов (и будет это делать потом) при наличии интерфейса с правами доступа ?


Я предполагал, что пользователи сами будут регистрироваться. Зарегистрировался как "администратор команды" - зарегистрировал свою команду, назначил капитана и т.д. Зарегистрировался как "игрок" - добавляешься в команду.

vmag
- кто будет вносить игроков: фио, год рождения, и прочую лабуду... если половина из них откажется это делать?


Ну отказался регистрироваться - значит ты не в системе) Либо регистрирует "администратор команды", он же менеджер

vmag
- кто будет подтверждать игроков в команду и подобные действия, если капитан скажет идите вы все в .ОПУ, у меня тренировки с 6 утра до ночи...


Подтверждать будет юзер с правами "администратор команды", обычный менеджер, как писал выше, у которого это часть его обязанностей заниматься подобными делами

vmag
и я бы вернул _id в TeamPlayers как было у вас изначально:
Это не тот случай чтоб экономить 5 байт на строку, похоже вы частенько будете ковырять эту таблицу,
по этому стоя на суррогатном ключе будет проще идентифицировать запись перед DELETE и UPDATE


Понял, верну тогда
...
Рейтинг: 0 / 0
проектирование БД
    #40068328
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yozzi
yozzi
fkthat,

я верно все понял? роль правильно будет в этой же таблице PlayerTeams хранить? А token также в Credentials может быть или для него отдельную таблицу лучше, типа Sessions?


Да, точно, vmag натолкнул на мысль, должен быть наверно, и какой то общий пользователь - админ системы, и который к командам вообще отношения не имеет, соответственно, он ведь не будет в таблице TeamUsers, как тогда быть? Или не должен...)
...
Рейтинг: 0 / 0
проектирование БД
    #40068330
vmag
по этому стоя на суррогатном ключе будет проще идентифицировать запись перед DELETE и UPDATE

там идентификация по uid + team_id, она не подводит
...
Рейтинг: 0 / 0
проектирование БД
    #40068355
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozzi
Да, точно, vmag натолкнул на мысль, должен быть наверно, и какой то общий пользователь - админ системы, и который к командам вообще отношения не имеет, соответственно, он ведь не будет в таблице TeamUsers, как тогда быть? Или не должен...)


Вы просто стоите на пороге всего этого, так сказать - открыли дверь...
С опытом вы поймете некоторые моменты:
- все хотят чтобы в БД было как можно больше информации, но никто не хочет её туда вбивать, это можно сделать только выкрутив кому-то руки в прямом и переносном смысле этого слова и это может сделать только Заказчик (если он есть) иначе придется самому закатывать рукава и доказывать нужность и гениальность...
- если кроме вас эта бд никому не нужна (никто не лоббирует, не финансирует и нет перспектив на это), то относитесь к процессу по проще, - как к учебному для самого себя, ну или настраивайтесь, что вы сами будете платить за хостинг (как минимум), если захотите покинуть пределы localhost и найти спонсоров...
...
Рейтинг: 0 / 0
проектирование БД
    #40068368
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag
yozzi
Да, точно, vmag натолкнул на мысль, должен быть наверно, и какой то общий пользователь - админ системы, и который к командам вообще отношения не имеет, соответственно, он ведь не будет в таблице TeamUsers, как тогда быть? Или не должен...)


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


Да это и так "для личного развития", так сказать, но просто хочется, чтобы было все по уму, ну или приближенно к этому)
...
Рейтинг: 0 / 0
проектирование БД
    #40075139
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день! Расширил схему бд, подскажите, верно ли я сделал?

В Requests планирую хранить заявки игроков на добавление в команду (не уверен, что связь должна быть с Team_players) и заявки команд на участие в турнирах. Еще хочу добавить Trainings, при этом игроки должны подтверждаться на тренировки, но не могу пока придумать, как сделать... т.е тренер команды создает тренировку в заданное время, а игрок должен подтвердить свое участие в этой тренировке, аналогично с матчем
...
Рейтинг: 0 / 0
проектирование БД
    #40075167
email и phones - это отдельные таблицы
location - это не город, а полный address (тоже отд. таблица)
...
Рейтинг: 0 / 0
проектирование БД
    #40075205
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
бабушкин зайчик
email и phones - это отдельные таблицы
location - это не город, а полный address (тоже отд. таблица)


я пока не думал полные адреса вводить, думал ограничиться городом, без улиц и т.д

бабушкин зайчик
email и phones - это отдельные таблицы


эм... а для чего?)
...
Рейтинг: 0 / 0
проектирование БД
    #40075234
yozzi
эм... а для чего?)

потому что они не только у юзеров бывают
потому что их бывает несколько
потому что искать проще
...
Рейтинг: 0 / 0
проектирование БД
    #40075235
yozzi
я пока не думал полные адреса вводить, думал ограничиться городом, без улиц и т.д

когда передумаете, придётся переделывать
...
Рейтинг: 0 / 0
проектирование БД
    #40075237
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
бабушкин зайчик
yozzi
эм... а для чего?)

потому что они не только у юзеров бывают
потому что их бывает несколько
потому что искать проще


понял, спасибо)

а можете подсказать насчет: В Requests планирую хранить заявки игроков на добавление в команду (не уверен, что связь должна быть с Team_players) и заявки команд на участие в турнирах. Еще хочу добавить Trainings, при этом игроки должны подтверждаться на тренировки, но не могу пока придумать, как сделать... т.е тренер команды создает тренировку в заданное время, а игрок должен подтвердить свое участие в этой тренировке, аналогично с матчем
...
Рейтинг: 0 / 0
проектирование БД
    #40075340
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yozzi
Давайте попробую объяснить, почему я так решил сделать, ну и вобщем задачу. Я разрабатываю информационную систему для команд и игроков , и хотел бы, чтобы можно было регистрировать и новые команды и новых игроков, ну и соответственно входить под ними в систему, у команды свой логин для входа, у игрока - свой. Можно конечно добавить на форме входа выпадающий список «войти как...» и в зависимости от этого решать кто это, игрок или команда, но мне это решение не нравится.

Жирным выделена первая и основная проблема. Игроки во что?
И уже исходя из ответа нужно строить БД. Потому как наличие у одного игрока нескольких логинов в некоторых компьютерных играх будет считаться за твинководство.
Далее идёт проблема безопасности, так как в системе присутствуют пользователи и логины с паролями. Что будет делать система, не БД, а именно система, если один пользователь зашёл сразу под несколькими своими логинами? Что будет делать система, если пользователь на турнире играет сразу за несколько команд под разными логинами?

По последней схеме - абсолютно лишние все таблицы *_roles и поля в таблице "Team_players", вся эта связка заменяется одним полем "team_role" в которой, условно: 1 - это админ, 2 - просто игрок. Либо поле "team_role" связывается с таблицей в которой идёт перечень всех ролей, если планируется этот список расширять.
Так же излишне разделение одного человека на Users и Players, всё это можно реализовать через одно поле описанное выше.

Напоследок несколько наводящих вопросов: Зачем хранить location_id в Users и Teams ?
...
Рейтинг: 0 / 0
проектирование БД
    #40075359
yozzi
а можете подсказать насчет: В Requests планирую хранить заявки игроков на добавление в команду (не уверен, что связь должна быть с Team_players) и заявки команд на участие в турнирах. Еще хочу добавить Trainings, при этом игроки должны подтверждаться на тренировки, но не могу пока придумать, как сделать... т.е тренер команды создает тренировку в заданное время, а игрок должен подтвердить свое участие в этой тренировке, аналогично с матчем

Код: sql
1.
2.
3.
ev_t -- event type -- в команду, на турнир, на тренировку
eid -- entity id -- id: команды, турнира, тренировки
uid -- юзер ID
...
Рейтинг: 0 / 0
проектирование БД
    #40075374
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Stanislav P
Игроки во что?

в футбол, любительские команды

Stanislav P
Что будет делать система, не БД, а именно система, если один пользователь зашёл сразу под несколькими своими логинами?


Ну зайти он сможет, но у него ведь не будет привилегий каких либо, только права на просмотр будут

Stanislav P
Что будет делать система, если пользователь на турнире играет сразу за несколько команд под разными логинами?


В несколько команд можно заявиться будет и под одним логином, это не запрещается

Stanislav P
По последней схеме - абсолютно лишние все таблицы *_roles и поля в таблице "Team_players", вся эта связка заменяется одним полем "team_role" в которой, условно: 1 - это админ, 2 - просто игрок. Либо поле "team_role" связывается с таблицей в которой идёт перечень всех ролей, если планируется этот список расширять.


Думал разделить, Administrative_roles - это что то типа владелец, администратор/менеджер, тренер, обычный игрок (причем здесь это все можно совмещать, т.е владелец может быть и тренером и при этом играть сам); Playing_roles - это позиция на поле, вратарь, защитник, нападающий; Team_roles - это капитан, помощник капитана и опять же обычный игрок

Stanislav P
Зачем хранить location_id в Users и Teams?


Чтобы пользователь мог видеть команды из своего города, а команды, соответственно, игроков из своего города.

Идея такая: есть игроки-любители, команды, турниры. Одни и те же игроки могут быть в нескольких командах, команды могут быть в множестве турниров. Игроки заявляются в команды, администраторы команда или же владельцы, рассматривают эти заявки и принимают игроков. Тренера/администраторы назначают расписание тренировок/матчей, игроки же должны подтвердить свое участие в тренировке/матче в этот день. Тренера также могут добавлять план тренировок, упражнения и т.д. Администраторы команд также могут заявлять свои команды на участие в турнире, организатор турнира должен подтвердить команду, ну и команды между собой должны товарищеские матчи организовывать, вызовы какие либо делать друг другу
...
Рейтинг: 0 / 0
проектирование БД
    #40075524
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yozzi
Идея такая: есть игроки-любители, команды, турниры. Одни и те же игроки могут быть в нескольких командах, команды могут быть в множестве турниров. Игроки заявляются в команды, администраторы команда или же владельцы, рассматривают эти заявки и принимают игроков. Тренера/администраторы назначают расписание тренировок/матчей, игроки же должны подтвердить свое участие в тренировке/матче в этот день. Тренера также могут добавлять план тренировок, упражнения и т.д. Администраторы команд также могут заявлять свои команды на участие в турнире, организатор турнира должен подтвердить команду, ну и команды между собой должны товарищеские матчи организовывать, вызовы какие либо делать друг другу


В таком случае всю схему в топку. И начать проектирование надо с составления списка того, что, зачем и как нужно юзеру системы. Будет список, тогда уже можно будет и схему БД рисовать.
...
Рейтинг: 0 / 0
проектирование БД
    #40075532
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Stanislav P
В таком случае всю схему в топку. И начать проектирование надо с составления списка того, что, зачем и как нужно юзеру системы. Будет список, тогда уже можно будет и схему БД рисовать.


Ну, допустим...

Всем зарегистрированным юзерам нужно:

- иметь возможность редактировать личную информацию
- иметь возможность создавать команды
- иметь возможность создавать турниры
- иметь возможность поиска команды/турнира
- иметь возможность заявиться в одну или несколько команд
- иметь возможность подтвердить участие в игре
- иметь возможность подтвердить участие в тренировке
- иметь возможность получать уведомления от команд

Юзеру с ролью админа команды:

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

Юзеру с ролью тренера конкретной команды:

- иметь возможность приглашать других юзеров в команду
- иметь возможность утверждать расписание тренировок
- иметь возможность утверждать состав на игру, расстановку, устанавливать задачи игрокам для этой команды
- иметь возможность назначать капитана команды и его помощников для этой команды
- иметь возможность распределять игровые номера
- иметь возможность утверждать состав на тренировку, утверждать план тренировки для этой команды
- иметь возможность рассылать уведомления игрокам/тренерам из этой команды

Юзеру с ролью организатора турнира:

- иметь возможность редактировать описание турнира, лого и т.д
- иметь возможность приглашать команды на турнир
- иметь возможность рассылать уведомления администраторам/тренерам команд участников турнира
- иметь возможность получать уведомления от команд о принятии участия
- иметь возможность удалить созданный турнир



Пока что как то вот так.
...
Рейтинг: 0 / 0
проектирование БД
    #40075578
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Отлично!

Сколько сущностей есть в твоём описании?
Я вижу такие: Пользователь , Команда , Турнир .
Остальное здесь
Соответственно у нас уже есть три таблицы : Пользователи , Команды и Турниры .

У каждой сущности есть набор атрибутов.
У Пользователя есть минимально:
1. ID
2. ФИО
3. Логин
4. Пароль
Все эти атрибуты вполне ложатся в одну таблицу.

У Команды есть:
1. ID
2. Название
3. Логотип
4. Создатель команды
5. Состав команды из пользователей

У Турнира есть:
1. ID
2. Название
3. Место проведения
4. Дата начала турнира
5. Дата окончания турнира
6. Пользователь, создатель турнира
7. Список участвующих команд

У Команды и Турнира есть атрибут "состав", который рамками СУБД решается как отдельная таблица связанная с основной:

Атрибут Состав Команды является отдельной таблицей СоставКоманды содержащей:
1. ID
2. ID_Команды
3. ID_Пользователя
4. Роль_Пользователя (есть несколько вариантов реализации того, что один пользователь может иметь несколько ролей в команде)

Атрибут Участники Турнира так же является отдельной таблицей УчастникиТурнира :
1. ID
2. ID_КомандыУчастницыТурнира


То есть, у нас есть пять основных таблиц: Пользователи, Команды, СоставКоманды, Турнир и УчастникиТурнира.
...
Рейтинг: 0 / 0
проектирование БД
    #40075609
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Stanislav P
Отлично!

Сколько сущностей есть в твоём описании?
Я вижу такие: Пользователь , Команда , Турнир .
Остальное здесь
Соответственно у нас уже есть три таблицы : Пользователи , Команды и Турниры .

У каждой сущности есть набор атрибутов.
У Пользователя есть минимально:
1. ID
2. ФИО
3. Логин
4. Пароль
Все эти атрибуты вполне ложатся в одну таблицу.

У Команды есть:
1. ID
2. Название
3. Логотип
4. Создатель команды
5. Состав команды из пользователей

У Турнира есть:
1. ID
2. Название
3. Место проведения
4. Дата начала турнира
5. Дата окончания турнира
6. Пользователь, создатель турнира
7. Список участвующих команд

У Команды и Турнира есть атрибут "состав", который рамками СУБД решается как отдельная таблица связанная с основной:

Атрибут Состав Команды является отдельной таблицей СоставКоманды содержащей:
1. ID
2. ID_Команды
3. ID_Пользователя
4. Роль_Пользователя (есть несколько вариантов реализации того, что один пользователь может иметь несколько ролей в команде)

Атрибут Участники Турнира так же является отдельной таблицей УчастникиТурнира :
1. ID
2. ID_КомандыУчастницыТурнира


То есть, у нас есть пять основных таблиц: Пользователи, Команды, СоставКоманды, Турнир и УчастникиТурнира.


Да, получается так... вроде пока так и было, только еще дополнено было в схеме...
Для стадионов, стран, городов, ролей таблицы нужны?
...
Рейтинг: 0 / 0
проектирование БД
    #40075612
yozzi
Stanislav P
В таком случае всю схему в топку. И начать проектирование надо с составления списка того, что, зачем и как нужно юзеру системы. Будет список, тогда уже можно будет и схему БД рисовать.


Ну, допустим...

Всем зарегистрированным юзерам нужно:

- иметь возможность редактировать личную информацию
- иметь возможность создавать команды
- иметь возможность создавать турниры
- иметь возможность поиска команды/турнира
- иметь возможность заявиться в одну или несколько команд
- иметь возможность подтвердить участие в игре
- иметь возможность подтвердить участие в тренировке
- иметь возможность получать уведомления от команд

Юзеру с ролью админа команды:

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

Юзеру с ролью тренера конкретной команды:

- иметь возможность приглашать других юзеров в команду
- иметь возможность утверждать расписание тренировок
- иметь возможность утверждать состав на игру, расстановку, устанавливать задачи игрокам для этой команды
- иметь возможность назначать капитана команды и его помощников для этой команды
- иметь возможность распределять игровые номера
- иметь возможность утверждать состав на тренировку, утверждать план тренировки для этой команды
- иметь возможность рассылать уведомления игрокам/тренерам из этой команды

Юзеру с ролью организатора турнира:

- иметь возможность редактировать описание турнира, лого и т.д
- иметь возможность приглашать команды на турнир
- иметь возможность рассылать уведомления администраторам/тренерам команд участников турнира
- иметь возможность получать уведомления от команд о принятии участия
- иметь возможность удалить созданный турнир



Пока что как то вот так.

это всё правила авторизации, которые складываются в группы и присваиваются ролям, которые раздаются юзерам
...
Рейтинг: 0 / 0
проектирование БД
    #40075626
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
бабушкин зайчик
yozzi
пропущено...


Ну, допустим...

Всем зарегистрированным юзерам нужно:

- иметь возможность редактировать личную информацию
- иметь возможность создавать команды
- иметь возможность создавать турниры
- иметь возможность поиска команды/турнира
- иметь возможность заявиться в одну или несколько команд
- иметь возможность подтвердить участие в игре
- иметь возможность подтвердить участие в тренировке
- иметь возможность получать уведомления от команд

Юзеру с ролью админа команды:

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

Юзеру с ролью тренера конкретной команды:

- иметь возможность приглашать других юзеров в команду
- иметь возможность утверждать расписание тренировок
- иметь возможность утверждать состав на игру, расстановку, устанавливать задачи игрокам для этой команды
- иметь возможность назначать капитана команды и его помощников для этой команды
- иметь возможность распределять игровые номера
- иметь возможность утверждать состав на тренировку, утверждать план тренировки для этой команды
- иметь возможность рассылать уведомления игрокам/тренерам из этой команды

Юзеру с ролью организатора турнира:

- иметь возможность редактировать описание турнира, лого и т.д
- иметь возможность приглашать команды на турнир
- иметь возможность рассылать уведомления администраторам/тренерам команд участников турнира
- иметь возможность получать уведомления от команд о принятии участия
- иметь возможность удалить созданный турнир



Пока что как то вот так.

это всё правила авторизации, которые складываются в группы и присваиваются ролям, которые раздаются юзерам


ну я не могу не согласиться с Вами)
но ведь данные где то хранить нужно при этом
...
Рейтинг: 0 / 0
проектирование БД
    #40075629
yozzi
ну я не могу не согласиться с Вами)
но ведь данные где то хранить нужно при этом

в таблицах авторизации
...
Рейтинг: 0 / 0
проектирование БД
    #40075631
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
бабушкин зайчик
yozzi
ну я не могу не согласиться с Вами)
но ведь данные где то хранить нужно при этом

в таблицах авторизации


users и roles? а остальные данные тогда где?
...
Рейтинг: 0 / 0
проектирование БД
    #40075634
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozziДля стадионов, стран, городов, ролей таблицы нужны?

Ничего из этого не упоминается в списке задач, так что нет, не нужны.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
проектирование БД
    #40075646
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov

yozziДля стадионов, стран, городов, ролей таблицы нужны?

Ничего из этого не упоминается в списке задач, так что нет, не нужны.


Ну хорошо, но ведь у турнира есть место проведения - стадион, аналогично и у команд есть место, где они тренируются - стадион, игроки, турниры и команды находятся в каком то городе, помимо этого ведь дополнительные таблицы должны быть. В списке было про уведомления и запросы на добавления, тоже таблицы ведь
...
Рейтинг: 0 / 0
проектирование БД
    #40075651
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
yozziНу хорошо, но ведь у турнира есть место проведения - стадион, аналогично и у команд есть
место, где они тренируются - стадион, игроки, турниры и команды находятся в каком то
городе, помимо этого ведь дополнительные таблицы должны быть.

Когда реализация твоего проекта дойдёт до них - тогда и будешь решать что с ними делать.
"Планирование наперёд" - пустая потеря времени.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
проектирование БД
    #40075928
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yozzi,

Таблица для городов не нужна. Можешь сделать только список стран, а полный адрес оставить одним полем.
с ролями можно поступить двумя путями - одно поле с маской, то есть, число 1 - это только роль игпока, 10 - только владелец. 11 - игрок и владелец, и так далее.
Стадионы не факт что нужны, если есть полный адрес. Но если хочется, то можно и стадионы сделать, но схему надо переделать под новый вариант.
...
Рейтинг: 0 / 0
проектирование БД
    #40076188
yozzi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Stanislav P,

Ок, спасибо
...
Рейтинг: 0 / 0
проектирование БД
    #40076210
yozzi
бабушкин зайчик
пропущено...

в таблицах авторизации


users и roles? а остальные данные тогда где?

rules, groups, roles, users
...
Рейтинг: 0 / 0
58 сообщений из 58, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / проектирование БД
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]