mayton2019

Соревнования и Олимпиады помогают для поступления в университет. Но они они не способствуют поступлению на работу в большую корпорацию. Скорее наоборот. Олимпиадник - опасен и создает проблемы для проектов которые работают по 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 и у ваших исходников.

В SQL обычно одинарные кавычки используются для строковых литералов.

DELETE from books WHERE us_books = 'слово' .....

Двойные там для других задач. Например для приведения идентификаторов к CASE-sensitive виду.- Типа "MyTable"

Зависит от утилиты. Если она считывает информацию со STDIN - то ей можно втолкнуть ответ через pipeline

$ yes | your-utility ......

или еще через echo можно попробовать.

Непонятно целеполагание. Автор хочет что-то сделать зачем?

Непонятно зачем тегать ООП ? В наше время сферического ООП не существует. Есть ООП в реализации конкретных языков. И оно очень сильно отличается. Например в некоторых языках все объекты - суть прототипы. В других не так.

Добавил версию с тегами js, ruby. И давайте обсуждать вот в разрезе языков. А то запутаемся совсем.

Не приживаются они для СУБД.

IDE-шки. Вот такие дела. Редко когда тебе нужно открывать в Oracle PLSQL Developer десяток PLSQL пакетов.

Так вообще вместо IDE используют IDE основного языка программирования. В нем и пишут текст. Тем более что 99% он инкапсулирован в ORM.

Попробуй на сайте JetBrains скачать что-то. И еще DBeaver был. Там удобно каталоги баз вести.

Игнорируй младшие коэффициенты - вот и будет сжатие. Так оно и работает. Честно-честно.

Почти все современные редакторы умеют работать с векторной графикой. Если есть рисование кистью сплайнов или просто геометрических фигур - то считай уже векторный. В противоположность и Adobe Illustrator умеет фотки в себя затягивать. Тоесть деление это сугубо условное. Как сельхоз-продукция и пром-товары. Я-бы предложил просто найти в википедии и почитать как оно классифицировано там.

Там ничего ценного нет. Мак адреса указывают на производителя оборудования.
Сетки и DNS могут просто показать кто твой провайдер.

Остальная инфа достаточно обезличенная. Какие шаги предпринять? :))) Ну можешь
сходить в супермаркет и купить бейсбольную биту. Что тут еще сказать?

Сильно больших людей обидел?