Структура базы данных за социальными сетями [руководство]

Question

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

Когда дело доходит до mysql, я бы создал новую базу данных для каждого пользователя, подписавшего или у меня есть одна огромная база данных и создающая таблицу для каждого пользователя, который зарегистрировался? Тогда будет ли каждый пользователь иметь имя пользователя, пароль, список друзей и столбцы столбцов в своих таблицах или базах данных?

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

Спасибо, и извините за неопределенности.

Answer 1

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

Для вашего приложения будет одна база данных. Эта база данных будет содержать таблицу с именем «user», с идентификаторами столбцов, «username», «password» (вам нужно посмотреть, как безопасно хранить пароли в базе данных, что выходит за рамки этого ответа. НЕ ПРОДАВАЙТЕ ПАРОЛЬ В ТЕЛЕФОНЕ ПЛАНА). Пароль включен, потому что приложение контролирует вход в систему. Вы не используете пользователей MySQL в качестве пользователей приложений. У MySQL будет, вероятно, два пользователя - один для вас и один для вашего приложения. Прошу прощения, если вы уже знаете это; вы выглядите настолько новым, что не можете, и если это так, стоит упомянуть, потому что это спасет вас от многих неприятностей.

Каждый пользователь приложения будет существовать как строка/запись в этой таблице. Столбец «id» - это так называемый «первичный ключ». Это означает, что это значение отличается для каждой записи в таблице и используется для уникальной идентификации каждого пользователя.

Затем вы хотите сделать так, чтобы пользователи могли создавать сообщения. Каждый пользователь может создавать несколько сообщений, но каждый пост может быть создан только одним пользователем, что делает это «отношения один ко многим». Как это обычно реализуется, создавая вторую таблицу «post». Post имеет столбцы 'id', 'author' и 'content'. Опять же, post.id является первичным ключом этой таблицы. post.author - это так называемый «внешний ключ». Это означает, что он ссылается на первичный ключ - в этом случае user.id. Подумайте об этом как о каком-то указателе. Если вы хотите найти имя пользователя, создавшего сообщение, вы должны посмотреть запись для сообщения в таблице «post» и найти значение этой записи для автора. Вы можете использовать этот номер, чтобы найти автора сообщения в таблице пользователя.

Для примера рассмотрим следующие таблицы:

user 
id username 
1 awesome_user 
2 more_awesome_user 
3 less_awesome_user 

post 
id author content 
1 1  I am awesome 
2 3  Yes you are, awesome_user 
3 2  I am more awesome 
4 1  No you're not 
5 2  Yes I am look at my name 
6 1  having more_ in front of your name doesn't make you more awesome 

В этом случае, вы можете сказать, что «я удивительным» пост был создан «awesome_user» пользователя, потому что post.author = user.id для этой должности и пользователя. Чтобы узнать, как на самом деле писать запросы, которые делают это, вы должны использовать google термин «объединение таблиц».

Далее, скажем, вам нужно, чтобы пользователи могли любить сообщения. Пользователю может нравиться много сообщений, и сообщение может понравиться многим пользователям, что делает это «многими ко многим». Как это обычно делается, это наличие новой таблицы, которая представляет это отношение. Позволяет вызвать таблицу user_likes_post. Эта таблица будет содержать следующие столбцы: user, post. Это оба внешних ключа к соответствующей таблице.

Теперь, для примера:

user_likes_post 
user post 
1 2 
3 5 

В этом случае, вы можете сказать, что пользователь «awesome_user» любит пост «Да ты, awesome_user» написаны «less_awesome_user», потому что вы можете посмотреть пользователя 1 в таблице пользователя, и вы можете посмотреть сообщение 2 в таблице сообщений. Опять же, при написании запросов вы можете присоединиться к таблицам, чтобы это произошло.

Обратите внимание, что user_likes_post не имеет столбца id. Это связано с тем, что в этом случае мы будем делать первичный ключ (user, post) вместо (id). Первичный ключ может состоять из нескольких столбцов. Это можно сделать только тогда, когда две строки не имеют одинаковых значений для этих двух столбцов. Другими словами, следующее разрешено:

user post 
1 2 
1 3 
2 2 

Но это не допускается

user post 
1 2 
1 2 

Это полезно для нас, потому что это мешает нам, потому что это будет препятствовать двойной симпатией. Это также можно сделать, указав столбец идентификатора как первичный ключ и имеющий «уникальное ограничение» на (пользователь, сообщение), но маловероятно, что нам когда-либо понадобится однозначно идентифицировать подобное, поэтому нет смысла в имея столбец id, так как это просто потеряет пространство. Стоит отметить, что внешние ключи также могут состоять из нескольких столбцов, поэтому можно ссылаться на подобные таблицы из другой таблицы. Однако, если вы планируете это делать, я рекомендую использовать столбец id.

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

Надеюсь, это поможет вам найти правильный путь для изучения дизайна баз данных. Дайте мне знать, если вы хотите прояснить это. Удачи!

• первичный ключ
• внешнего ключа
• ограничение
• ограничение уникальности
• один-к-одному
• один-ко-многим
• многие-ко-многим
• соединительные столы
• нормализация базы данных