Правильное использование модели с разбивкой на типы

StalkerClasses

Новичок
Есть одна таблица.
В ней по столбцу type разбивается содержимое на 4 типа.

- завуч
- учитель
- ученик
- отчисленный ученик.

Как правильно описывать и использовать модель для данной таблицы?
 

WMix

герр M:)ller
Партнер клуба
PHP:
class Table{
  const TYPE_LEAD = 'завуч';
  const TYPE_TEACHER = 'учитель';
  const TYPE_APPRENTICE = 'ученик';
  const TYPE_EXCLUDED_APPRENTICE = 'отчисленный ученик';

  private $type;

  public function types(){
    return [
      self::TYPE_LEAD,
      self::TYPE_TEACHER,
      self::TYPE_APPRENTICE,
      self::TYPE_EXCLUDED_APPRENTICE
    ];
  }
  public function validateType($type){
    return in_array($type, $this->types());
  }
}
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Никак. Модель не имеет отношения к таблице. Нужно понять, какая предметная область у тебя, в ней описать модель, а потом привязать это к хранению данных модели в таблице (или нескольких).
Неизвестно даже, в одной ли модели находятся ученики с учителями (может да, если это таблица учета случаев харрасмента, может нет, если это оценки и ведомость по зарплате).
 

StalkerClasses

Новичок
PHP:
class Table{
  const TYPE_LEAD = 'завуч';
  const TYPE_TEACHER = 'учитель';
  const TYPE_APPRENTICE = 'ученик';
  const TYPE_EXCLUDED_APPRENTICE = 'отчисленный ученик';

  private $type;

  public function types(){
    return [
      self::TYPE_LEAD,
      self::TYPE_TEACHER,
      self::TYPE_APPRENTICE,
      self::TYPE_EXCLUDED_APPRENTICE
    ];
  }
  public function validateType($type){
    return in_array($type, $this->types());
  }
}
Не совсем пойму - что это дает?

Привел наверное не очень удачный пример.
Есть таблица - каталог PDF - в ней хранится 4 типа записей (корень, портфель, папка, PDF-документ) - в зависимости от того какой это тип выводится различное отображение на сайте (причем последний тип PDF-документ не может содержать дочерних элементов).

Как мне например выбрать только папки? Либо PDF-документы. То что везде ставить в условие например type=4 или type='pdf' это понимаю, но как это сделать более правильно?

v3.png

Разбивать такую задачу на несколько таблиц не вижу смысла.
 

StalkerClasses

Новичок
Разбить на 4 таблицы такой пример - очень сложно. Нужно делать очень много проверок. А здесь всего одна - на предмет того, что PDF-не может содержать дочек.
Использовать полиформизм - совершенно не вижу перспективным в таких случаях.
 

ivanov77

Новичок
Как мне например выбрать только папки? Либо PDF-документы. То что везде ставить в условие например type=4 или type='pdf' это понимаю, но как это сделать более правильно?
Чтобы не писать type=4 или type='pdf' подсказали выше про использование констант
Для выборки объектов можешь использовать репозиторий, просто класс через который все эти выборки осуществлять. Полиморфизм тебе может пригодится чтобы работать с коллекциями конкретных объектов, например массив объектов Teacher
Организовать их можно так:
- базовый класс Table как выше, только type не приватный
- А конкретный так:
PHP:
class Teacher extends Table
{
protected $type = self::TYPE_TEACHER;
}
 

WMix

герр M:)ller
Партнер клуба
Не совсем пойму - что это дает?

Привел наверное не очень удачный пример.
Есть таблица - каталог PDF - в ней хранится 4 типа записей (корень, портфель, папка, PDF-документ) - в зависимости от того какой это тип выводится различное отображение на сайте (причем последний тип PDF-документ не может содержать дочерних элементов).

Как мне например выбрать только папки? Либо PDF-документы. То что везде ставить в условие например type=4 или type='pdf' это понимаю, но как это сделать более правильно?

Посмотреть вложение 1278

Разбивать такую задачу на несколько таблиц не вижу смысла.
для начала опиши как я описал, далее спроси что-нибудь новое. я кроме "тип" ничего нового не услышал. как его записать и проверять я показал раньше. кроме слова "тип" и намек на "дерево" есть еще знания модели?
 

StalkerClasses

Новичок
Если на примере Yii то в идеале бы хотелось получить что то вроде
-> getFindAllPortfel
-> getFindAllDirectory
-> getFindAllPdf

-> getFindPkPdf
-> getCountPdf
и т.д.
 

