Всех приветствую, товарищи! Имею свой сервис бытовой техники, делаю сайт. Есть 3 таблицы: 1 - "marka" - столбцы "id", "marka", "comment" - список марок бытовой техники; 2 - "model" - столбцы "id", "model", "markaID", "comment" - большой список разных аппаратов; 3 - "remont" - столбцы "id", "modelID", "time", "SN", "clientID", "status", "comment" и др. - список аппаратов, которые на ремонте. Надо вывести таблицу, которая должна состоять из столбцов "Аппарат" (марка, модель), "Дата принятия", "Состояние ремонта", "Клиент". То есть мне нужно запрос Код (Text): SELECT id, time, clientID, modelID, status FROM remont ORDER BY time доработать так, чтобы вместо "modelID" я получил "model", связавшись по id и ещё раз получил "marka", связавшись по "markaID" с таблицы "model" на таблицу "marka". Не могли бы помочь с получением данного запроса?
Код (Text): SELECT `marka`.`marka`, `model`.`model`, `remont`.`time`, `remont`.`status`, `remont`.`clientID` FROM `marka`, `model`, `remont` WHERE `marka`.`id` = `model`.`markaID` AND `model`.`id` = `remont`.`modelID` ORDER BY `remont`.`time`
Важно понимать, что если в одной или второй из первых двух таблиц отсутствует соответствие в последующей таблице, то эта строка из выборки будет опущена. Для её отображения следует использовать "левое" объединение, где отсутствующее значение будет заменено на NULL. Но такое объединение не имеет настолько же простого аналога синтаксиса, как выше.
В целом, поддерживаю, потому что с JOIN нагляднее. Но ИМХО, слишком категоричное заявление. ))) В некоторых диалектах, например в Oracle 8i вообще нет/не было фразы JOIN, всё успешно выражается через WHERE. А для открытых соединений специальный синтаксис с (+) Это не к тому, что надо именно так писать, просто во многих источниках можно встретить такой синтаксис, потому что его использовал самый продвинутый на тот момент сервер БД.
Лишнее для топикстартера обсуждение вынесено в отдельную тему: https://php.ru/forum/threads/vyneseno-iz-zapros-s-obedineniem-trjox-tablic.101335/#post-662598 Булат, вот почитай чтобы понимать больше про соединения (join): нагуглил по быстрому - https://learndb.ru/articles/article/30
@artoodetoo@Drunkenmunky@Slava Rozhnev, спасибо вам всем большое! Так как в моём случае было желательно выводить всю информацию с одной таблицы, а с других добавлять по наличию в них информации, касательно строки с основной таблицы, я всё-таки выбрал вариант LEFT JOIN. Спасибо всем за "бурное" обсуждение по данной теме - получил для себя много новой информации.
Ну, так и добавили бы "марку" NoName и "модель" Unknown. Подобные задачи, где все поля формы обязательны к заполнению, так и решаются.
Эти обобщенные NoName тоже могут «пропасть» из «словарей». Если их и использовать, то только как замену NULL'ам при выводе. Хотя в принципе, как дефолтные значения, вполне можно использовать. Если юзеру влом делать выбор при заполнении формы или в словарях пока нет нужных данных (он собирает расширить словари потом отдельно).
Именно. Кстати, не обратил внимания сразу, более правильным, для этого случая, было бы держать `markaID` не в `model`, а таки тоже в `remont`. Иначе, хоть и редко, будут недоразумения - у производителей небогато с фантазией. Разве, что в Икее
Почему? У ТС'а правильно! Марка – это зависимый от модели признак. В remont надо хранить только «независимые» (т.е. зависимые непосредственно от ремонтируемого девайса) признаки. См., как ТС это сделал с клиентом (хозяином ремонтируемого девайса). --- Добавлено --- Иерархия легко восстанавливается: Код (Text): LEFT JOIN model ON modelID=model.id LEFT JOIN marka ON markaID=marka.id
Для записей, которые должны выйти из активного употребления, придумали "мягкое удаление" - не удаляем физически , а прописываем признак active=0 или дату deleted_at=now(). Таким образом, ссылочная целостность у исторических данных сохраняется. И при этом "удаленные" записи отфильтровываем в списках выбора.
Я и не говорю, что проблема нерешаема. Решаемо всё. Даже без дополнительных колонок и далее по списку. Но зачем усложнять базу, для которой и одной-то таблицы "за глаза". Если же в качестве учебной, то назначение неудачно выбрано. Лучше всего для этих целей какой-нибудь каталог с фильмами или книгами использовать. Тут тебе и сам фильм, и режиссеры с актерами, и жанры, и серии, и студии со странами проката... Учись-не хочу
да, и что? не в этой конкретной выбрке от ТС, но где-то будет дополнительное условие. реальные базы состоят из сотни таблиц, каждая из десятка полей. задача хорошая для тренировки, потому что позволяет расти. --- Добавлено --- реально сейчас ТСу не нужны никакие "мягкие удаления". это просто информация для расширения кругозора . чтобы он понимал про целостность и как выводить из оборота старые записи без проблем.
Я неправильно выразился. Кто-то должен её обслуживать. Мониторить актуальность названий. Вы серьезно?
Уж точно не программист будет отвечать за реальность данных ))) Наша задача создать надежную и заслуживающую доверия систему управления данными. Что объявить устаревшим - дело штатных работников заказчика. А я офигеваю от утверждений типа "там точно что-то потеряется, поэтому давай разрешим показывать null". Это неприемлемый вариант.
Так и я о том же. Устанавливаем значения по умолчанию, модель отвязываем от марки - ничего не потеряется, ничего не нужно мониторить. Конкретно для этого случая, идеальный вариант.