mayton2019

Он хайпанул знатно. Но у него есть детские болезни. Такие-же которыми болеют всякие stackoveflow и прочие вопросники. Возможность словить эксплоит. И не очень понятная лицензионная чистота кода. Кто проверит и кто програнтирует что код надежен - непонятно. Тут недавно log4j бабахнул как бомба с critical vulnerability. Джависты до сих пор заикаются и крестятся. Пакет для логгирования который был в каждом втором проекте оказался с дыркой. И никто не видел. При том что и исопльзовали его и code-review многократно делали.

И представте себе уровень безответвенности который исходит из генератора шума. Шучу конечно не шума. А такой себе Марковской генерилки шума. Но опять-же спрашивать про это GPT команду бесполезно. Они-же ее просто обучали на каком-то текстовом сете. Вот надо смотреть что было в том сете и как оно проскочило в учебную выборку.

Непонятно что автор хотел сделать. Может так. Я не проверял. Типы и функции может другие надо.

UPDATE my_table SET days = CURRENT_TIME - date;

В подобного рода задчах - стоит цель просто продемонстрировать все что вы знаете про ООП. В данном случае ООП+JS. Поэтому берете любой учебнок по ООП и затаскиваете в ваш гамбургер все-что что там есть. Наследование. Билдер. Декоратор.

Практическая польза от такого кода - нулевая. Потому что справочники размеров бургеров, топпингов и добавок не выделены в отдельные сущности. Тоесть UI не владеет этой информацией и не может корректно наполнить бургер. Или в противном случае UI будет должен каким-то образом (каким?) синхронизироваться с кодом.

Или вы думаете что пользователь в бургерной будет стоять перед терминалов и в Java консоли код набирать?

В реальном бизнес проекте классификатор продуктов может занимать до сотен тысяч позиций. Одних бургеров может быть до 1000 из которых например 300 - в будущих акциях а 400 - удалены с продаж но еще существуют
в справочниках для аналитики. Будут абсолютные дубли по названиям но отличающиеся по цене. Будут товары недоступные любым а только VIP и так далее. Вот такие вот дела.

Поэтому здесь что бургер что кот-собака или человек-обезьяна все едино. Демонстрируйте ООП в вакууме.

Типа можно накатить изменения и также безопасно откатить.

По поводу безопасного отката. Это на 99% зависит от SQL кода который вы напишете. Это никак не связано с фреймворком поддержки миграций. Берите какой угодно фреймворк. Например liquibase или flyway.

И даже в них если во время alter table rename column вы столкнетесь с активными сессиями в БД - то ваша транзакция переименования упадет и вы будете вручную решать ситуацию отката или наката.

Безопасность наката и отката также зависит от грамотности описания ваших чендж-сетов. Бывает так что в 1 чендж-сет запихивают 2 DDL команды и одна из них проходит а вторая не проходит и фреймворк повисает навсегда в клинче. Двигаться назад он не может т.к. Не был применен чендж-сет. И двигаться вперет тоже не может т.к. первая DDL команда уже выполнена и повторо ее вызывает ошибку типа "table/index already exists".

Выводы - грамотность описания чендж-сетов. И все.

Ваш фреймворк phinx выглядит ужасно с точки зрения кода. Как по мне он не делает главной задачи а именно - не является DSL для upgrade/rollback. Он - прибит гвоздями к PHP и следовательно его можно рассматривать только под углом вашего PHP-удобства. Удобен он вам? Используйте.

По разному. Я думаю что разные DBMS (SQlite, Oracle) могут по разному обрабатывать группировку.
Правильный ответ на вопрос - посмотреть execution plan комадой
explain (plan) select ..... group by....;
Наперед угадать какой будет использовал алгоритм - невозможно. Как вы помните
язык SQL - это декларативный язык который декларирует свойства результата а не метод
которым разрабочик хочет что-то сделать.

Oracle например имеет много conditions для исполнения группировки например:
1) Какой оценочный объем выборки? Может ли она быть отсортирована in-memory (sort-area-size) в противном
случая будет external sorting в TEMP tablespace.
2) Есть-ли композитный или простой индекс по полям группировки? В этом случае будет index-scan.
3) Требует ли запрос немедленной выдачи первой пачки (хинт +FIRST_ROWS) или можно подождать
но получить весь объем быстрее. Это тоже влияет на выбор алгоритма.

Это всё эвристики которые влияют на выбор окончательного алгоритма.

И уже к сортированной выборке собственно применяется лямбда которая делает группирующую операцию
AVG, SUM, COUNT ... e.t.c. и выдает строки курсора.

Алгоритмы и структуры данных тесно связаны с зубо-дробительными бенчмарками. Как-то отсортировать терабайтный текстовый файл или найти два одинаковых числа в файле из чисел тоже большого размера.
Иногда такие задачи задают на собеседованиях Google и Microsoft.

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

В структурах данных важно также оценивать память "на глазок".

В этом смысла кодер С++ имеет много преимуществ т.к. он видит и понимает как распределяется память
в узле бинарного дерева например (два указателя по 64 бита + какой-то размер для ключа который тоже
можно посчитать). Какой аллокатор брать? Встроенный в язык new или нужно делать собственный.
Такой расчет важен для оценки например - применима ли структура данных вообще?
Какой толк от дерева если оно не влезет в оперативную память? А падение памяти в swap - тут-же замедляет
алгоритм в разы.

