mayton2019

В конце 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 нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

1. Java (JDK/JRE) не содержит в себе драйверов доступа к БД вообще. В ней определен только базовый
интерфейс java.sql.* и существует некий стандарт на то как драйверы должны работать. Например когда мы делаем ResultSet::close, или Statement::close, драйвер может ничего и не делать в этот момент. Все зависит от того
как производитель (Oracle, MSSQL) реализовал под капотом работу драйвера. Поэтому как работает внутри драйвер это - тайна.

2. Обычно если в приложении тебе часто и много нужно создавать объектов Connection, то используют пулы коннектов (Hikari Connection pool, DBCP, C3PO). Почитай в этом направлении. Пулы экономят сессионные
объекты на стороне БД и создают новые коннекты быстрее за счет переиспользования сущесвтующих коннектов.
В обычном (прямом режиме) работы с БД процесс установки соединения может занимать несколько секунд.
Это может быть запредельно медленно для некоторых алгоритмов.

3. В сложных ent. приложениях используются фреймворки типа Spring которые декларируют зависимости одник
компонент от других и также обеспечивают ленивую инициализацию и работу синглтона. Всем новичкам
нужно знать что такое синглтон и уметь им пользоваться. И лучше уметь это сначала без фреймворка
чтобы понимать уже как это делает фреймворк.

Как в такой схеме реализуются связи?

Обычно в игровой логике избегают использования SQL систем из-за unpredictable времени
отклика. Тоесть если в финансовой системе вы можете подождать секунд 5 или минутку
обработки транзакций то внутри игры игрок быстро заскучает и выйдет из игры.

Поэтому в играх обычно используют NoSQL системы (наподобие RocksDb, Cassandra)
но в них доступ идет только по ключу. Key-Value и никакие JOINS не работают.

Если сильно хотят подружить игру с платежной системой - то заводят отдельный сервер
для денежных операций (он может быть под SQL БД) но события между игрой и платежной
системой гоняют по очередям (MQ) чтоб не было нигде блокирующих операций.

Поэтому твой вопрос по сути - это квест. Типа пойдешь на право - перформанс потреяшь
или пойдешь налево - вырастет денормализация и аномалии в БД.

В мире существует огромное количество баз с фильмами где лежит мета-дата.
Это сведенья об актерах, аннотоции, рецензии и технические подробности релиза и рейтинги прокатов.
Вот когда-то я качал отсюда например https://developer.imdb.com/non-commercial-datasets/
Поищи в kaggle и google базах по машинному обучению. Там тоже есть метадата. Но вся она
не стандартизирована. Разрозненна. И тебе предстоит работа дата-инженера в попытках
хотя-бы привести это все к общему знаменателю. Справочники везде будут разные
и модель нормализации вообще бывает разная. Кроме того эти базы ведут конкретные
люди, которые ведут их в системе ценностей запада и США и поэтому их взгляд на
содержимое будет вполне себе понятным. Тоесть объективной базы или объективной
аннотации без купюр или без повестки будет найти почти невозможно.

Сами фильмы - это платная услуга и скорее всего такого ты не найдешь нигде.
А если где-то и найдешь - это обычно быстро закрывают. Может у соседа по дому
есть росшаренная папка Windows. Как вариант.

Если просто скроллить ленту rutor то можно найти неплохие релизы новых фильмов
но как по мне - там больше шир-потреб или что-то очень старое и ненужное. Рутор
неплох но очень мало чего я для себя там находил. Ну там Comedy Club можно было найти.

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