mayton2019

Вот эта колбаса - по смыслу - group-by с фильтрацией. Попробуй сделать из 3 запросов 1.

,(SELECT COUNT(comment_system.id) FROM comment_system WHERE itemtype='qqq' AND item_id = ebids.id) AS has_qqq_comment 
  ,(SELECT COUNT(comment_system.id) FROM comment_system WHERE itemtype='www' AND item_id = ebids.id) AS has_www_comment 
  ,(SELECT COUNT(comment_system.id) FROM comment_system WHERE itemtype='eee' AND item_id = ebids.id) AS has_eee_comment

Поскольку ты тегнул вопрос "JAVA" то имеет смысл просто начать изучение сразу по книгам Брюса Эккеля и Хостмана.
Вот в разрезе того как они описывают ООП - тебе будет достаточно. Еще посмотри на книгу Шаблонов проектирования (от Банды четырех) и Рефакторинг с шаблонами от Джоша Кериевски.

Читать чистую ООП - теорию я тебе не советую. Там нет того что тебе понадобиться.

Мне вспоминается мульсериал Футурама. Там когда профессора спросили - на каком принципе летает его космическая ракета - он ответил что она на самом деле не летает. Она стоит на месте. Просто она двигает вокруг себя всю вселенную.

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

SELECT 
 `user_id`, `username`, `first_name`,`last_name`, `title` 
FROM 
 `userdata` 
WHERE 
 `type` LIKE '%group'

Мне кажется что JavaScript/TypeScript - это плохой старт для изучения ООП. Дело в том что JavaScript исполняющая среда изначально была разработана с слишком вольной интерпретацией объекта. Грубо говоря она настолько flexible что те строгие законы и правила которые навязывает ООП в JavaScript могут быть слишком легко нарушены.

Поэтому чтобы почувстоввать нужность ООП, как дисциплины. Я-бы предложил Java или C#. Это как в музыке. Нельзя начать сразу ипровизировать джаз на музыкальном инструменте в 5 лет. Надо пойти в музыкальную школу где преподаватели тебе поставят руку правильно. А потом уже после семилетки - муз-училища - консерватории - иди в импровизации. Или даже иди раньше. Но какая-то дисциплина должна быть. ООП - это дисциплина. Не волюнтаризм.

Несколько мыслей. Не претендует на правильность. Особенностей Котлин не знаю но подозреваю что он под капотом просто использует Java Threads.

1) Java используют модель потоков при коророй 1 поток ОС не равен потоку JVM. Обычно 1 поток ОС может обслуживать много Java threads. В состоянии покоя threads мало потребляют ресурсов.

2) Я пока не вижу проблем до тех пор пока у вас нет нехватки Heap. 1 Thread по умолчанию аллоцирует 1Мб поэтому 1000 тредов могут у вас скушать гигабайт. Есть опция командной строки которая это регулирует. Ее надо трогать аккуратно чтоб не получить другую ошибку типа Stackoverflow.

3) По поводу того чем заняты threads. Сделайте дамп стека потоков как один чел тут пишет https://www.baeldung.com/java-thread-dump

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

4) Кроме того программист должен был заложить в конфиги регулятор числа рабочик потоков в пуле. Это может быть нечто вроде

Executors.newFixedThreadPool(....);

короче поищите в сорцах. Если не заложил - попросите пускай сделает это property.

Тут нужно акцент не на С++ делать а на то что разработка ведется для Windows. Тегнул топик.

Вот ссылочка на DLL-linked ordering. Может будет полезна

https://docs.microsoft.com/en-us/windows/win32/dll...

У нас как-то Windows-NT простояла в работе аж до 2010 года. И ничего.
Главное чтоб МС не заложил туда никакоую тайм-бобмочку. А так - хоть 100 лет
пускай работает. Я-бы больше смотрел в бюлетень уязвимостей SMB-протокола.
Если ОС не поддерживается то тогда и фиксы не доставляются. А про SMB уязвимости
как-то в youtube говорил один дед по имени КиберДед. Хотя я ему не верю если чесно.

Соревнования и Олимпиады помогают для поступления в университет. Но они они не способствуют поступлению на работу в большую корпорацию. Скорее наоборот. Олимпиадник - опасен и создает проблемы для проектов которые работают по 20-30 лет. Олимпиадник также будет раздражать других командных игроков. Его оценки (эстимации) задач будут слишком отличаться от других. Олимпиадник плохо понимает необходимость эстетики программного кода и SOLID-философии. Дай бох что за 5 лет учебы в университете этот гений слегка поостынет и начнет думать как team-player.

В принципе имеет. Почему нет? Но есть нюансы.

Вот самое слабое утверждение .

"регулярно" пересчитываем хэш найденных сущностей и сравниваем с хэшем сохраннённой sqlite

Регулярно это как? Каждую секунду? Или минуту. Вобщем тут нет единого правильного ответа. Нужно разговаривать с бизнесом и понимать где можне чем пожертвовать. Или точно знать что работаем с архивными данными. Следовательно кеш - вечен. Или работаем со справочником товаров которые обновляются раз в сутки. Тогда обновление или переасчет кеша можно просто привязать к старту системы. И каждый день перегружать ее.
Короче инвалидация кеша - это главная проблема в любых инициативах с кешом.

