Алексей
Да, я же создатель мема наверняка
Ну прости. Просто я удивился что обслуживающая должность стоит первой)
Алексей
Тогда только author родитель, а остальные дочерние?
Не совсем корректные аналогии тем более по таблицам. По ключам ещё. Да и то не корректно.
Алексей
Рыночек порешал, что поделать
😁 зря я в прошлом году от должности отказался. Сейчас бы самый большой по вилке был бы😁
Алексей
Рыночек порешал, что поделать
Но я парень идейный. Так что второй год упорно учу с++
Даниил
Хорошо. Тогда получается что всё три таблицы, если рассматривать отдельно являются основными, так как есть PK. Но если брать по связям: Если брать author , supply, тогда 1- родитель, 2- дочерняя Если брать author и book , тогда 1 - родитель, 2 - дочерняя. Если брать book и supply , тогда 1 - дочерняя, 2 - дочерняя.
Igor
Парни, кто может кинуть толковую ссылку или объяснить: какая таблица дочерняя, а какая родительская!? В инете нашёл инфу о FK, PK, связи 1 к многим и другие. Но всё равно не допираю.
Они стрелочки рисуют через жопу всегда рисовали в другую сторону. и между supply и другими двумя по идее нет связи хз какой мудак их нарисовал ... родительской называется таблица на которую ссылаются (в которй поле ссылки является праймари ключем) т.е автор родительская таблица а книги дочерняя... supply придумал какой то мудак и она сбоку припеку.
Igor
дай ссылку на главу откуда ты вырезал эту картинку
Даниил
Сек через комп зайду
Igor
Не все что можно связать через join является связью с точки зрения структуры базы данных . а там стрелочки рисовали уже от души ;)
Даниил
https://stepik.org/lesson/308887/step/2?unit=291013 чуть прокрути там будет схема
Igor
а это они так схему запроса рисуют ... теперь понятно
Даниил
я нихера не понял,получается мудак тут я?
Igor
давай еще раз в чем вопрос ;)
Igor
связь один ко многим многие ко многим и т.п. это название связей базы данных ... они будут на схеме обозначенны стрелочками
Igor
а линиями без стрелочек обозначенны условия соединения в джойне которые не явлюятся "связями" с точки зрения базы данных
Igor
Стрелки они рисуют как дебилы ... всегда рисовали в обратную сторону но по большому счету похер
Даниил
так, я хочу понять где дочерняя таблица, а где основная? Как понял, автор - ОСНОВА, боок -ЗАВИСИМАЯ ( очевидно, по ключу) НО остальные связи не понимаю, как разобрать : например автор и сапплай кто РОДИТЕЛЬ?
Igor
сапплай не имеет связи
Igor
поэтому к ней не применимо понятие родительская и дочерняя
Даниил
короче. тут только связь между автором и боок?
Igor
да
Даниил
потому что есть id
Igor
нет потому что есть стрелочка ... которой обозначается foreign key в базе данных
Vasily
Этот запрос должен отобрать строки из таблиц bookи supply такие, что у них совпадают и автор, и название книги. Но в таблице supply фамилия автора записана не числом (id), а текстом. Следовательно, чтобы выполнить сравнение по фамилии автора нужно "подтянуть" таблицу author, которая связана с bookпо столбцу author_id. И в логическом выражении, описывающем соединение таблиц, можно будет использовать столбцы из таблиц book, authorи supply.
Vasily
Там же все описано. Зачем, как и почему
Igor
он хочет понять в терминах родительская и дочерняя зачем то
Vasily
Да проектировали через жопу, но уж как есть
Даниил
я имею ввиду, что author_id есть и в одной, и вдругой таблице, поэтому есть связь РОДИТЕЛЬ-РЕБЯНОК. В других такой связи нет (...._id), поэтому они не могут быть ни родитель,ни ребенок?
Vasily
По идее там в supply тоже не имя автора, а его id должен быть.
Igor
это типа импорт новых поступлений
Igor
поэтому в нем айди не заполнен
Даниил
хорошо,зайдем с другой стороны. Если бы в таблицы сапплай было author_id и в таблице author был author_id, тогда связь была бы?
Igor
я имею ввиду, что author_id есть и в одной, и вдругой таблице, поэтому есть связь РОДИТЕЛЬ-РЕБЯНОК. В других такой связи нет (...._id), поэтому они не могут быть ни родитель,ни ребенок?
наличие поля айди это частый но не обязательный признак для создания связи ... никто не мешает сделать связь по текстовому полю, хотя скорее всего это будет лажа но мало ли какие случаи ... может быть это какой нить guid ключь не обязан быть числовым и иметь имя id ... более того по большому счету он не обязан быть праймари ключем
Igor
хорошо,зайдем с другой стороны. Если бы в таблицы сапплай было author_id и в таблице author был author_id, тогда связь была бы?
если бы связь была в базе она бы была если бы не было то не было ;) ... связь это сущность в базе
Igor
на схеме существующие связи обозначают линией со стрелкой
Даниил
да
Igor
стрелка у них указывает в сторону дочерней ... но обычно принято рисовать в другую сторону
Igor
потому что это книги ссылаются на авторов ... авторы про книги ничего не знают
Даниил
а если стрелки нет,тогда нет и связи или это другой тип связи?
Igor
все зависит от системы обознанчения связей на схемах ... они бывают разные ... но в первом приближении да
Igor
Наличие связе ведет к проверке целостности и является доп нагрузкой для базы ... если целостность не нужна или по еще каким то причинам связи может не быть ...
Даниил
хорошо, author_id дает нам уникальное значение,например Достоевский,который в табл author больше не повториться. Но в табл supply нет id,тогда получается автор может повториться два раза?
Даниил
два раза в сапплай
Даниил
тогда связь нужна
Vasily
У достоевского ж не одна книжка
Даниил
я про автор и сапплай имею ввиду
Vasily
Может хоть имя, хоть id быть несколько раз в сапплае
Vasily
Один автор, разное название книг
Даниил
тогда зачем нужен id, если он может повторяться. Он же должен быть уникальным или я не так понимаю?
Vasily
В таблице автор да, уникальеым
Даниил
а в табл сааплай может повторяться потому что там просто author?
Vasily
А в остальных нет... проще id хрпнить в тех табличках, чем длинное имя автора
Igor
потому что есть понятие нормализованная таблица и не нормализованная ... вот таблица supply не нормализованная поэтому в ней треш и угар ...
Vasily
У достоевского ж не одна книжка
Vasily
Щас он найдет формы и все...
Igor
supply забудь это дерьмо ... которое пришло из вне ... типа тетя бухгалтер загрузила xls файл .. теперь мы его должны обработать и запихать в основную структуру ... она не хводит в основную структуру базы данных это просто временная таблица куда срут всяким дерьмом
Даниил
ладно,парни,видимо я не догоняю совсем. Пойду еще читать про связи и какие то нормализированные таблицы. Спасибо за ответы,чуть позже снова их почитаю
Vasily
Не надо
Vasily
Мозг засрешь
Igor
не пытайся понять таблицу supply она не вписывается в идею реляционной базы данных ... она просто есть
Igor
так бывает ;)
Liza
тогда зачем нужен id, если он может повторяться. Он же должен быть уникальным или я не так понимаю?
Там supply_id т.е. id товарной единицы в магазине. Грубо говоря, автор и книга - сразу созданы как одна база (литература), таблица supply - запас книг в каком-то магазине - видимо создана была отдельно и добавлена в эту базу, у нее нет родственников, она приёмыш. Может, так понятнее...
Даниил
Лады,просто принять эту данность
Vasily
Это ашот с помойки книги принес и сдал в магазин по списку. Он не знает о магазине ничего
Даниил
а все табл так строится и каждый раз нужно ломать голову или это редкий случай просто попался?
Igor
зависиит от того кто строит ;)
Igor
посмотри по курсу и сделай выводы часто или редко ;)
Vasily
Это простая табличка и база 😁
Даниил
Ладно,спасибо,парни за объяснения !
David
Здравствуйте. После чистки ноутбука подключил WiFi модуль и он не работает. Может быть что вообще нет, а может быть, что минуту есть wifi и дальше нет
David
Пишет что модуль не подключен
David
Может ли быть что дрова полетели?
David
Не уверен что проблема с контактами т.к wifi бывает появляется