ファイルサーバに保存したプロフィール画像→loginしているuserの画像をとってくるには？(laravel5.5)

総合スコア51

2018/04/21 02:11 編集

回答ありがとうございます。こちら表示時はAuth::user()->id; でとってきた値を参照してImageオブジェクトのcreated_atとnameより画像のパスを取ってくる。こちらは理解できたのですが、profile画像は1userにつき1つの写真だけなので、「userテーブルに「img」みたいなカラムをただ追加して名前を保存しとく」という方法が単純に思いつくのですが、なにかデメリットがあるのでしょうか？？

2018/04/21 02:45

すぐに思いつく限りで３つほどありますので記載します。 ①タイムスタンプからファイルパスが割り出せなくなる created_at もしくは、modified_atからファイルパスを特定する仕様の場合、そのどちらかのカラムのタイムスタンプを写真がアップロードされた日付で固定する必要があります。しかしながら、プロフィールは更新される可能性が高いものですので、これが難しいと思います。 ②画像をアップロードしたユーザーの特定ができなくなるプロフィール画像自体も更新される可能性があります。リレーションを貼っていない場合、過去の画像が誰がアップロードしたものかわからなくなってしまいます。プロフィール画像として違法画像がアップロードされる→別画像をアップロードし直す　とされた場合、その違法画像をアップロードした犯人がわからないなど困った事態に陥ります。 (このためImageモデルからUserモデルへのリレーションも必要です。　User対Imageが1対多) ③プロフィール以外にも画像を使う可能性があるサービスの機能が増えていく可能性を考えると、画像ファイルが別のコンテンツにも使用される可能性が出てくると思います。現状の延長線でいけばプロフィール画像のサムネイル画像を作りたい場合などです。また、ユーザーごとにブログ記事を書けるような機能が追加されるかもしれません。そう言った場合、Imageモデルがあると便利かと思います。

2018/04/21 04:37 編集

すみません、たぶん誤解をあたえてしまったかもしれません。 usersテーブルにimgカラム作成　→パスをnameカラムに挿入する場合はuser_idを参照し、データがあればupdate, なければinsertします(profile画像は1userにつき１つなので) →ですので①に関してはuser_idを参照しプロフィール画像を取ってこれる + ②に関してはそのuser_idのimgカラムにprofileのパス名があるので特定はできるかと？思われますしかし確かに③を考えるとImageモデルは作っておいた方がbestだとおもわれますので、そうしようとは思っております。

2018/04/21 05:10

本文に設計について追記いたしました、申し訳ございませんがそちらもよろしくお願いいたします。

行動規範の内容に同意します

例として記載されている4-hoge.jpgのhoge.jpgは、ユーザがアップロードした際のファイル名そのものでしょうか。（ユーザごとに可変でしょうか）

対応として３つ考えました。いかがでしょうか。

ファイル名をDBに保存し、表示の際にDBから取得して「(ここをどう書けば??)」部分に入れる
ファイル名がid-xxxx.yyyという形式が守られるのであれば、public/images/teachers/フォルダ内をユーザID+ハイフン（例でいうと"4-"）の前方一致検索でファイル名を取得して「(ここをどう書けば??)」部分に入れる
いっそのこと、ファイル名を「ユーザID.jpg」というファイル名にして保存するようにし、表示時も「ユーザID.jpg」として扱う

質問を受けての追記への追記

ディレクトリパスについては、「運用上画像ファイルをどのように扱いたいか」で仕様を決めるのが良さそうに感じました。この辺りを明記されるとさらに良い回答が得られそうです。
運用が考慮できていないかもしれませんが、例えばこういった規約にしてみるのもありですかね。

プロフィール画像はユーザIDに紐づくような規約（ディレクトリにユーザIDまたはそれに準ずる情報を使う）
ブログ画像は日付や記事IDなど一意性のある情報と連番を組み合わせた規約

ユーザ退会のような業務がある場合、関連する画像を削除しやすく設計しておくと良さそうですね。
またプロフィール画像は最新版だけあればいい、のであれば、ユーザごとにファイル名を固定にしておいて上書きする運用もありかと思います。
ブログ画像は記事削除時に画像ファイルも削除したいようであれば、記事IDに紐づく形で管理できるといいですね。

この場合、プロフィール画像とブログ画像は別のテーブルで管理する方が良さそうです。（保持の単位が異なるので）

プロフィール画像の情報はユーザ情報と同一テーブル、または1対1で紐づくテーブルで管理する
ブログ画像の情報は記事情報に1対Nで紐づくテーブルで管理する

投稿2018/04/21 00:03

編集2018/04/21 07:53

総合スコア2335

2018/04/21 04:43 編集

回答ありがとうございます。「前方一致検索」についてですが「'images/teachers/'./^{{Auth::user()->id}}/,」という書きかたでしょうか？(これはsyntax errorが出るので違うと思いますが。。)　それともpreg_matchを使うのか？？と思いましたがこれはやはりtrue or falseでreturnされるので違いますし。。　何か勘違いしていたら申し訳ないです、よろしくお願いいたします。

2018/04/21 07:34

誤解を与えてしまったかもしれません。『public/images/teachers/フォルダ内をユーザID+ハイフン（例でいうと"4-"）の前方一致検索でファイル名を取得して』とは、サーバローカルのディレクトリ内ファイルの検索です。readdir等を利用した検索処理を自前で実装することを想定しています。（http://php.net/manual/ja/function.readdir.php imageタグに正規表現でのファイル名指定は行えません。

2018/04/21 07:36

