Всем привет.

Вот такая ситуация возникла.
Пишу апи для сайта. Есть сайт который имеет даные, к примеру категории и сервисы, на том сайте можно их добавлять и редактировать.
Есть еще, так скажем копии этого сайта, ну или доноры, не суть. Суть в том что на этих сайтах нет добавления и редактирования тих данных, их нужно брать с главного сайта.

С главного сайта отдаю даные в формате json

Теперь вот встала заминка на получение и вставку этих данных. Обработчики висят на кроне.
Первое, думал использовать ON DUPLICATE KEY UPDATE, но у меня таблицы InnoDB и при
запросе ON DUPLICATE KEY UPDATE AUTO_INCREMEN увеличивается, хотя мне по сути это не столь важно изначально, но в последствии может скорее навредить. С одной стороны достаточно удобно, но вот этот нюанс с AUTO_INCREMEN меня коробит

Второе. Решил подумать над INSERT IGNORE, с одной стороны можно предположить что у меня могут быть индексы разные или описание или название поменялось на родном сайте и он мне дополнительную запись ненужную создаст, но в таблице есть поле дата создания категории или сервиса, поэтому это поле тоже можно считать так скажем ключем, оно не меняется. Короче думаю использовать INSERT IGNORE

Третье. Помимо вставки, севисы и категории могут отключаться, поэтому мне нужно еще обновление данных. С одной стороны ON DUPLICATE KEY UPDATE справится за раз
с другой плохо что INCREMEN увеличивает, а плохо в том, что если через год два на этот сайт включим возможность собственого добавления категорий тех же и было 1-2-3-4 а тут следующая будет к примеру 20. некрасиво
Поэтому думаю использовать INSERT IGNORE и уже отдельно делать обновление

Кто что думает? Надеюсь выразился правильно и понятно что я хочу сделать

Прочел про INSERT IGNORE, тоже если вставки небыло увеличит AUTO_INCREMEN

На хабре нашел вариант

$mysqli->query('INSERT INTO `user_innodb` SET `login` = "walker" ON DUPLICATE KEY UPDATE `id` = LAST_INSERT_ID(`id`), `money` = 10;'); 
echo $mysqli->insert_id; 

$mysqli->query('INSERT INTO `user_innodb` SET `login` = "walker" ON DUPLICATE KEY UPDATE `id` = LAST_INSERT_ID(`id`), `money` = 20;'); 
echo $mysqli->insert_id;

Выведет 7 и 7, первый раз запись была добавлена под id = 7, второй раз изменена.
https://habr.com/ru/post/310954/

Ну что, есть у кого какие мысли по тому поводу

Astin, первое, что пришло в голову - тебе нужна репликация. Там все эти нюансы учтены автоматически. Ведь то, что ты пытаешься сделать, и есть репликация!
Можешь посмотреть тут, например, https://habr.com/ru/post/56702/. Ну и в официальной документации смотри тоже. Преимуществ у репликации много, они все хорошо известны и описаны.

Второй вариант, это чтобы все сайты-копии-доноры обращались за данными к основному сайту. Либо напрямую к БД, либо через АПИ. Но я имею ввиду только запросы на получение данных! Вставка всё равно же делается основным сайтом. Так что зависимые будут только читать.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Я не могу донорам дать возможность подключения к бд главного сайта
С главного я отдаю инфу, доноры ее запросили и занесли к себе в бд

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

Если использовать репликацию, то я так понимаю все доноры будут подключены к одной бд, а мне как раз таки это не нужно. Мне проще чтоб у каждого донора была своя бд
Я установил донор администратору, проинсталировал что надо, повесил нужные файлы на крон и все, администратор получает свое и свои деньги. А вот вдруг ему в голову взбредет кого нанять и чтото переделать касаемо бд, вот пусть в свою бд лезит и делает что хочет, а не просит потом доступ полный к основной бд

Репликация кстати да, штука классная. Я скоро проект буду писать и там тоже будут доноры, но они будут только читать инфу и распологаться на одном хосте и как раз мне репликация и понадобится

Я не про это. Я не могу уловить, чем может навредить разрыв в последовательности автоинкрементных идентификаторов. Это же не порядковые номера.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ну может особо ничем не навредит если конечно через лет так более 20 не переполнится
Суть не в том, просто через пару месяцев уже увеличение на 60 минимум, у сервисов они показываются и вроде как не солидно будет выглядеть в списке сервисов такие разрывы идентификатора сервисов. По мне так хрен с ним, но хочется чтоб было нормально и красиво что ли. Вроде как с хабра пример нормально пашет

Если есть вероятность переполнения, используется bigint.

Очень большая ошибка воспринимать идентификаторы, как последовательности чисел, особенно если хочется, чтобы они были по порядку. Ситуаций может быть много, от возможности удаления каких-то ошибочных данных до откаченных транзакций. И вот твой случай.
Тратишь время на то, чего делать нельзя по определению.

Бытует еще одно стойкое заблуждение, что ID должен быть обязательно числом. Это не так. Стоит просто посмотреть на HTML, там ID с одними числами вообще запещен.

Идентификатор нужно ассоциировать не с порядковым номером, а с отпечатком пальца. Он индивидуален, это главное и единственное его предназначение. А в каком они идут порядке - дело вообще последнее.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

На счет bigint это да.

Я не трачу время на поиск именно этого решения, изначально сделал вот как писал до этого ON DUPLICATE KEY UPDATE, просто решил ради интереса поискать инфу что и кто как делает, ну и у ва, профи, поинтересоваться что вы думаете на счет вот такого.

По поводу

Что мешает получать идентификаторы с мастера? Если «удаляться ничего не будет», добавь в API-функцию параметр для указания базы, т.е. стартового идентификатора выборки (на слэйве значение можно получать из автоинкрементального счетчика или просто вычислять значение After как номер последнего идентификатора плюс 1). Если возможно обновление, обновляй записи с id меньше базы и добавляй в противном случае (передавать мастеру актуальную для слэйва базу в этом случае не нужно – можно передавать 0 или 1, либо вообще ничего).

P.S. Только не забудь после загрузки подкрутить автоинкрементальный счетчик на слэйве, если были получены новые записи (именно новые, а не обновленные).