Задать вопрос

hrnsywtfczlh

Лайки

  • Зачем именно нужны связи в бд?

    rozhnev
    @rozhnev Куратор тега MySQL
    Fullstack programmer, DBA, медленно, дорого
    В Вашей базе уже есть связь мезду таблицами Message и User. Поля Message.userid => User. id связывают таблицу Message с User
    К Вашей схеме Вы можете только добавить внешний ключ который не позволит вставлять сообщения от несущуствующего пользователя
    CREATE TABLE User (
    id INTEGER NOT NULL AUTO_INCREMENT,
    login VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL,
    status INTEGER NOT NULL,
    PRIMARY KEY (id)
);

CREATE TABLE Message (
    id INTEGER NOT NULL AUTO_INCREMENT,
    userid INTEGER NOT NULL,
    message VARCHAR(255) NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (userid) REFERENCES User(id)
);


    https://sqlize.online/sql/mysql57/35f0f9087119cc77...
    Ответ написан
    8 комментариев
    8 комментариев

  • Зачем именно нужны связи в бд?

    @deliro
    Когда к тебе придёт менеджер и скажет: "эй, hrnsywtfczlh, а почему у нас тут вот заказов отгруженных на 15 миллионов, а получателей даже не в базе?", тогда-то ты и поймёшь, зачем нужны связи в БД. Но сперва поседеешь.
    Ответ написан
    7 комментариев
    7 комментариев

  • Зачем именно нужны связи в бд?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Нужно поговорить об аномалиях. Например в твоей системе я могу (теоретически) добавить месседж
    который не принадлежит ни одному пользователю системы. Я просто сделаю

    insert into message(9999999, -1, "Mua-haha...");

    И у меня есть пост от анонимоса который не зарегистрирован как пользователь.

    Разумеется можно полагаться на логику твоего приложения и думать что такая ситуация невозможна
    но с точки зрения БД она вполне возможна потому как родственная связь User + Message нигде не объявлена.
    И SQL позволяет это сделать.

    Чтоб поправить ситуацию надо эту связь добавить и тогда я не смогу создать фейковые посты от анонимосов.
    ALTER TABLE Message
ADD FOREIGN KEY (userid) REFERENCES users(id);

    По умолчанию констрейнт создается с опцией restict (это было в Оракле как в Майскл - не знаю)
    и это гарантирует что невозможно также удалять родительские записи пока есть дочки.
    Для скорости ссылочные ключи всегда - индексированы.

    Рассуждать на тему вреда от аномалий - это просто терять время. Каждый владелец БД сам решает
    какие уровни строгости ему вводить. Вообще любая теория касаемая БД - по сути просто развивает
    идею строгости НФ1,2,3,4,5,6 и ссылочных ограничений.

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

    По сути вопрос сводится к тому как не создавать мусор в БД.
    Ответ написан
    2 комментария
    2 комментария