方法論としては、他の回答者さまからもあるように、「ファイル名をDBに保存し、表示の際にDBから取得して「(ここをどう書けば??)」部分に入れる」が、性能面も鑑みた上で良いかと思います。

2018/04/23 08:12

ありがとうございます。 takyafuminさんのおっしゃるテーブル構造はyukkenoottunaさんの提案された中間テーブルを使用するのではなく「user_imagesテーブル(profileカラム作成し0,1で管理？？)」　→profile画像1枚・userその他の画像の管理を考えているので、modelは1対N？「blog_imagesテーブル」　→1対N 　　またそれぞれの画像保存pathはimages/teachers, images/blogs　などと分ける設計でしょうか？？

2018/04/23 15:29

> takyafuminさんのおっしゃるテーブル構造はyukkenoottunaさんの提案された中間テーブルを使用するのではなくそうですね。そのような主旨で回答致しました。 > 「user_imagesテーブル(profileカラム作成し0,1で管理？？)」 > 　→profile画像1枚・userその他の画像の管理を考えているので、modelは1対N？そのような要件であれば、1対Nで良いかと思います。画像の種類を判別するための区分でprofile、その他を分けると拡張性も持てますね。 > 「blog_imagesテーブル」 > 　→1対N 1記事に複数の画像が使われる可能性を考慮し、このように考えました。

2018/04/23 15:30

> またそれぞれの画像保存pathはimages/teachers, images/blogs　などと分ける設計でしょうか？？この点は、どのように扱いたいかで設計するのが良いかと思います。回答としては、一例として上記のように分ける想定でした。

2018/04/23 15:31

保存時のファイル名については重複するとまずいので、 yukkenoottunaさまの回答にあるようにユニークなファイル名を付与する仕組みがあるといいですね。

2018/04/24 12:49

丁寧な回答ありがとうございました、今回はtakayafuminさんのテーブル構造+yukkenoottunaさんのファイル作成・保存方法を合体させた方法でいこうと思います。非常に勉強になりました、ありがとうございました！

2018/04/24 14:43

頑張ってください！！

行動規範の内容に同意します

ベストアンサー

追記を拝見し、自分の過去のコードや設計を再度確認しました。
この設計が100%正しいというわけでは無いと思いますが、一例として御覧ください。

モデルとリレーション

Userモデル対Imageモデルは一対多の関係だが、リレーション上多対多にする。
Userモデル以外からImageモデルを使用する場合も、多対多のリレーションを貼る。
この対応にて、User, Imageモデル共にテーブルにて双方のidを格納するカラムが必要なくなる
- 中間テーブルimage_userテーブルにて管理

マイグレーション

かかるマイグレーションは下記のようになる(up以外省略)

create_images_table.php

public function up()
{
    Schema::create('images', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name')->comment('写真のファイル名');
        $table->softDeletes();
        $table->timestamps();
    });
}

create_image_user_table.php

public function up()
{
    Schema::create('image_store', function (Blueprint $table) {
        $table->increments('id');
        $table->unsignedInteger('image_id')->comment('imageテーブルのID');
        $table->unsignedInteger('user_id')->comment('userテーブルのID');
        $table->timestamps();
    });
}

画像の格納処理

public function storeImage($image)
{
    // [storage/app/public/images/年/月/日]のディレクトリを作成
    Storage::makeDirectory('public/images/' . date('Y/m/d'));
    // 一意のファイル名を作る
    $fileName = uniqid();
    $directoryPath = public_path(). "/storage/images/" . date('Y/m/d');
    // 基本の横幅を設定
    $basicWidht = 250;
    // 保存をする
    $this->makeImage($image, $basicWidht, null, "$directoryPath/$fileName");
    // ファイル名をimagesテーブルにレコードし、Imageモデルを返す
    return Image::create([
        'name'      => "$fileName",
     ]);
}

画像はその性質によらず、[storage/app/public/images/年/月/日]のディレクトリに保存します。
また、ファイル名はユーザーがアップロードしたものをそのまま使うのではなく、uniqid()によりユニークになるようにしてあげます。
このディレクトリ＋ファイル名でユニーク性を保ち、かつ使われていない過去ファイルをディレクトリごと圧縮する際などに便利になります。

画像パスの取得

$path = 'public/images/' .date('Y/m/d/', strtotime($user->images[0]->created_at)) . "$image->name";
$user->image->url = Storage::url($path);

画像パスは取得処理が面倒なので、コントローラやサービスクラスにて処理し、その後viewに渡すようにしています。

投稿2018/04/21 06:18

総合スコア51

2018/04/21 10:41 編集

回答ありがとうございます。申し訳ございませんが、まだ疑問点がありますので本文に追記させていただきました(質問を受けての追記②)。恐縮ですがよろしくお願いいたします。

2018/04/21 12:16

① そうです。省略しています。プロフィール画像の保存は大枠で見れば、ユーザーの更新に内包されているはずです。コントローラにて、`$user->images()->sync([$image->id]);`で中間テーブルが更新されるはずです。 ② > $image->nameでloginしているユーザのidを取ってこれるのか？？？これは私の理解力不足で意図が汲みきれません。ごめんなさい。ログイン済みのユーザーであれば、ユーザー情報がすでに取得できている認識です。このため、リレーションの貼ってあるImageオブジェクトはユーザー情報に内包され取得できていると思います。つまり、`$user->images[0]`に最新のプロフィール画像情報がImageオブジェクトとして格納されている認識ですがいかがでしょうか。また、Imageオブジェクトのidの必要性はわかりかねますが、必要であれば`$user->images[0]->id`で取れるのではないかと思います。