Александр Нестеров

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

Тут какая то порнография с отступами, методами и их параметрами.

def process_shot(user_id):
    global cur, con
    return True
    return False
success_rate = get_upgraded_success_rate(user_id)

Это вот вообще как? Зачем? Метод то закончился, откуда user_id возьмется

Вы не смогли перевести текст ошибки?

что-то по лучше, чем MySQL

а что получше - феррари, карьерный самосвал или метро?
Феррари вроде как быстрее, но не может перевезти 500 тонн за один рейс. Карьерный самосвал перевезти может, но расход горючки сумасшедший. А у метро фича - гоняет без пробок, но только там, где рельсы заранее проложили.

Все хорошо у MySQL с ресурсами.
У вас сейчас нет соцсети с миллионами юзеров, поэтому вам не нужна никакая навороченная сверхпроизводительная архитектура и бигдата.
Когда упретесь в производительность вы сперва подкрутите настройки того-же мускула, потом распараллелите, потом часть данных вынесете в какой-нибудь редис, и только когда и этого будет мало, вот тогда вы задумаетесь о смене основной БД.
К этому времени вы уже будете иметь представления какие у вас посты, сколько их, где у вас в архитектуре узкие места, и будете неплохо представлять какие есть альтернативы.
Альтернативы конечно и сейчас есть, но они вам не нужны в данный момент - больше мороки с ними, чем пользы. Ну выберете вы сейчас метро, например, будете инвестировать скиллы и время в рельсы, а в тоге окажется что вам нужно не метро и не самоствалы, а больше подошли бы нефтеналивные танкеры. Вы заранее не можете предсказать что и как у вас будет устроено.

Целиком в БД сохраняют с тегами HTML, или Объектом JSON

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

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

Неправильно.
Названия переменных и функций должны быть говорящими, чтобы их назначение сразу было понятно. Урезать названия до пары символов, лишь бы было покороче, - очень плохо.
По пробелам, пустым строкам, отступам и пр. есть стайлгайды - рекомендации по оформлению кода. Например, PSR-1 и PSR-12 для PHP, Google Style Guide и Airbnb Style Guide для JS. В компании может быть принят и какой-то свой стайлгайд.

Не правильно.

Код должен быть читаем и понятен человеку. Причем, не только автору, но и «злому маньяку тим-лиду, который вооружен и знает, где вы живёте», как говорится в шутке программистов.
Для этого пустые строки между блоками кода бывают полезны. Как и комментарии, и длинные осмысленные наименования переменных и фукций.
Компилятор потом всё равно всё перелопатит по-своему в ацкие бинарные инструкции )

Как форматировать код — договариваются. Есть общепринятые стандарты форматирования кода (coding style). Например, стандартный для PHP. Или принятый в компании AirBnB для JavaScript.

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

SELECT * FROM table_name ORDER BY id ASC запрос sql для получения всех полей с сортировкой начиная с самого мелкого Id.
Как засунуть результат запроса в теги - ЗНАЕТ РАЗРАБОТЧИК ТВОЕГО САЙТА.
Все сайты сделаны на разных CMS , а некоторые вообще самодельные, логика работы везде разная, тут не кто не скажет ответа на то не знаю что

Просто сделать линух своей повседневной операционной системой.

1) Умеющие работать с клиентом телеграма, e.g. https://github.com/LonamiWebs/Telethon
2) Умеющие получать список рабочих процессов, e.g. psutil

По своему опыту скажу, что учиться в университете и одновременно работать разработчиком реально.

В моём случае руководитель пошёл на встречу: я устроился на полставки (20 часов в неделю) + работа дистанционно.

Так что главное 1) решить что важно для тебя, 2) уметь договариваться.

А мы откуда должны это знать?

Читать документацию, конечно. Там это описано.

Во-первых, проверить структуру таблицы eBase, какие столбцы там есть.
Во-вторых, никогда не использовать форматирование строк для составление запросов.
Для этой цели есть parametrized queries.

Без кода нельзя точно сказать, что именно не так.