TheRonCronix

Так вот же: '\',
А нужно: '\\',

' -> \'
" -> \"
\ -> \\

Каждый подмодуль имеет свой pom.xml Их можно объединить одним parent pom.xml.

parent pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    <artifactId>jdcs</artifactId>
    ...
    <modules>
       <module>net</module>
        <module>gui</module>
        <module>handler</module>
    </modules>
    ...

В подмодулях можно сослаться на parent и указать зависимости от других подмодулей:

<project ...>
    <artifactId>gui</artifactId>
    ...
    <parent>
        <groupId>com.jdcs</groupId>
        <artifactId>jdcs</artifactId>
        <version>0.0.1</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>com.jdcs.net</groupId>
            <artifactId>net</artifactId>
            <version>${project.version}</version>
        </dependency>
        ....
    </dependencies>

    ...

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

Вы можете попробовать создать заглушки тех функций, которые вызывают проблемы. Если функции в скрипте создаются командой create or replace, то ваша заглушка будет заменена при накате.

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

Примеров очень много. Пожалуйста: https://duckduckgo.com/?q=load+and+traverse+json+i...

Процент от продаж для программиста имеет смысл, если он будет в том числе продавать. Прямо или косвенно. Если сваязи между трудом программиста и продажами вы провести не можете, то платите фикс. Причем связь должа быть существенная, что трудног представить, если рпограммист только программирует, а не занимается звонками, или каким-то еще продвижением. sales = effort * k. Вот этот "k" и есть процент от продаж за его вклад.

Если делать на бекэнде, очевидно, что плюс - это скорость, т.к. операции выполняются в пямяти + не нужно проходить по лишним слоям, чтобы передать данные в БД. Но в таком случае данные могут быть утеряны в случае сбоя сервиса. БД по крайней мере гарантирует, что данные сохранены на диск (хотя тут есть свои но, тем не менее).

Кажется, вам для начала стоит понять, что "ложки нет".
А вообще вот: https://wiki.unrealengine.com/Pick_Up_Physics_Obje...

Можете посмотреть еще conda. Это средство управления пакетами и средами.

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

regexp_substr(col, '(?<=CN=)[^,]+')

1. Выше верно указали, что нужны агрегаты. Агрегаты могут быть частичными. Если count у вас без distinct, то показатель будет аддитивным и проблем с суммированием по агрегатам быть не должно.
2. Раз у вас таблица так растет нужно ее секционировать. Скорее всего по дате.

Можно сопоставить каждому char_id бит в битовом поле, который хранить в chars.
После соединения item и charsItems нужно провести агрегацию с суммированием битовых значений для каждого item. Если у item признак имеется, соответсвующий бит добавляется в сумму, если нет, то не добавляется. К получившемуся результату применить фильтр по битовой маске.
Еще буитовую сумму можно хранить перманентно, чтобы ее проиндексировать.

Ниже только мое мнение.
C++ это язык, занимающий определенную нишу, а именно - это язык промышленной реализации высокопроизводительныз приложений. С++ по задумке должен сочетать в себе скорость Си и удобство различных парадигм языков высокого уровня, в значительной степени ООП. Разрабатывать на нем трудно.
Из этого можно сделать вывод, что сфера, в которой придется работать - это реализация программ для долговременного использования, программ с высокой производительностью и надежностью.
С++ используется в разработке десктоп-приложений, СУБД, бэкэнда, игр, высокопроизводительного ПО. С++, на мой взгляд, это хороший способ реализоваться как программист-практик. "бухгалтерша" и программист на С++ не совместимы.

Может быть имеет смысл посмотреть в сторону масштабируемых СУБД, типа hbase?
Выше верно указали, что партиционирование это по сути и есть разбиение таблицы на несколько, например на помесячной основе.

Не составной ключ как столбец можно назвать просто id, можно имя_таблицы_id. На мой взгляд оба варианта допустимы.
Важно скорее придерживаться одного стандарта, т.к. это благоприятно скажется при разного рода автоматизации.
имя_таблицы_id может быть более выгоден в случае, если у вас есть две разные таблицы, но по смыслу имеющие один и тот же первичный ключ. Т.е. бизнес-смысл у него один. Также в выборках, где в качестве алиасов используются короткие одно-двух буквенные последовательности и выбирабтся несколько id, то может быть трудно понять какой id из какой таблицы. В целом я склоняюсь к варианту с осмысленными названиями, т.к. осмысленное название лучше, чем не осмысленное, т.е. я бы выбрал имя_таблицы_id.
Сам же первичный ключ как констрейнт имеет смысл называть: pk_имя_таблицы