常連

インフルエンサー

回答者

ベストアンサー

拍手喝采

自己紹介

Laravel6を使用しています。
defaultのmigrationファイルでtimestamps()メソッドがあり、こちらでcreated_atとupdate_atカラムを作成していました。
そして、そこではnullable()をメソッドチェーンで繋いでおり、created_atとupdate_atがnullを許容するカラムとして作成しているようでした。

レコードの作成日時や更新日時はnullを許可せず必須であるべきだと個人的には思うのですが、nullを許可するメリットは何が考えられるのでしょうか。
なぜLaravelはnullを許容するのをdefaultとしているのでしょうか。
created_atとupdated_atはnullを許可するのが一般的なのでしょうか。

ご存じな方ご教示いただけますと幸いです。

ちなみに「2038年問題」を考慮し、私自体はtimestamps()メソッドを使用せず、datetime型でcreated_atとupdated_atを作成しています。

null許可する理由がtimestamp型であることに関係あるのであれば、必須化してもいいかなと考えています。

created_at, update_atをnull許可する理由やメリットについて

Laravelの実践的な練習として[ベストプラクティス](https://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md#%E3%83%95%E3%82%A1%E3%83%83%E3%83%88%E3%83%A2%E3%83%87%E3%83%AB%E3%80%81%E3%82%B9%E3%82%AD%E3%83%8B%E3%83%BC%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9)と言われるものを見つけ、そこでは以下の様に記載されていたのですが、いくつか疑問点があり、今回質問させていただきました。

記載されていた内容で、行っていたこととしては、Controllerに記載されていたDBに関するロジックに関しては、Modelに記述しているという認識です。

ただ、それに関して以下の点が不明点です。
> DBに関連するすべてのロジックはEloquentモデルに入れるか (〜省略〜) レポジトリークラスにいれます。

- まず、なぜ下記ではBadに値するのでしょうか？
- また、その場合全てのDB操作をModelで行ってはあまりControllerの意味がなくなってしまうといった点や、Modelが肥大化してしまうのではないでしょうか？

上記を踏まえた上でどの様な判断を行い、Modelにコードの記載を行うことがあるのか、またその判断基準や全てのアクションをModelに記載してしまってはダメだと思うので、どのアクションをModeに記載するのか、共通化したものとして捉えていいのかが質問点となります。

長くなってしまい、あまりうまくまとめることができなかったのですが、以上を踏まえ、ご回答
していただけると幸いです。


以下は記載されていた内容です。

> ##### ファットモデル、スキニーコントローラ
DBに関連するすべてのロジックはEloquentモデルに入れるか、もしクエリビルダもしくは生のSQLクエリを使用する場合はレポジトリークラスに入れます。

> Bad:
```PHP
public function index()
{
    $clients = Client::verified()
        ->with(['orders' => function ($q) {
            $q->where('created_at', '>', Carbon::today()->subWeek());
        }])
        ->get();

    return view('index', ['clients' => $clients]);
}
```
> Good:
```PHP
public function index()
{
    return view('index', ['clients' => $this->client->getWithNewOrders()]);
}

class Client extends Model
{
    public function getWithNewOrders()
    {
        return $this->verified()
            ->with(['orders' => function ($q) {
                $q->where('created_at', '>', Carbon::today()->subWeek());
            }])
            ->get();
    }
}
```

ポジトリークラスに入れるメリットと入れる基準

Laravel5.7, MySQL5.7 で見積書、および請求書を生成、管理するシステムを作成しています。
リレーション周辺の知見をいただきたく質問しました。

Laravel 職人のご意見をお聞かせください。

具体的には、**見積モデルの「見積書発行日」時点での消費税モデルをどうリレーションするのか？自分が採用したアプローチの他にもっと良い方法はないのか？**
という疑問です。

なぜ悩んでいるかを列挙すると、以下の通りです。

- リレーションはできるだけすっきりと書きたい。（可読性のため）
- トリッキーなことはしたくない。（Laravelの作法には従おう）
- 発行日が変更されたとき、正しい消費税率を関連づけたい。できれば発行日が変更されても「よしなに」税率も変更される。
- ビジネスロジックがブラックボックスになりがちだから、SQLのトリガーは使いたくない。

## Model, migration

問題になる部分の関連 Modelは Estimate, Tax で、今のところ、以下のような構造です。

```php
<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateEstimatesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('estimates', function (Blueprint $table) {
            $table->bigIncrements('id')->comment('ID');
            $table->unsignedBigInteger('company_id')->comment('会社ID');
            $table->unsignedBigInteger('client_id')->comment('顧客ID');
            $table->unsignedBigInteger('tax_id')->comment('税率ID');
            $table->string('estimate_number')->nullable()->comment('見積番号');
            $table->string('title')->comment('件名');
            $table->date('publish_dt')->comment('発行年月日');
            $table->date('expiration_dt')->nullable()->comment('見積有効期限');
            $table->string('condition')->nullable()->comment('支払条件');
            $table->string('extra', 1000)->nullable()->comment('備考');
            $table->timestamps();
            $table->softDeletes()->comment('削除日時');

            $table->foreign('company_id')->references('id')->on('companies');
            $table->foreign('client_id')->references('id')->on('clients');
            $table->foreign('tax_id')->references('id')->on('taxes');
        });
    }
}
```

```php
<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateTaxesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('taxes', function (Blueprint $table) {
            $table->bigIncrements('id')->comment('ID');
            $table->unsignedTinyInteger('rate')->comment('税率');
            $table->date('start_dt')->comment('開始年月日');
            $table->date('end_dt')->nullable()->comment('終了年月日');
            $table->timestamps();
            $table->softDeletes()->comment('削除日時');
        });
    }
}
```

ここで、Estimate と Tax において、素のSQLであれば、estimates.tax_id を使わずとも、

```sql
SELECT * FROM estimates 
INNER JOIN taxes 
ON (estimates.publish_dt BETWEEN taxes.start_dt AND taxes.end_dt)
 OR (estimates.publish_dt >= taxes.start_dt AND taxes.end_dt IS NULL)
```

と、リレーションを取ることが可能です。

コントローラーから見積書一覧を取得するときに、`with`を使ってアクセスしたいので、

```php
<?php

namespace App\Http\Controllers;

use App\Models\Estimate;

class EstimateController extends Controller
{
    public function index()
    {
        $estimates = Estimate::with(['tax'])
            ->orderByDesc('updated_at')
            ->orderByDesc('id')
            ->paginate();
        return view('estimates.index', compact('estimates'));
    }
}
```

まず最初に、このSQLを表現するリレーションを表現できないのか？
と調べましたが、もちろん以下の形では表現できません。

```php
<?php

use Illuminate\Database\Eloquent\Model;

class Estimate extends Model
{
    public function tax(): BelongsTo
    {
        return $this->belongsTo(Tax::class, 'publish_dt'); // NG
    }
}
```

また、以下のように表現しても、できなくはないですが、
一覧表示するときにループの中で毎回SQLを発行してしまうので、良いアプローチではないと思います。

```php
<?php

use Illuminate\Database\Eloquent\Model;

class Estimate extends Model
{
    public function tax()
    {
        return Tax::whereDate('start_dt', '<=', $this->publish_dt)
                  ->where(function($query){
                    $query->whereDate('end_dt', '>=', $this->publish_dt)
                      ->orWhereNull('end_dt')
                  })->first();
    }
}
```

#  暫定的に採用したアプローチ

`estimates`に`tax_id` を追加し、素直にbelongsTo でリレーションし、
`EstimateObserver` クラスで `creating` , `updating` を定義しています。

```php
<?php

namespace App\Observers;

use App\Models\Estimate;
use App\Models\Tax;

class EstimateObserver
{
    public function creating(Estimate $estimate)
    {
        if (is_null($estimate->publish_dt)) {
            return;
        }
        $publish_dt = $estimate->publish_dt;
        $estimate->tax_id = Tax::whereDate('start_dt', '<=', $publish_dt)
            ->where(function ($query) use ($publish_dt) {
                $query->whereNull('end_dt')
                    ->orWhereDate('end_dt', '>', $publish_dt);
            })->first()->id;
    }
    
    public function updating(Estimate $estimate)
    {
        if (is_null($estimate->publish_dt)) {
            return;
        }
        $publish_dt = $estimate->publish_dt;
        $estimate->tax_id = Tax::whereDate('start_dt', '<=', $publish_dt)
            ->where(function ($query) use ($publish_dt) {
                $query->whereNull('end_dt')
                    ->orWhereDate('end_dt', '>', $publish_dt);
            })->first()->id;
    }
}
```