Как правильно наследовать и соединить классы?

Понял. А что делать, если у меня в запросе на получение счета используется INNER JOIN в запросе? И например меня (или не меня) торкнуло изменить поле в какой-либо таблице?

Вообще - менять имена в таблицах, из которых собираются объекты - так себе затея. Вам в любом случае нужно будет переписать код всех классов для этих таблиц.

И да правильная настройка foreign key прям помогает не делать глупости )

Но если таки имена полей таблиц/таблицы переименованы приложение просто сломается.

public function getInvoice($id){
  $query = "SELECT * FROM `".$this->db_table_invoice."` AS t1 JOIN `".$this->db_table_user."` AS t2 ON t1.`user_id` = t2.`id` JOIN `".$this->db_table_org."` AS t3 ON t1.`org_id` = t23.`id` WHERE t1.`id` = ?";
  $stmt = $this->db->prepare($query);
  $stmt->execute(array($id));
  return $stmt->fetch();
}

Вот метод получения данных о счете. Видите, в нем связь таблиц. И этот запрос НЕЛЬЗЯ сделать не зная структуры БД.

Проблему которую вы описывает с успехом решают Eloquent и Doctrine. Эти инструменты достаточно сложны, чтобы не писать их с нуля ))

По сути единственный способ - это отдельно описать зависимости одних моделей от других. И собирать запросы с учетом этих зависимостей. Но даже если вы это сделаете - это не даст 100% защиты от дурака.

Александр, понял, спасибо!

Макс Васильев, в очень грубом приближении это будет выглядеть так:

1. Все модели нужно научить отдавать свои таблицы и поля;
2. Нужно запилить класс управления зависимостями - он же конструктор запросов. Преобразует определенный тип зависимости в определенный кусок запроса;
3. Когда будут готовы п.1 и п.2 нужно описать зависимости в классе Invoice, которые будут автоматически подтягивать имена полей таблиц и сами таблицы, если нужны;

Логика всего этого дела не тривиальна от слова совсем, и в комментариях на тостере её не описать. И то, это решение позволит локализовать проблему, но не избавиться от неё полностью. Классы, работающие с таблицами нужно будет изменять вместе с изменениями таблиц.

Александр, Мощно! Большое спасибо за объяснение)

Спасибо. Я в сообщении выше ответил про MYSQL запрос. Можешь глянуть?

Макс Васильев, ну что я могу тут сказать... Конечно может быть и придумали уже методики, как такого избежать. Но я на своей памяти такого не припомню.
Пэтому и надо относится к проэктировке проекта очень тчательно. Не просто так же говорят, что кодинг - это всего-лишь 10-30% от всего времени проекта. А если бы было так просто раааз и поменял архитектуру, то конечно все было бы легко))
Могу разве что посоветовать делать качественную документацию, чтобы при каких-либо изменениях можно было почитать, что надо изменить с этими изменениями. И я молчу уже о помощи "новым" разрабам. Эта касается так же и тебя, ибо ты через пол года- год забудешь об этом в первую очередь))

Therapyx, спасибо за объяснение. Я думал что я сильные сделал зависимости от БД. В общем разберусь как следует.

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