Совет для моделирования базы данных MySQL

Мне нужен совет по созданию модели базы данных, содержащей данные для нескольких пользователей. Я постараюсь быть как можно более конкретным. Пожалуйста, извините меня, если это слишком широко или неуместно.Совет для моделирования базы данных MySQL

Я создаю веб-приложение, в котором пользователи могут регистрироваться и добавлять данные об их спортивных объектах. После регистрации пользователь должен иметь возможность добавлять участников в таблицу и добавлять достижения в другую таблицу.

Сейчас у меня всего 4 стола. members_table содержит всех участников спортивной игры. achievements_table содержит все достижения. member_has_achievement имеет отношение между членом и достижением и действует как уникальный идентификатор.

И, наконец, у меня есть login_table.

Эта таблица имеет несколько столбцов: loginid username password email

Моя первая мысль была создать таблицу соотношение между login_table и members_table. Так что один пользователь может иметь несколько членов, и эти участники могут иметь несколько достижений.

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

Любой совет, как я мог бы моделировать это по-другому?

источник

2014-09-19 Karsten Tietje

Какая разница между пользователем и участником программы? –

Также вам не нужно 'member_has_achievement', пока вы помещаете уникальный идентификатор в success_table (например, уникальный идентификатор достижения, а член имеет уникальный идентификатор, поэтому вы можете просто вставить этот уникальный идентификатор в success_table). –

@CharlotteDunois Мне кажется, что ему нужно member_has_achievement, похоже, что достижения_table хранит все доступные достижения, а member_has_achieve говорит, какие из них есть у члена. Так разумно иметь это (это отношения «многие-ко-многим»). –

Все кажется хорошим на данный момент. Представьте, что у вас несколько пользователей, которые хранятся в вашей таблице пользователей.
Теперь, если пользователь может добавить элемент, все, что вам нужно, это в members_table, добавьте user_id в качестве внешнего ключа:

----------------- 
| Members_table | 
----------------- 
| ID : PK  | 
| User_ID : FK | 
| Name   | 
| anything_else | 
----------------- 

----------------- 
| User   | 
----------------- 
| ID : PK  | 
| email   | 
| login   | 
| password  | 
-----------------

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

таблица пользователей здесь будет ваш login_table кстати :)

источник

2014-09-19 11:33:12

Да. Я просто думал, что это лучший способ. Но, как вы указали, это действительно может работать :) –