mayton2019

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

Но когда будешь изучать команды типа fdisk, parted, mkfs то лучше конечно ценную ОС отключить вообще.

Мне кажется ты смешал в кучу две разные технилогии. Bind variables. Это вставка специальных переменных
в тело DML/DQL запроса вместо значений. Это поддерживается на уровне БД. Это важно для БД потому что идет компилляция текста запроса для повторного его исполнения много раз.

И интерполяция строк. Это просто тупо генерация новой строки. К базам не имеет отношения.
Это поддерживается Python например. Строковой интепорляцией ты можешь сделать первую часть запроса.

Сделать нечто вроде
"UPDATE emp SET ename=? WHERE empid=?"
(кстати в синтаксисе у тебя скорее всего была ошибка)

И потом уже вместо вопросительных знаков добавить bind variables.

Из быстрых советов - проверь что Subdivision_ID проиндексирован.

Наверное имеется в виду это. Вот тут переменная i может быть использовани и после цикла.

int i = 0;
while(i<10) {
 doSomething(businessObj[i]);
 j++;
}
i = 0;

Кострукция for - замыкает область видимости и переменную не видно. Хотя в наше
время код больше тяготеет к более function-style кодингу когда итератор
или параметр цикла вообще не нужен. У нас есть некий foreach и он делает все что надо.

По поводу NTFS/ExFat - для самих приложений ничего особо не меняется. Ну я не знаю приложений
которые-бы как-то были завязаны на эти свойства. Это может для админов безопасности там важно.

Хорошая ли это идея. Тут надо рассмотреть опции. Я часто смотрю кино с портативного диска. Иногда
кошка может прыгнуть на системник. Пошатать что-то и диск может отмонтироваться. Бывает. Но с кино ничего не происходит. Доступ read-only. Кошку выгнал. Диск подключил и смотрю себе дальше. А что с приложениями?
Дело в том что когда программист пишет код с I/O - он считает что диск всегда доступен. Совсем всегда.
И ситуация когда диск вдруг отьехал - катастрофична. Может ли ОС работать когда диск c: отключился?
Скорее нет чем да. Вобщем отсутсвие диска - катастрофа для приложений. И особенно для приложений
которые в этот момент что-то сохраняли на диск - это отложенная катастрофа. Вы последствия
почувстуете после следующего запуска. В противоположность - сеть. Она изначально проектируется
как опционально-доступная и все программы при обработке сетевых ошибок используют ретрай-логику.
Тоесть просто ждут и повторяют операции. Толерантны к сбоям.

В противоположность I/O ошибки записи - нихрена не толерантны. Это сразу выпадение программы в ОС
с сообщением "я не шмогла!". Это не относится ко всем программам а просто к большинству. К 80%
программ если хотите.

Вобщем все зависит от класса I/O операций ваших приложений. Если это как просмотр фильмов - то можно.
Если это КАК postgres с журналом - то есть риск получить полностью поломанную файловую системую и
неработающие приложения. Как работают ваши секвенсоры и плагины? Часто они делают запись?
Насколько запись критична для работы "здесь и сейчас"? Что будет если их структуры данных
для записи оказались записаны "наполовину"? Вот это вопросы на которые вы должны ответить.

Если хотите более надежные внешние диски - подключайте SATA-диск через внутренний карман на корпусе.

Капец ты продуктивный кодер. Это надо-же столько много букв написать.
Никто разбираться скорее всего не будет.

Но я-бы предложил тебе стратегию как в будущем не залетать с такой бедой.
Тебе надо стартовать новый проект который точно работает (hello world) на ботах.
И потихоньку начинай переносить свой функционал в новый проект. И делай запуск и тестируй.
И делай каждый раз git commit.

Наступит момент когда он упадет - это и будет проблемное добавление. Дальше - откатывайся взад
и разбирайся какое изменение привнесло дефект. Процесс можно ускорить если добавлять дихотомически.
Сначала +50%. Упало. Удалил 25%. Едет. И так далее.