JS и Python не предоставляют тонкого контроля над памятью. У них своя модель построенная для комфорта
самого процесса разработки а вовсе не для струткуры данных.

Давайте порассуждаем что такое вообще "поворот дерева". Это - метафора. Это изменение двух потомков двух узлов a и b. По сути это функция transform:
void transform(Node *a, Node *b) {....}
при этом (a,b) - состоят в отношении relatives. Родственники.

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

В рамках импорто-замещения РФ скоро откажется от Windows.
Тогда специалисты по Linux будут восстребованы везде.

Вот главный мотиватор. Хочешь иметь работу завтра - изучай Линуха сегодня.

По линкам из википедии можно начать читать https://en.wikipedia.org/wiki/Blockchain#References

Прошу прощения за внезапный UP.

Но мне задали вопрос про Forth. Я увлекся и тут меня (Остапа) понесло.
Вобщем я начал читать и листать всякую инфу по форту. Первое впечатление - полный бардак
в стандартах. Нет никакого общего понимания что такое вообще язык Форт. По крайней
мере я для себя понял что форт - это просто набор слов (words) каждое из которых либо число
либо слово которое вызывает вычисления. Больше реально ничего не регламентировано.
И я так понимаю что Форт-еров это вообще не парит. Они такие себе либеральные оптимисты.
Судя по конференциям средний возраст Форт-иста - далеко за 70 лет. Дедушки с бородами...

По поводу компиллятора и транслятора. Ничего пока непонятно. Целевая платформа
- не всегда x86 а всякое редкое железо. И тренироваться могу пока на GForth который
кое-как работает но не хватает слов. И YForth который крашится в segfault сразу
на моем Linux x64. Остальные я пока не пробовал.

Сам внешний вид кода у меня вызвает немой восторг как когда-то вызывал Common-Lisp.
Это пожалуй редкое чувство я не испытывал давно. И при всем при этом я не нашел
совершенно никакого практического применнеия. Так. Просто забавная мозговая идея
которую приятно думать на сон грядущий.

На главный вопрос автора - и я ответить не могу. Не знаю является или нет. И я не знаю является
ли он вообще ЯЗЫКОМ. МОжет он как Lisp - просто идея. Он просто настолько широк что
определение языка его сужает.

Надеюсь я никого не отвлек своим спичем от важных дел.

Ты правильно тегировал тему с SQL-Injection. Но ее наличие надо доказать.
Например - взять и вставить какой-то код в ячейку и попробовать воспроизвести.
Одних страхов - недостаточно.

Я видел пакет iwatch. Кажется пытался где-то его применить. Он слушает слишком много событий. Там буквально каждый чих в файловую систему будь то просмотр директорий или атрибутов вызывает шквал событий и их надо грамотно буферизировать и фильтровать.

В идеале вы должны поставить свой ФТП-root под версионный контроль. Например под git. И делать чисто технический коммит на каждое событие изменения файла.

Проблема в том что в такой много-пользовательской среде как ФТП трудно выделить атомарную часть изменения чтобы обозвать ее коммитом. Если 2 пользователя одрновременно пишут в 2 файла в ФТП - это нормальное действие с точки зрения файлового сервака. И в этот момент трудно принять решение где-же собсно
был коммит. Мы полюбому будем фиксировать в коммитах недописанные тела файлов. Вот в чем проблемка.

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

Проверьте делает ли ФТП временное расширение для файла во время записи или обновления. Это важно.

Ну если вы занимаетесь застройками по всей стране - то тогда и делайте карту страны. Зачем вам Африка или Антарктида. Товарищ выше верно пишет - что гео-фотки это самые ресусоемкие. И никто их не хранит одной картинкой. Да и GoogleMap тоже использует структуры наподобие QuadTree чтобы просто их отрисовать. И это нормально.

Можно разослать всем письмо о плановых затаскиваниях в домен. Дескыть всем явится с десктопом в час Х в админскую комнату. По плану. По 5 человек в день. А кто не явился - закрыть им доступ к сети по мак-адресу. Прибегут потом.

Обычно такие системы строят не на основе БД а на основе системы сообщений (messageMQ). Это - более современный и рациональный подход. Не бот долбит БД а MQ уведомляет бота о каком-то событии.

Варианты. Можно преобразовать JSON в JSON-Lines (где каждая строчка - это независимый JSON документ представляющий строку таблицы).

Потом загрузить это в spark dataframe

Using Scala version 2.12.15 (OpenJDK 64-Bit Server VM, Java 11.0.17)
Type in expressions to have them evaluated.
Type :help for more information.

scala> val df1 = spark.read.json("/tmp/emp.json")
df1: org.apache.spark.sql.DataFrame = [_corrupt_record: string]

И имея фрейм либо сохранить в CSV либо подключить драйвер JDBC записать прямо в базу.

Еще во фреймворке Pandas есть опции загрузки из JSON. Но я сам не спец в пандасе поэтому
точно как сделать не скажу.

Вот. Еще я помню где-то писал утилиту чтоб произвольные JSON конвертить в JSON-lines.

Короче способов - масса. Беда как обычно в вопрошающем. Что он готов для этого установить
и что выучить.

Те которые на 100Гб можно подарить детям на игрушки. А для больших (несколько терабайт) - моешь посмотреть SMART информацию (как советуют выше).

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