ininth

не понятно, какой влияние оказывает третья таблица на вторую

Напрямую никакого. У вас INNER JOIN `wp_company_rates` и `wp_term_relationships`, поэтому естественно, что в финальную выборку попадут только те строки, которые совмещаются по условию JOIN'a. Если после RIGHT JOIN вы получили в объединённой строке `wp_company_rates`.`post_id` равное NULL, то, естественно, в INNER JOIN эта строка не войдёт.

Локально откатить хэд и сделать force push:
git push -f

Есть еще 4 вариант, одна таблица с общими данными, и вторая таблица с доп данными id, payment_id, param_name, param_value, со связью один ко многим. То есть к каждому платежу может быть добавлено произвольное количество доп параметров.

Плюс в отличие от json в том, что можно делать выборки по этим параметрам

Могу посоветовать две очень годные книги для тех, кто действительно хочет разбираться в БД:
- Системы баз данных. Полный курс, Гектор Гарсиа-Мол...,
- MySQL по максимуму, Шварц Бэрон, Зайцев Петр, Ткач....
Книги непростые и начинать нужно не с них.
Начинать нужно с любой книжки по синтаксису и основ, типа нормальных форм.
Переходить к данным книгам можно, когда вы освоите синтаксис, разберетесь с устройством всех типов данных и сами сможете сконструировать примеры:
- таблицы, находящейся в 1НФ, но не в 2НФ,
- таблицы, находящейся в 2НФ, но не в 3НФ,
- таблицы, находящейся в 3НФ, но не в НФБК,
- таблицы, находящейся в НФБК, но не в 4НФ,
- таблицы, находящейся в 4НФ, но не в 5НФ,
- таблицы, находящейся в 5НФ, но не в ДКНФ,
- таблицы, находящейся в ДКНФ, но не в 6НФ.

Пул реквест - это когда в каком-нибудь репозитории у вас нет прав на внесение изменений. Чтобы внести какие-нибудь свои изменения нужно сделать этот самый пул реквест - предложить свои изменения тому, у кого эти права есть, он посмотрит и либо смержит (сольет) эти изменения в ту ветку, куда вы делаете пул реквест, либо в жопу вас пошлет.

Enterprise разработка - это разработка, направленная на решение проблем бизнеса. В отличии от разработки для решения проблем конечных пользователей.

На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
* устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
* сложная и непостоянная бизнес-логика, давление на нее из множества источников
* результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
* слабо заметный вклад конкретного программиста, проистекает из сложности ПО

Требования к программисту... ну я бы сказал, усидчивость, вдумчивость, исполнительность... хм, а что, в каких-то других областях другие требования к программистам? Хотя, конечно, в противоположность, можно назвать способ разработки "быстро-быстро и в продакшн". Но, к слову, такие ситуации могут и в энтерпрайзе возникнуть.

По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.