mayton2019

Все int я индексировал

Вот ты чудак. Надо не все индексировать а только те которые оптимизатор запросов может выбрать в плане запроса.
Ты кстати еще получишь обратную связь в виде замедления update/insert/delete на такой чудо-таблице.
Оптимизация - это искусство. И тут нельзя так... приходить и ВСЁ индексировать...

Обычно эволюция кода идет синхронно с обновлением схем в БД. Для этого есть инструменты типа liquibase/flyway. Они приводят в БД в состояние полного синхронизма с вашим репозитарием кода. И то что у вас происходит (нет таблицы) - это ужас-ужас и надо срочно что-то менять в жизни.

Вот так. Развивайтесь. Взрослейте. Хватит уже бегать в детских штанишках. Хорошая система должна трекать свои изменния. Берите лучшие практики которые есть сегодня. Создание таблицы в секции catch - это опасная практика которая кроме того вызывает еще один парадоксальный вопрос из серии - а что делать если exception возник внутри секции exception и так далее.

Для более конкретного примера: мне нужен middle+ frontend разраб, которого заинтересует моя та или иная идея

Со стороны выглядит будто ты - такой себе ловкий менеджер. Сидишь и хочешь надурняк что-то высидеть :)

Смотри если твоя идея реально ценна (в ней есть бизнес интерес) то наверное лучше пойти на крауд-файндинговы площадки и там собирать деньги. Или поискать инвесторов.

Если у тебя - чисто научный интерес - то иди лучше в научные кафедры. Ищи себе руководителя и грызи гранит науки. Может станешь лет через 10 кандидатом наук.

До кучи еще посмотри сериал Силиконовая Долина. Тоже про идеи.

Какой формат данных (JSON или JSONB) лучше использовать в этой ситуации?

Похоже автор занялся любимой задачей скучающих разработчиков. А именно - ПРЕЖДЕВРЕМЕННОЙ оптимизацией.

JSON и JSONB возникли например из задачи хранения в БД ДОКУМЕНТОВ. Документ - предполагает специфический юзкейс. Например однократное создание и редкую модификацию. И частое чтение с поиском по текстовому индексу например.

Является ли задача автора - подходящей под данный use-case? Чорт его знает. Я-бы сказал что пока нет. Все таки комментарии пользователя это такие себе... частые модификации документа которых хотелось-бы избежать.

И вообще пока не будет создано 2 макета или 2 proof-of-concept с бенчмарками - мы не можем точно сказать что лучше.

Сам-же Бартунов например в одном из своих докладов рассказывал что сама идея затащить в PG документы возникла из идеи работать с properties в одном поле. С такой себе неструктурированной информацией. А сама задача вознила из прикладной проблемы в дизайне базы для системы образования. Им нужно было хранить в строке неспецифицированный лист атрибутов. Это еще не JSON но уже дедушка его. Вот его так порешали. Это похоже на кейс автора? Я-бы сказал что далеко нет.

Вообще чтоб доказать или опровергнуть огульный тезис о JSON-ификации я-бы довел постановку до абсурда. Зачем мы будем трекать комментарии в JSON. Давайте и посты туда-же. И странички. И вообще всю модель положим в 1 документ JSON. Каково а? У нас будет база с 1 единственной JSON строкой которая хранит в себе всё. Технологично? Да. И не запрещается.

Вот как-то так.

Что такое раздача? Это когда ты опубликовал ссылку но кто-то конкретный не смог ее у тебя забрать. Тоесть он не видит твой хост по IP. Вот я-бы начал расследование именно с этого шага. Что это за человек. Где он сам сидит географически. Пингует ли он тебя? Соединятся ли по UDP/TCP. Может твой провайдер тут непричем.

Вот. А когда уже 2-3 человека твою раздачу забрали - то уже надо обсуждать видят ли их все остальные участники. Вот как-то так.

С провайдером все просто. Можно его спросить что он там по договору предоставляет и что нет.

Такой должности нету. Но это иногда делают архитектор, системный аналитик или просто технический лидер.

Все нормально добавляется. Разбирайся.

>>> import xml.etree.ElementTree as ET
>>>
>>> ET._namespace_map
{'http://www.w3.org/XML/1998/namespace': 'xml', 'http://www.w3.org/1999/xhtml': 'html', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#': 'rdf', 'http://schemas.xmlsoap.org/wsdl/': 'wsdl', 'http://www.w3.org/2001/XMLSchema': 'xs', 'http://www.w3.org/2001/XMLSchema-instance': 'xsi', 'http://purl.org/dc/elements/1.1/': 'dc'}

>>> ET.register_namespace("CadEng4", "urn://x-artefacts-rosreestr-ru/commons/complex-types/cadastral-engineer/4.1.1")
>>>
>>> ET._namespace_map
{'http://www.w3.org/XML/1998/namespace': 'xml', 'http://www.w3.org/1999/xhtml': 'html', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#': 'rdf', 'http://schemas.xmlsoap.org/wsdl/': 'wsdl', 'http://www.w3.org/2001/XMLSchema': 'xs', 'http://www.w3.org/2001/XMLSchema-instance': 'xsi', 'http://purl.org/dc/elements/1.1/': 'dc', 'urn://x-artefacts-rosreestr-ru/commons/complex-types/cadastral-engineer/4.1.1': 'CadEng4'}

Как осуществить переход из одного switch-case в другой и вернуться обратно

Вызвать метод.

Python-разработчик в it это что-то вроде разнорабочего на стройке. Вроде он умеет всё делать но никакой конкретной специализации или направления за Python не закреплено. Это с одной стороны хорошо. Т.к. получается универсальный солдат. А с другой стороны стикер Python еще не говорит о том например сможете ли вы работать в ML. Последнее требует широкого обыта в этой области.

Учитывая тренды времени я вижу следующие направления
- автоматизация тестирования
- автоматизация devops процессов, инфо-без
- BigData + ML + системы машинного зрения
- веб-разработка (Django, Flask), сюда-же я добавлю ботов и скрейпинг сайтов.

Тоесть как видите специализации настолько разношёрстные что надо углубить сам вопрос.

Не просто изучать Python, а изучать Python для конкретного вида деятельности.

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

Сильно зависит от background. Если автор заходит в Spring с улицы - то ему придется учить все в том числе SQL, ORM, Web, MQ. Это очень плохо и это ставит под сомнения обучение Spring.

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

Не нужно все задачи сваливать на регулярку. Регулярка видит семантику символьной последовательности.
Арифметческие смыслы - такие как диапазон, больше или меньше, это все - мимо кассы. Это задача для
целых и вещественных чисел а не для символов.

1) A OR В И В OR А;
2) A AND ВИ В AND A;
3) (A OR В) OR С И A OR С;
4) (A AND В) AND С И A AND (В AND С);

Это не надо доказывать. Это законы коммутативности и ассоциативности булевых операций AND/OR.

Даллее по тексту там - похоже на закон дистрибутивности но надо проверить.

Я никогда не слышал чтоб кто-то читал чистые алгоритмы. Обычно программа более конкретная. Например алгоритмы игровой логики. Алгоритмы маш-обучения. Обобщенные алгоритмы какого-то языка (C++) etc.

Чистые алгоритмы - это Кнут, Кормен. Короче сферическая лошадь в космосе.