My1Name

Вероятнее всего в том, что нужно jdbc-драйвер для Oracle использовать, а не для MS SQL Server.

Смотрим здесь. Получаем для обычного INT 4 байта на одно число, для BIGINT 8 байт.
200 * 4 * 10'000'000 = 8'000'000'000 или 8Gb.
200 * 8 * 10'000'000 = 16'000'000'000 или 16Gb.
По нынешним меркам сущие пустяки.
Хранить, конечно же, нужно в нормальной форме, иначе суммирование придётся делать в приложении.

1. Адреса должны быть относительными всегда
2. Место хранения следует задавать переменной

В конце 20-го века, когда Эдгар Кодд развивал свою реляционную теорию было очень
модно все данные нормализовывать для хранения их в БД. Это соотвествовало экономии
ресурсов (диски мерялись килобайтами и мегабайтами) и нормализация хорошо ложилась на
техно-стек. Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом.

В 2000х развитие веб и XML(XHTML/SGML, XSLT, XPath) дало толчок новым видам
хранения информации в виде markup languages. Появляются технологии семанического веба.
Мечтатели-теоретики создают RDF, OWL. Базы данных пытаются успеть втянуть в себя новые типы.
Oracle начинает поддерживать XML+Schema как тип данных в таблице. Браузер начинает
поддерживаеть трансформацию XML и обогащение его стилями. XML - моден. Его внедряют
везде где можно и где не нужно. Даже в конфигах Apache Http и в сборщике Maven.

Параллельно Дуглас Крокфорд работает над Java Scrip Obj Notation и создает лайтовый язык
для описания объектов и документов. Они - конкурируют с XML но JSON практически побеждает
в вебе, полностью захватывая веб протоколы (Ajax, WebSockets, e.t.c). И интеракцию с сервером.
JSON становится более популярный для REST. Многие БД тоже начинают поддерживать JSON.
Postgres даже делает бинарный JSON и добавляет спец-индексы для быстрого поиска атрибутов.
Узко-специализированные системы такие как Mongo изначально заточены на храннение JSON
информации.

BigData плавно проростает в 2007 (кажется) и где-то в 2014 (или позже) году фреймворк Spark начинает поддерживать DataFrames + Structured Types которые по сути являются зеркалом JSON. Фреймворк
позволяет грузить в бигдату JSON-lines датасеты, автоматически выводя схему.

Это - финал. Я считаю что после такой конвергенции в бигдату JSON получил путевку везде где только можно.
Сегодня вы можете без стыда использовать JSON везде в любых уровнях стека (даже в Redis) если
у вас хватает памяти и вы уже порешали вопросы бизнес-согласованности данных и умеете эти
данные инвалидировать и обновлять.

Если поискать анти-паттерны применения JSON в базах данных - то я-бы предложил такую метрику.
Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает
сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

console.log(typeof settings);
console.log(typeof flag);

Почти уверен что там будет строка в одном или обоих случаях. Поэтому проверка и не работает.

1. Нет! Строки неизменяемые. Конкатенация строк - это операция по созданию нового объекта с новой ссылкой.

2. String это базовый тип для Java, а StringBuilder добавили только в 5-ю версию. Апгрейд существующего класса не стали делать по соображениям совместимости и чтобы не поломать String Pool, который для билдера не имеет смысла.

3. Потому что это разные типы!!! Хотите, чтобы String и StringBuilder сравнивались по содержимому? Делайте дочерние классы, в которых переопределяйте сравнение, а потом экземпляры своих классов присвойте переменным типов String и StringBuilder - магия, сравнение заработало!

Почему нужно было помимо класса String создавать дополнительные классы по типу StringBuilder?

Потому, что String - иммутабельный класс. Чтобы конструировать строки как раз добавлены StringBuffer (в версии 1.0) и StringBuilder (в 1.5).

В данном примере строка s спокойно изменяется путем конкатенации, что аналогично sb.append

В итоге у вас каждый раз создается новый объект. Не всегда это бывает уместно.

2. Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Потому, что это нарушает принцип единой ответственности. Так же можно заметить, что мысль не стоит на месте и со временем появляются новые методы для конструирования строк.

3. Почему s.equals(sb) равно false, если мы сравниваем только значения, а не ссылки

Потому, что вы сравниваете разные объекты. StringBuilder - это не String.

Недетерминировано работает. Без синхронизации между потоками у нас нет гарантий последовательность и видимости, так что даже без одновременного вызова мутирующих методов есть шанс сломать инвариант.

Одно на все приложение.