Что такое «несоответствие импеданса» в программировании?

final class ProductType {
 
    public function __construct(
        public string $Uuid,
        public string $Name,
        ProductCollection $Products) {}
 
}

Теперь ProductType содержит ProductCollection, который в конечном итоге будет содержать массив экземпляров Product. Это создает двунаправленную реляционную ссылку — ProductType содержит все его продукты, а каждый Product содержит свой тип продукта.

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

Учитывая иерархию

Описанная выше модель создает иерархию в кодовой базе: Product находится ниже ProductType. Это звучит логично и соответствует нашим ожиданиям от реального мира.

Реляционные базы данных не признают иерархии. Поскольку все отношения эквивалентны, реляционные базы данных по своей сути имеют «плоскую» структуру. Мы видели это ранее при получении данных с помощью JOIN.

Отсутствие иерархии в SQL означает, что все таблицы имеют одинаковый приоритет по отношению друг к другу. Результатом этого является то, что вы можете легко получить доступ к свойствам записей, глубоко вложенных в иерархию ваших логических объектов. Кроме того, снижается риск циклических зависимостей.

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

Объектно-ориентированное программирование основано на объединении простых объектов в более сложные. В реляционных моделях нет понятия композиции или «простого» и «сложного» — любая запись может ссылаться на любую другую.

Наследование

Еще одна исключительная функция ООП — наследование. Обычно класс расширяет другой, добавляя дополнительные поведения. Реляционные базы данных не могут воспроизвести это. Таблица не может «расширять» другую таблицу.

Кодовая база, использующая наследование, столкнется с трудностями, когда дочерние объекты сохраняются или гидратируются через реляционную базу данных. В базе данных вам обычно понадобятся две таблицы. Один хранит свойства базового объекта (который вы расширяете), а другой обрабатывает свойства дочернего объекта.

Затем код сопоставления перебирает все свойства объекта. Свойства, производные от расширенного класса, будут вставлены в первый код. Те, которые непосредственно определены для дочернего элемента, окажутся во второй таблице.

Аналогичная система требуется при отображении обратно в кодовую базу из базы данных. SQL JOIN можно использовать для получения всех записей, соответствующих базовому (расширенному) классу, включая дочерние свойства. Те записи, которые содержат дочерние свойства, затем будут сопоставлены с экземплярами дочернего класса.

CREATE TABLE parent(Id INTEGER PRIMARY KEY, A INTEGER);
CREATE TABLE child(Id INTEGER PRIMARY KEY, B INTEGER, ParentId INTEGER);

class Parent {
    public function __construct(int $A) {}
}
 
final class Child extends Parent {
    public function __construct(int $A, int $B) {}
}
 
// Get records
// SELECT * FROM parent INNER JOIN child ON child.ParentId = parent.Id;
$objs = [];
foreach ($records as $record) {
    if (isset($record["B"])) {
        $objs[] = new Child($record["A"], $record["B"]);
    }
    else $objs[] = new Parent($record["A"]);
}

CREATE TABLE products(Price INTEGER, TaxRate INTEGER);

final class Product {
 
    public function __construct(
        protected int $Price,
        protected int $TaxRate) {}
 
    public function getTotalPrice() : int {
        return ($this -> Price * ($this -> TaxRate / 100));
    }
}