WMix

герр M:)ller
Партнер клуба
PHP:
class DocumentType{
  // см пример выше
  // .const ...
  private $type;
  // ...
  /** @return bool */
  public function is($type){
    return $this->type == $type;
  }
}

class Document{
  /** @var DocumentType */
  private $type;
  /** @var Document */
  private $parentDocument;
  /** @return bool */
  public function typeOf($type){
    return $type->is($type);
  }
}

class Documents{
  /** @var Document[] */
  private $documents = [];
  /** @return Document[] */
  public function getFindAllPortfel(){
    $out =  [];
    foreach( $this->documents as $document){
      if($document->typeOf(DocumentType::Portfel) ){
        $out[] = $document;
      }
    }
    return $out;
  }
  //...
}
 

StalkerClasses

Новичок
Хотел бы вернуться к данной теме.
По прежднеу стало актуально на примере исполнительной документации.

У меня есть одна таблица - документ:
В ней есть поле doc_type где в ней запись со значением
1 - это материал (бетон № паспорта, арматура - марка арматуры, № паспорта, краска)
2 - это техника (кран, экскаватор, виброплита, опалубка)
3 - это сертификат (скан сертификата, письма,
4 - техническая вставка (журнал общих работ, исполнительная схема, фотоматериал)

В зависимости от того, какой тип документа выбран немного различается набор полей для редактирования.
Мой вопрос в следующем - в любом фреймворке Yii2, Laravel - вы ставите 1 модель = 1 таблица, по этому как правильно организовать управление такими типами записей где одна модель имеет как бы несколько вариантов подмоделей?
 

fixxxer

К.О.
Партнер клуба
Ты все время повторяешь одну и ту же ошибку - начинаешь с полей и таблиц в базе данных.

Начинать надо с моделей в PHP-коде, реализующих бизнес-логику, не задумываясь о том, как и где это будет храниться.
Вот прямо берешь и пишешь class Document {}, безо всяких там extends и прочего, без фреймворка вообще.
А уже потом писать слой персистенции в базе.

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

StalkerClasses

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

Начинать надо с моделей в PHP-коде, реализующих бизнес-логику, не задумываясь о том, как и где это будет храниться.
Вот прямо берешь и пишешь class Document {}, безо всяких там extends и прочего, без фреймворка вообще.
А уже потом писать слой персистенции в базе.

Тут ты конечно заметишь, что фреймворки типа Yii2 или Laravel ставят тебе палки в колеса, но это не повод делать через задницу. Костыли в слое персистенции - это нормально (хотя должно навести на мысль, что надо взять фреймворк получше), костыли в бизнес-логике - это намного хуже.
Понимаю. Но приведу еще пример. Страницы в дереве могут быть "страница", "ссылка", "папка". Но хранить все это можно в 1 талице
Как вот мне описать модель данных типа страница с тремя типами?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Давайте разделим понятия Yii и Active Record. Это было 10 лет назад. Не надо выдумывать никакого "1 модель = 1 таблица", нигде такого не написано.
Первая глава в разделе "Working with databases" назывется "Database Access Objects" - PDO, вторая - "Query Builder", а в разделе Models пишут про модели без связи с базой. В yii много чего не так, но AR есть только если вы сами его захотите.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@StalkerClasses почитай про реализацию бинарных деревьев для файлов в каталогах, и про entity-attribute-value для товаров с разными характеристиками по категориям, это разные типы задач с разными паттернами решений
 

StalkerClasses

Новичок
Мне не всегда подходит EAV. И зачем здесь нужны бинарные деревья?
@StalkerClasses почитай про реализацию бинарных деревьев для файлов в каталогах, и про entity-attribute-value для товаров с разными характеристиками по категориям, это разные типы задач с разными паттернами решений
 

fixxxer

К.О.
Партнер клуба
Давайте разделим понятия Yii и Active Record. Это было 10 лет назад. Не надо выдумывать никакого "1 модель = 1 таблица", нигде такого не написано.
Первая глава в разделе "Working with databases" назывется "Database Access Objects" - PDO, вторая - "Query Builder", а в разделе Models пишут про модели без связи с базой. В yii много чего не так, но AR есть только если вы сами его захотите.
Ну, открыл ссылку на Models. Читаю:

Models represent business data in terms of attributes. Each attribute is like a publicly accessible property of a model.
When the data for a model is received from end users...
$model->attributes = \Yii::$app->request->post('ContactForm');
Спасибо, но нет.
 
Сверху