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

Question

[Эдуард Баженов]

Здравствуйте! При изучении ООП возник такой вопрос. Например, есть изделия 4-х видов, есть несколько общих свойств, остальные специфичные. В php я создам родительский класс с общими свойствами и методами и 4 дочерних со специфичными. А в бд мне нужно просто создать 4 таблицы для каждого вида? Или есть другой способ?

Comments

[Павел Лебедев]

Mongo DB

[Дмитрий]

И не одной отметки об решении

Answer 1

[ThunderCat]

А в бд мне нужно просто создать 4 таблицы для каждого вида? Или есть другой способ?

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

Comments

[Эдуард Баженов]

Ну вот смотрите: в моем случае 4 вида рольштор: рулонные, зебра, вертикальные и горизонтальные. У них общие свойства: ширина, высота, управление (левое или правое), тип крепления. Далее у рулонных есть типы конструкции (mini, uni1, uni2 и тд), для которых нужны разные составные части (разные типы валов, где то нужен короб, где то нет). Не могли бы вы вкратце объяснить как это реализовать?

[ThunderCat]

EAV

Answer 2

[Северное Сияние]

Да, 4 таблицы. Но это у вас должна быть такая бизнес-логика, которая это оправдывает. Уверены что оно вам действительно требуется?

В 90% случаев достаточно одной модели и у нее разные свойства.

Например, пользователь - у него есть свойство пол. Или набор свойств, лежащих в отдельной таблице.

То, что вы описываете - это наследование от интерфейса Гуманоид нескольких моделей, допустим, модели Человека и Инопланетянина. Там будет 2 таблицы и две разные модели, имплементирующие интерфейс/наследующие абстрактный класс Гуманоид. Но будет совершенно разная реализация методов.

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

Или взять какой-нибудь портал типа Авто-ру. Я не думаю, что объекты объявлений имеют разные типы (легковое//грузовые машины/спецтехника) - там все это также представлено наверняка в виде свойств одного объекта Объявление.

Comments

[Эдуард Баженов]

Ну вот смотрите: в моем случае 4 вида рольштор: рулонные, зебра, вертикальные и горизонтальные. У них общие свойства: ширина, высота, управление (левое или правое), тип крепления. Далее у рулонных есть типы конструкции (mini, uni1, uni2 и тд), для которых нужны разные составные части (разные типы валов, где то нужен короб, где то нет). Не могли бы вы вкратце объяснить как это реализовать?

[Северное Сияние]

Эдуард Баженов, я думаю, надо посмотреть, как это делается в интернет-магазинах. Предполагаю, что там делаются списки свойств, после чего создается тип товара и перечисляются свойства, которые должны присутствовать в этом товаре. При создании самого товара оператор указывает необходимые свойства. Поиск рулит. И еще.

Наследование моделей даст гораздо больше подводных камней.

Answer 3

[Дмитрий]

Как вариант хранить все в одной таблице, просто дополнительные свойства хранить в дополнительном поле. Можно например хранить сериализацию массива этих свойств
Создать класс, где в конструкторе будет происходить сериализация массива и заполнение свойств из него.

class Model extends BaseModel
{
    private $id;

    private $data;

    private $other;

    public function __construct()
    {
        foreach (unserialize($this->other as $key => $value) {
            $this->{$key} = $value;
    }
}

Ну и делать fetch object передавая имя модели
Способ наркоманский, писал с телефона, могут быть косяки, это пример реализации

Answer 4

[Adamos]

Таблица products (изделия):
id - title - article - прочие общие поля, которые будут у любого изделия

Таблица properties (типы свойств):
id - title - прочие поля, нужные для обработки (например, это может быть json-поле, в котором прописаны нюансы отображения. Поиска по нему все равно никогда не потребуется)

Таблица product_properties (свойства изделий):
id - product_id - property_id - property_value (строковое значение достаточной длины, чтобы его хватило на что угодно)

Если постоянно нужен поиск по значениям свойств и список возможных значений того или иного свойства - можно ввести еще таблицу property_values:
id - property_id - value c уникальным индексом по двум полям
и в таблице product_properties вместо property_id и property_value задавать property_value_id