#mysql #sql
Вопрос:
У меня есть база данных MySQL с user таблицей, после нового требования мне пришлось создать новую таблицу под названием social_media , и с этого момента каждый новый пользователь будет создаваться со social_media_id столбцом, содержащим ссылку на их социальные сети.
=================== ===================
| user | | social_media |
=================== ===================
|PK id | |PK id |
|FK social_media_id | | instagram |
| first_name | | facebook |
| last_name | | twitter |
| email | ===================
===================
Я хочу обновить мою базу данных так, что каждый пользователь, который не имел социальные медиа ссылки, прежде чем получит один (даже если данные имеют значение null), чтобы они могли обновить их, если они хотят, есть то, что я могу сделать, чтобы сделать новую social_media запись для каждого пользователя, что не один, и добавить правильный social_media_id внешний ключ для этого user ?
Комментарии:
1. ваша структура данных кажется обратной. В social_media должна быть колонка для идентификатора пользователя, а не наоборот. Реально, таблица social_media-это отношения «многие к одному» с пользователями. Более того, таблица social_media не должна содержать несколько столбцов для сущностей SM — тем более запись на сущность на пользователя. Это решение становится бесконечно проще, когда вы правильно нормализуете
2. @DougCoats Теперь, когда вы упомянули об этом, вы правы, имеет смысл иметь идентификатор в таблице social_media и столбец
name, представляющий тип социальных сетей, я хотел, чтобы все это было вuserтаблице, чтобы упростить обновление, однако, как бы вы создали новые записи для всех пользователей, у которых его еще нет?3. Может быть, вам стоит сделать это так:
User (PK id, first_name, last_name, email),social_media (pk id, social_media_name), и еще один столик дляuser_social_media (pk id, fk user_id, fk social_media_id).
Ответ №1:
Хорошо @Jorche, это слишком долго, чтобы быть комментарием, но я действительно хочу помочь.
Во-первых, это, вероятно, то, как должна выглядеть ваша структура данных:
Во-вторых, мне сейчас очень сложно рассказать вам, как вы вводите эти записи, потому что у меня абсолютно НУЛЕВЫЕ требования или любая другая бизнес-логика, которая помогла бы мне помочь вам определить наилучший подход к этому. Скорее всего, вам придется работать рука об руку с разработчиками приложений или разработчиками ETL (хотя это можете быть даже вы), чтобы понять, что это за подход. Может быть, это вызываемая хранимая процедура, может быть, это настроенный триггер, трудно сказать наверняка без дополнительного контекста, понимаете?
Все, что мы знаем на данный момент, — это то, что пользователи существуют, и иногда у них есть реляционные данные, связанные с объектами социальных сетей. Ваша задача буквально состоит в том, чтобы понять этот процесс и принять соответствующие решения о том, как регистрировать эти данные таким образом, чтобы это имело смысл как с точки зрения эксплуатации, так и с точки зрения проектирования базы данных.
Не хотелось бы говорить об этом, hombre, но все вопросы, которые у вас сейчас есть, полностью зависят от деталей, которые вы не предоставили.
Комментарии:
1. Возможно, было бы справедливо упомянуть, что соглашения об именах на моем снимке экрана — это мусор. Кроме того, я использовал реляционный дизайнер access, подайте на меня в суд — это быстро и легко для вопросов и ответов
2. Эй, @Дуг, я действительно ценю твой ответ. Я думаю о переходе на новую структуру данных, так как мы также хотим иметь очень специфические типы социальных сетей, кроме того, я собираюсь провести больше исследований в области хранимых процедур, которые, по моему мнению, могут быть способом создания записей, которые нам нужны