Не, я имею ввиду, как его получить?

селект, но как?

Как тебе надо, так и выбирай из базы. SELECT id, title FROM post WHERE slug = 'some-testing-post';

если есть айдишник, как в примере наверху, то указав его в where: SELECT * FROM post WHERE id = 123123

Как тебе надо, так и выбирай из базы. SELECT id, title FROM post WHERE slug = 'some-testing-post';

А как потом полученный id засунуть в INSERT?

из какой задачи появились все вопросы?

Как делать запросы в нормализованую базу данных? Допустим есть таблица users id user_name и таблица stats id stat_name И таблица user_has_stat И в приложении есть только юзернейм и название статы

с этой

В приложении есть stats.name, player.login и value для вставки в players_stats

тебе нужно вставить несколько связанных записей?

Собственно из первых двух нужно получить id'ы, для вставки в players_stats

тебе нужно вставить несколько связанных записей?

Не совсем понимаю, что вы имеете ввиду под "связными записями"?

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

stats и players условно уже заполнены

вставка будет только в players_stats

и "новые" значения это только value

ага, и нужно получить id статы по ее имени?

да

и id игрока по логину

SELECT id FROM stats WHERE name = 'abc'

должно даже такое сработать INSERT INTO player_stats (player_id, stat_id, value) VALUES (1, (SELECT id FROM stats WHERE name = 'abc'), '123')

пробовал подобное, но без скобочек, в аргументах VALUES

сейчас с ними попробую

не работает

Здесь я уже не силен, но тогда можно просто разбить на два запроса и хоть в переменной сохранять. Обычно это делают на стороне приложения

Просто мне показалось странным, делать это на стороне приложения

Всё же база данных смогла бы это как-то оптимизировать и всё такое

Type the URL of: a feed page, a Facebook public page, or a Twitter/Youtube/Instagram account

Не, это абсолютно нормально. Здесь действительно можно одним запросом обойтись, но в большинстве случаев без ЯП посередине нормально не обработать данные

An error has occured. The feed 'http://Не, это абсолютно нормально. Здесь действительно можно одним запросом обойтись, но в большинстве случаев без ЯП посередине нормально не обработать данные' cannot be added (error: 'Invalid URI: The hostname could not be parsed.')

Кстати, а чем отличается REPLACE от IINSERT… ON DUPLICATE KEY UPDATE ?

replace - это функция для работы с данными, не с записью

можно сделать реплейс строки в определенном поле записи

REPLACE INTO table (key, a, b c) VALUE (1, 2, 3, 4) работает так же, как и INSERT INTO talbe (key, a, b c) VALUE (1, 2, 3, 4) ON DUPLICATE KEY UPDATE a=1, b=2, c=3

разве нет?

ой, a=2, b=3, c=4

а

on duplicate key update имеет шанс оставить часть старых значений

replace полностью перезапишет

https://ruhighload.com/post/%d0%9a%d0%b0%d0%ba+%d1%83%d1%81%d0%ba%d0%be%d1%80%d0%b8%d1%82%d1%8c+Mysqldump+%d0%bd%d0%b0+%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%b0%d1%8e%d1%89%d0%b8%d1%85+%d0%b1%d0%b0%d0%b7%d0%b0%d1%85+%d0%b4%d0%b0%d0%bd%d0%bd%d1%8b%d1%85?utm_source=mail&sa=3071:be30b951db0f644c18ae8500fb6519f7

ruhighload очень хороший ресурс

Да

Методичка по созданию репликации у меня долго не закрывалась в браузере

А скинь методичку

Пока на гтид не ушли

С телефона не найду

Как так получилось, что таблица на 306 мб с полной избыточностью перенеслась в mysql без избыточности в 285 мб На sqlite была структура INT INT TEXT TEXT INT На mysql структура int(5) int(4) varchar(32) Перенос был таким INT -> удалено, было A_I ключом INT -> int(5), без изменений TEXT -> int(4) + доп. таблица на 4мб TEXT -> varchar(32), без изменений INT -> удалено, хранило тип значения в 4 поле

Средняя длинна во втором TEXT поле была 12 символов, ну а на mysql собственно 3 цифры

Ну там разный бинарный формат, это не очень корректно сравнивать

Емнип int 4 по занимаемому месту не отличается от просто int

Ну там разный бинарный формат, это не очень корректно сравнивать

У sqlite он получается сам по себе легче, причём на много?

Понятия не имею, да и сравнивать по одному кейсу тоже некорректно

При выборе базы данных больше имеет смысл смотреть на гарантии и удобство работы, чем на 25% различия отдельных характеристик

Я уже выбрал, просто мне показалось странным, что уменьшение размера такое незначительное, думал, что будет больше. Но я ещё попробую с типами поиграться, может быть как-то поможет.

мда про мускул то немного фанатов)

Ничего, скоро подтянутся... ?

Главное задавать вопросы каверзные

походу в каком-то чате дали ссылку

https://geektimes.ru/post/285704/ Там список чатов выложили

Круто

Hi

Hi MySQL!

Кто нибудь использует MySQL на fusionIO: как можно убедиться, что atomicwrite включён, а doublewrite выключен?

Версия persona 5.7 - в доке нашёл что типа мускул сам определяет что живет на фьюжене.. прям магия

и тишинааааааа