Иван Мельников

https://docs.sqlalchemy.org/en/13/dialects/mysql.html
Классика.

Например эту библиотеку.
Или смотрите здесь

'%s' '%s',

Запятую пропустили.

Быстрее всего будет замапить в память:

Для сравнения, вариант от longclaps:

И ещё вариант от Зёма Подушкин:

Если файл огромный - можно поштучно искать переносы строки:

Либо ещё быстрее - читать блоками:

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

Ограничение уникальности накладывается на поля в рамках одного отношения, то есть то что вам хочется провернуть, а именно заглянуть как-то в другую табу чтобы проверить уникальность, из коробки такой возможности нет. Два наиболее очевидных способа решения задачи:
1) Прокинуть city_id в нужную таблицу. Да, не по феньшую, но реальность такая что нормализованные базы данных существуют только в книгах по базам данных или во всяких простячковых проектах, добро пожаловать.
2) Оставить все по феньшую и просто повесить триггер, в котором и будет происходить проверка уникальности по городу.

Да, можно конечно. Вопрос только в том, нужно ли это. Что это даст? Какую проблему решит? Какого результата вы ожидаете (повышение производительности, удобство редактирования и тд)? Не забывайте, что теперь для получения записи из любой таблицы вместе с ее описанием вам придется делать JOIN - приемлемая ли это цена за такую спорную "нормализацию"?

Это работает несколько не так. Events logging работает как сохранение таких данных как:
- уникальный идентификатор события
- имя события
- версия события (со временем обработчик может меняться)
- данные события
- опционально уникальный идентификатор сущности (но так делают не часто)

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

То о чем вы говорите является несколькими различными задачами. Доступ пользователей и роли это базовый принцип RBAC. Если несколько систем или она распределённая то стоит задуматься про Identity Server.

Логирование это отдельный срез и это делается как сбор access logs с вебсервера. Потом это можно положить в базу и анализировать, например, с помощью ELK стека.

Если надо ещё объединять по пользователям то вперёд и с песнями реализовывать свою систему по тому как access log вам надо анализировать по заголовкам и записывать в базу ручками. Тут готовых решений нет, вернее есть, стоят денег и вряд ли изменяются под чьи-то требования.

Данные по доступа к ресурсам можно снимать с proxy или балансировщика как вариант