Нуждаюсь в вашей помощи.
Дано: есть 2 таблицы. 1 таблица авторов - ИД, имя, фамилия, оценка. 2 таблица книг - ИД, название, ид-автора, оценка.
Заполнение этих таблиц идет собственно через 2 формы. Если создание записи автора может макака написать, то с записью книги я уже сижу который день. Я смог добавить в лист выбора полное имя автора, но запись не идет. Также выводить таблицу для чтения нужно будет вместо ИД выдавать полное имя.
Верю в силу двачика.
Побампаю несколько раз, надеюсь взлетит и мне поможет величайший
Нихуя не понял. Тебе в итоге что нужно получить?
sql запрос корректный, как записать из формы, хотя бы это
Из какой формы? Хотя бы что?
ну пишешь INSERT, указываешь id автора, покаж свой запрос
> 2, 1 в одной ячейке
Дебил блядь Дружище, так не делают, неудивительно что у тебя не получается. Посмотри что такое 3 нормальные формы.
FK автора?
Вот форма, имена берутся из sql таблицы авторов, мне надо из этих имен вырвать их ИД и закинуть во вторую таблицу
Ты у меня спрашиваешь? Ты ебанутый? Что такое FK автора?
$sql = "INSERT INTO books (title, p_id, grade) VALUES (:title, :p_id, :grade)";
Тебе нужна третья таблица со столбцами ID, книга, автор, нельзя писать в одной ячейке два значения.
ID автора из таблицы авторов
А что такое тогда id нахуй?
Идентификатор / Primary key
>А что такое тогда id
«Иди нахуй»
попробуй замутить это с помощью pandas на питоне.
вдобавок к этим двум нужна еще одна?
SELECT
id
FROM
authors
WHERE
fname = SPLIT_STRING(та хуйня, что в форме)[0]
AND
lname = SPLIT_STRING(та хуйня, что в форме)[1]
Че-то типа того
Не?
Он дело говорит, но можешь попробовать костыль запилить, типа p_id1, p_id2
да, только я хз как их записать сразу с названием и оценкой
Нужна таблица с двумя вторичными ключами, чтобы можно было к одной книге несколько авторов приделать. Будет
Id book_id user_id
1 1 1
2 1 2
3 1 3
т.е. книгу 1 трем людям 1, 2, 3 приписываешь
Названием и оценкой чего? Авторов или книг?
Название книги, ИД авторов, оценка, которую читатель книге ставит
Двачую этого господина. Если тебе нужно выводить несколько авторов, то пили author_1_id, author_2_id
Вставляешь двух авторов, потом книгу, потом отношение в третью таблицу выше.
Костыль, потом будет криво искать все книги одного автора, индексы сложнее будут работать
>Делать круд на пандас
да ты поехал, чел.
Дата саентист от скиллбокса в треде
А как грейд автора связан с грейдом книг?
никак, это разные оценки.
ты id авторов через запятую пишешь в строковую колонку?
Чел, ты так ничего и не понял...
:-(
Нельзя так таблицы строить, препод тройку поставит.
Анонов не слушаешь, так хоть про нормальные формы сходи почитай.
"INSERT INTO books (title, p_id, grade) VALUES (:title, (SELECT id FROM authors WHERE fname='fname' and lname='lname'), :grade)"
>>233414157
Необучаемый долбоеб
author
id (pk, auto-incremented)
first name
last name
rating
book
id (pk, auto-incremented)
title
rating
author_book
author_id
book_id
когда создаёшь книгу добавляешь 2 записи, в book и в author_book. Verstehst?
Он не понимает как ему айдишник получить даже, а ты ему предлагаешь таблицы усложнить
Бля, чел, ты ебанутый? Многое ко многим юзать, когда ТОЧНО ИЗВЕСТНО, что авторов два или один? Тут просто два поля и два один ко многим.
Тебе бы в в форме добавить какое-то скрытое поле, с айдишником выбранного автора. Его и будешь использовать в запросе на добавление автора к книге.
Но все айдишники в одну колонку я бы не запихивал, это хуйня. Лучше всего так как этот пишет >>233414578
Но ты сперва разберись как ты айдишник будешь получать, чтобы лишних подзапросов не делать.
>Бля, чел, ты ебанутый? Многое ко многим юзать, когда ТОЧНО ИЗВЕСТНО, что авторов два или один? Тут просто два поля и два один ко многим.
потом из-за таких программистов видишь в легаси базах custom_field_1, custom_field_2, customer_field_1000.
И запросы у тебя будут вида "select * from book where author1_id = X or author2_id = X". Подумал как индексы будут работать на больших объемах?
препод такое задание и дал, 2 таблицы, 2 формы
так а если там несколько авторов с одинаковыми именами?
А зачем нам несколько авторов с уникальными именами? Констрейнт сделать на уникальность сочетания имени и фамилии.
На каких объемах, сумасшедший? Это обычная лаба, ты же понимаешь, да? Тут всего два автора и микроскопический объем. Нахуя городить промежуточную таблицу?
>Но ты сперва разберись как ты айдишник будешь получать, чтобы лишних подзапросов не дела
и сейчас самое время рассказать про то, как добавить книгу и связь в одной транзакции, чтобы поддержать атомарность
>На каких объемах, сумасшедший? Это обычная лаба, ты же понимаешь, да? Тут всего два автора и микроскопический объем. Нахуя городить промежуточную таблицу?
Чтобы научиться правильно моделировать данные в реляционной базе, не?
суть в том, что потом это прогонять тестером надо, который несколько раз создает одинаковые записи, и на каждую запись ему нужно выдать верный id
Я бы одно поле сделал, name и один констрэйнт. Зачем их разделять... Тем более могут быть middle name
Чтобы научиться правильно моделировать данные -- надо делать это многократно и чтобы твою модель обсирали знающие люди. А просто с самого начала загрузить сложными вещами это долбаебизм
>препод такое задание и дал, 2 таблицы, 2 формы
и 2 автора у книги? Пиздос, это какое учебное заведение?
Хуевый это тестер, надо написать тестер с разными именами.
Но можно и с одинаковыми, но тогда тебе надо сразу доставать айдишник при селекте и каким-то образом его скрывать. Или можно нахуй не скрывать, а просто выводить "Семен Лопатович (11)", где 11 - это айдишник. Потом распарсить строку регекспом и забрать айдишник из неё. Это если тебе совсем поебать
Бамп
>Чтобы научиться правильно моделировать данные -- надо делать это многократно и чтобы твою модель обсирали знающие люди. А просто с самого начала загрузить сложными вещами это долбаебизм
Мне прямо не хочется тебе грубить, но это не правильно. Хочеть простую задачу - ставь задачу так, чтобы был 1 автор у книги. Будет тебе простое 1:n. А делать n:m через несколько столбцов - за это у нас во дворе пиздят только в путь
Европейское высшее))
BEGIN TRANSACTION
твои ебучие запросы
PROFIT;
COMMIT;
как id книги получишь, транзакция то не закоммичена ?
Навскидку, можно взять айдишник последней записанной книги и прибавить 1. Но тут получается race condition, если несколько людей одновременно будут записывать.
Давай рассказывай, как правильно
>Навскидку, можно взять айдишник последней записанной книги и прибавить 1. Но тут получается race condition, если несколько людей одновременно будут записывать.
>Давай рассказывай, как правильно
В разных базах есть средства получить в транзакции айдишник последней вставленной, но не закоммиченной записи в таблице в ЭТОЙ транзакции. База резервирует айдишник, если транзакция откатывается, то он не переиспользуется и будет разрыв в айдишниках. В классическом sql такого нет, надо смотреть конкретную базу данных.
Поэтому нельзя использовать auto increment id для вещей типа уникальный номер инвойса, потом клиент будет рассказывать налоговой, почему у него прогалы в отчетности
Интересный момент. Ну я думаю, что опу до таких тонкостей очень далеко
ОП, гугли связь многие-ко-многим. Поймёшь зачем нужна третья таблица.
первые несколько постов вообще не понимал о чем речь, а когда рассмотрел на пике несколько внешних ключей в одной строке - не сразу поверил что так можно спроектировать
Ну да, это я так. Рано или поздно с этим сталкиваешься в работе
А да, забыл добавить, видел решения, где обходили это так: не юзаем авто инкрементальные id, а сами на сервер сайде генерим GUID. Тогда ты знаешь ID до вставки в базу и все просто.
По мне - уебанство, удачи службе поддержки которая будет ебаться с guid'ами при разборках проблем вместо обычных чисел. Ну и размер таблиц, производительность тоже будет хуже
Ууу, сука. Ты мне своими гуидами ёбанный ФИАС напомнил.
Как вспомню - аж трясёт.
Сам вставлял в таблицу колонки с константами 0 и 1, двойные дублирующие колонки и вообще клал на нормальные формы. Энтерпрайз, 300к/с.
У тебя, блять, на фронте база? Ты ебанутый?
А вообще, если по делу - греби айдишник по имени, лол. Что сложного-то?
У тебя навряд ли база будет на 100500 авторов и поиск по пару-мегабайтной базе будет проходить моментально. Не красиво, да, но для решения задачи самое то не будешь же ты блять эластиксёрч прикручивать. У тебя даже база на фронте, ёбаный ебать.
Можешь ещё угореть и подгружать сразу ID и ФИО всех авторов, а в поле выдавать только ФИО. Подзаебаться придётся конкретно тебе ты явно курсач какой-то пилишь. Можно даже по совету >>233415052 попробовать, но не слушай >>233414578 - он долбоёб клинический
Пиздос, а если авторов у тебя три? А если пять? Ты этот момент продумал?
А сколько у нас одновременно ОПЕРАТОРОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ?
Если там одна баба Зина сидеть будет, то похую вообще и не заморачивайся над этой хуетой