Далее объем. Надо быть очень удачливым или иметь очень строгое ТЗ чтобы гарантировать что кеш будет иметь разумный объем. Если кеша будет не хватать или он будет в ротации в памяти с другими кешами то вреда от него будет больше чем пользы.

Далее идеология. Может ваша система уже давно переросла реляционку (EAV как признак) и ей просто нужно волевое архитектурное решение. Затащите документную БД. Mongo, CouchDb. Может вам с ней будет проще работать. EAV никогда не была эффективной в смысле скорости.

Лет 10 назад у меня в БД Oracle была такая проблема. Медленно чистились исторические partitions.
Ничего нельзя было придумать. Потом мы заметили что удаляется 99% datarows. После этого пришла
идея - вообще ничего не удалять а просто пересоздавать историчесекий parition с теми datarows
которые НАДО ОСТАВИТЬ. И грохать оригинальный. После такой оптимизации мы ускорились в 1000 раз. Надо было только сделать exchange partitions (ораклоиды поймут).

Вот так вот.

var token = jsMain["data"][i];
                if (!unique.Contains(token))
                {
                    token.Remove();
                }

Попробуй другую стратегию. Пересоздай новый JSON. С учетом удаленных токенов.

Если это - бизнес факты и таблица - PARTITION BY RANGE по дате - то можно суммировать только за последний день. Ну и предыдущие - просто хранить как результат суммы.

Вот как-то так. Возможно некрасиво.

>>> dict = {
  ...   "a": "1",
  ...   "b": "2",
  ...   "dict2": {
  ...     "c": "3",
  ...     "d": "4",
  ...   }
  ... }
  >>> 
  >>> for i in dict:
  ...   print(type(dict[i]))
  ... 
  <class 'str'>
  <class 'str'>
  <class 'dict'>

JOIN - не плохой.

В эпоху соц-сетей (facebook e.t.c.) придумали подготавливать веб-контент на сервере для каждого пользователя персонально. Ваша лента новостей. Ваш landing. Статистика. Все это хранится в какой нибудь RocksDb (на самом деле я не знаю в какой просто для примера взял) и извлекается просто по ключу. Обновляются эти документы по событиям. Тоесть мессенджинг системы тоже нужны. LinkedIn был настолько озабочен этим вопросом что создал Kafka решая задачи своей соц-сети.

Все эти хитрости сделаны только для того чтобы убрать реляционные БД из стека веб-технологий и сделать отрисовку landing как можно более быстрой. И этой быстроты невозможно было-бы достичь если-бы делать select всех новостей где подписчик == вы и где еще и все 100500 новостей order by... короче поняли. Ну и join тоже убрать. В любой умной БД есть звезда или снежинка и отрисовать на экране звезду и снежинку без join невозможно. Вобщем join здесь не причем. А важно что - убрали стек одинаковых повторяющихся операций поиска-соединения-фильтрации-сортировки и заменили на извлечение документа из документной БД.

Забавные страхи. Ну что-же мысли по пунктам.
- Можешь работать с ноутбуком. Он ведь не включается в розетку.
- Выключать технику из электросетей во время горзы в принципе совет разумный. Особенно это касается сетей где нет грозовой защиты. Проконсультируйся с электриком на этот счет.
- Привлекает грозу обычно не бытовое устройство а области низкой проводимости между небом и землей. Обычно это высокие сооружения из железа. Телевышки. Опоры электросетей. Антены и прочее. До того как молния до тебя долетит - она в первую очередь будет притянута именно к этим сооружениям, после чего уйдет в землю и нейтрализуется.
- Во всех случаях следует оставаться человеком разумными и следовать рекомендациями властей и гидромедцентра. Если ты живешь на острове где цунами и землетрясения и прочий disaster - то тогда для тебя не важны будут советы этого форума а важны будут в первую очередь задачи как спасти себя и свою жизнь а потом уже думать о технике.

Про что ERP системы? Они - про управление ресурсами предприятия. Нужно ли вам в процессе управления осуществлять поиски и соединения по разным сущностям? Скорее всего - да. 99% что да.

NoSQL системы принципиально не поддерживают JOINS. Они разрабатывались для других моделей где отклик важен а JOIN не нужен. NoSQL системы не умеют делать эффективное индексирование не-ключевых полей. Фактически если вы хотите индекс - вам производитель NoSQL нагло предложит просто создать реплику всей коллекции данных только сделав искомые поля ключевыми. Как поддержать реплику и сколько ресурсов это будет стоить - отдельный вопрос. Возможно в некотором гипотетическом сценарии поддержка хорошо индексированной NOSQL системы будет стоить дороже чем реляционной.

Вот и думайте. NoSQL в ERP - это авантюра.

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

У Java из коробки нет проблем с поддержкой национальных кодовых страниц. Все строки - поддерживают диапазон Unicode. Проблема может быть у Visual Studio Code и у ваших исходников.