mayton2019

Коробочное решение этой задачи называется SQL-Builder.

Вот пример такого https://pypika.readthedocs.io/en/latest/2_tutorial...

Использовать string interpolation здесь технически возможно, но не выдерживает критики
по инфо-безопасности. Атака на инжекцию - это Top 10 уязвимостей софта в 21 веке.

Вот об этом коллеги тоже пишут в ответах.

CREATE TABLE IF NOT EXISTS

Скипает таблицу если она уже существует. Удали таблицу и тогда этот DDL отработает успешно.

быстро сравнить структуры БД и сделать скрипт, который приводит одну БД к структуре второй?

В этой задаче - большое количество подводных камней. Например что делать если в двух БД есть одинаковые
поля но имеющие разный тип (NUMERIC / VARCHAR). Дилемма... Что делать с исчезающими полями?
Удалять? Дилемма...

Я вообще не видел коробочных решение которые бы работали на "раз-два-три". Всегда есть нюансы.
И есть conditions которые нужно вбить или вкрутить в эти решения.

Написать скрипты которые извлекают метадату из одной и из другой БД не очень сложно. Но само практическое
применение подобных скриптов - ограничено. И я думаю что это как раз та причина по которой коробочные
"миграторы" не прижились.

У тебя нет выбора. Вариант раз - это интерполяция строк.
'create table {} ....'.format(...)
Вариант 2 - это конкатенация строк. Ну и проверь что строка состоит или alpha-num. И все.
'create table ' + ..... + '.....'

Асинхронное программирование не обязано соотвествовать структурному. Ты предполагаешь
что код исполняется сверху-вниз как в Pascal. Но он выполняется в соответствии с тем как
срабатывают отложенные функции. Вот когда SELECT вернет данные - тогда и твой чек-поинт "1" будет
напечатан.

Эти два запроса - какая-то безсмыслица.

SELECT Town FROM users WHERE user_id = (?)

UPDATE users SET 'Town' = (?)

Автор ты можешь прокомментировать словами что здесь происходит. Мне кажется что после обсуждения
у тебя должны возникнуть другие вопросы.

Я не встречал бесплатных механизмов репликации. Обычно для толстых коммерческих БД типа Oracle продавались коробочные продукты (Streams/GoldenGate) которые требовали знаний на уровне сертификации.

Какие могут быть пути репликации в простом случае. Для таких детских бд как SQLits:

1) Убить всё что локально и скачать все что есть в удаленной БД. На вид выглядит просто. Но неясно
как часто это делать. Что будет триггером для такого события? Очевидно что должна быть золотая середина
между потерпеть еще на старых данных или плюнуть и стартовать обновление которое на мобиле
может затянуться на несколько минут. Вобщем пользователь страдает.

2) Придумать механику инкрементального обновления. Для этого вам будет нужно добавить во все
таблицы поле типа last_update_timestamp (вот примерно как Сергей выше писал) и обновлять только те
записи которые старше максимальной даты которая уже есть. Кроме того надо во второй транзакции
убить те записи которые были удалены в remote. Здесь - посложнее т.к. для убийства мы должны
гарантировать существование PK для всех отслеживаемых таблиц. Мой опыт работы с БД показывает
что там не то что PK там даже и нормализация не всегда делается. Все это как-то выглядит хрупко
как хрустальная ваза и возможно потребует дополнительных индексов которые раньше не требовались
для работы системы. Но при хорошем индексировании триггер можно дергать хоть каждые 15 минут.

В более сложном варианте я-бы предложил реплицировать не SQL протокол а тело самой таблицы.
И вести учет контрольных сумм блоков наподобие дерева Меркла. Но это решение настолько далеко
уходит от React-Native приложух что я-бы сам себе не советовал. Тут еще могут быть трудности с native
представлением SQLite. Неизвестно будет ли такая реплика бинарно-совместима.
Но это будет хотя-бы быстрая реплика.

Вот эти две вьюшки можно заменить на одну.

t2 AS (
    SELECT id
      FROM books
     WHERE dateYearPublished IN (2000) 
),
t3 AS (
    SELECT id
      FROM books
     WHERE pagesCount BETWEEN 200 AND 1000
),

что-то вроде

tbooks AS (
    SELECT id
      FROM books
     WHERE dateYearPublished IN (2000) and pagesCount BETWEEN 200 AND 1000 
)

Ну и count каждый раз считать не надо. Как-то кешируй там результат.

Очень часто новичкам нужен не count а exist хотя-бы одной строки. А это другой вид запросов.
И его использовать выгоднее чем count.

Поскольку нет никаких больше требований. У нас имеется типичная документно-ориентированная БД.
Рецепты. Ингредиенты не специфицированы. Могут быть любые.

Лучше всего здесь подходит MongoDb. И поиск по ингредиентам нормально сработает.
Одна таблица. Просто и изящно.

Тут скорее всего ничего нельзя сделать. Судя по всему используется Django ORM.
А любые ORM библиотеки не подходят для массовой загрузки-выгрузки.
Надо просто отказаться от ORM и работать на уровне БД (Mongo/MySQL)
их собственными средствами пакетной загрузки.

Добавь новую колонку telegram_id.

А этот код скорее всего не работает
CREATE TABLE IF NOT EXISTS users
потому что он опционален.

Ты сам себя перехитрил :)

Согласно законам нормализации в самой первой нормальной форме 1НФ требуется чтобы все данные лежали
в таблице и ячейчки содержали атомарные значения. Тоесть списки - нельзя. Иначе такая таблица
не признается реляционной и делать с ней реляционные действия невозможно.

Попробуй разбить свою таблицу на две. Пользователи. И id_пользователей.

Эта команда - опциональная.
CREATE TABLE IF NOT EXISTS users
тоесть она могла и не выполнятся. А если она не выполнялась - то очевидно что существует другая таблица users.

Давайте смотреть что в этой другой таблице. Автор неужели ты не мог логгирование добавить? Этож просто. Хоть бы знали работал ddl или нет.