Здравствуйте.
Есть два таблицы, допустим
Студент
id
name

ну и , допустим, таблица какая-нибудь
Оценки
id
idStudent
mark

как связаны понятно)

на вход подается строка "имя студента, оценка", соответственно берем имя студента, вставляем в таблицу студент, если такого там нет, забираем idэтого студента , вставляем в Оценки...

вопрос: как бы так убыстрить эту всю канитель с таблицей Студент? наверняка же кто-то уже с такой проблемой сталкивался... а то сижу тут, изобретаю колесо...

изначально было у меня SELECT по имени (ну или хешу от имени) студента, если селект ничего не дал, то инсер и опять то же селект (ибо id вставленой записи надежно вместе с селектом кажется получить нельзя?).. как-то убожественно получается, поменяла на insert ignore и селект... но тоже как-то некрасиво, учитывая что зачастую студент уже есть в базе...

в общем может кто-нибудь подскажет идею как сократить время выполнения всего этого дела?

Akina,

читала) INSERT ... ON DUPLICATE KEY UPDATE выполняется медленнее, чем insert ignore...кажется...

авторА зачем оптимизировать такую простую и в общем недолгую операцию?
ну, может и не дорогую, но время то все равно забирает тем более что количество таких вот операций оооочень велико... думала, может можно как-то упростить, потому что неудобная и какая-то топорная схема получается(

tanglir,

авторибо id вставленной записи надежно вместе с селектом кажется получить нельзя?
имела ввиду сразу вместе с инсертом) ну чтобы вставил а тебе назад поле первичного ключа возвращалось))

авторlast_insert_id()
а если у меня 100 параллельно таких роботов работает, которые делают такую связку запросов? где гарантия, что последний вставленный будет именно тем, что вставила конкретная программа...как-то побаиваюсь его пользовать... да и все равно тот же селект... есть, конечно, еще вариант: в качестве внешнего ключа использовать не поле id а какой-нибудь хеш от имени студента, тогда второй селект не надо делать... но опять же коллизии разные, и некрасиво как-то получается...

авторв документации, которую кто-то ниасилевает прочитать
каюсь)) думала что возвращает последнее вообще а не в текущей сессии)


т.е. я так понимаю, от связки селект-инсерт-селект все равно не уйти?

Akina,

авторПо одному соединению или по разным?
В первом случае разумнее положить исходные данные в темп-таблицу

вот тут я не очень поняла... ну,допустим по одному, но что нам дадут временные таблицы, можете пояснить? во-первых временные таблицы обрабатываются не быстрее чем обычные, а во вторых...просто не могу понять каким боком их сюда целесообразно приложить...)

tanglir,

авторподумайте над ситуацией, когда вы делаете селект, и студента в базе нет
а когда делаете инсерт, он там уже появился, занесённый другим человеком :)

ну, схема с insrt ignore-select тут вполне подходит, мне кажется... вот, только last_insert_id() тут уже не воспользуешься, на сколько я понимаю... я правильно хотя бы понимаю?))

А на сколько целесообразно завести например хранимую процедуру, которая получает на вход имя студента, а на выходе отдает его id? Понимаю, что то же самое, что и было, только в профиль) но:
+ уменьшения объема кода
- не будет ли процедура медленнее чем обычные селект-инсер-селект?...
ну и опять же на сколько это целесообразно?)

Akina,

авторВы правда думаете, что при выполнении пачки последовательно передаваемых запросов лимитирующее звено - это производительность MySQL-сервера?

не буду скрывать, я не совсем спец в mysql, я бы даже сказала совсем не спец) поэтому сюда и обратилась))

ну, переставите, что у вас есть текстовик со списком всех студентов страны с их оценками по разным предметам... соответственно, текстовик распарсить и в базу затолкать последовательно все это дело...это подходит под "пачки последовательно передаваемых запросов"? ну и опять же это пример с таблицами студент и оценки очень утрированы по отношению к тому что происходит у меня, просто надо было как-то проще объяснить что я имею ввиду, ситуация-то распространенная как мне кажется)

в моем случаем скорость выполнения является одним из ключевых условий... правильно построенный запрос, правильно построенная бд, что еще может мне помочь ускориться?) ну, не знаю, по поводу правильных запросов у вас вот спросила, по поводу конструкции бд... а какие еще варианты есть, разбиение на 2 таблицы и связь их по id по любому лучше, чем хранить поле текстовое в таблице Оценки.

Akina,

я занимаюсь парсингом сайта. допусти какой-нибудь сайт с данными по всем футбольным матчам за последние лет 100. Мне надо это все дело в мою базу перекачать... да, вариант с CSV хорош , но тут задача более обширная чем просто тупо в две таблички загнать... таких таблиц как "студент" у меня больше 5 будет (судьи, игроки и т.д.,поэтому и хочу что-нибудь с этим сделать, а то надоело уже)... соответственно, заходим в каждый турнир, забираем данные по нему, заносим в бд, открываем страницы для каждого матча и т.д.... ладно если был бы готовый текстовик, тут же дело обстоит немного по-другому...заносить эту всю иформацию сначала в CSV а оттуда в базу?... какой-то... вообще не вариант, как мне кажется)
ну и мне критически важны сроки, в которые вся работа будет сделана

Arhat109,

авторЗапросите csv формат и его вам вышлют

и его дадут??? офигеть...просто, даже такая мысль в голову не приходила... пришла на работу, сказали вот сайт, вот открываешь код, парсишь, собираешь в бд...
ну просто капец, и я все это время страдала ерундой?!...

стесняюсь спросить, а как запросить этот csv, просто написать в поддержку: уважаемая редакция, пришлите мне данные?