こんにちは
手元の 5.2.2 ですと、meta_value は longtext 型ですので、
4,294,967,295 または 4G バイト (232 − 1) 文字
入ります。
https://dev.mysql.com/doc/refman/5.6/ja/string-type-overview.html
例示されているような１レコードはシリアライズすると52バイトになる模様ですので、単純計算で 82,595,524 レコード入るんじゃないでしょうか。
このサイズまで来たら、MySQL が一度に受信可能なデータサイズとか、ネットワークの何とかとか、インフラ系の制約も影響するのかもしれませんけど。
適切かどうかということですが、このデータが1ユーザーあたり何件程度作られると想定しているのかによると思いますが、1ユーザーあたり数万件にもなることを想定するなら、独自のテーブルを作ってそちらに保存したほうがパフォーマンス的にも管理上も良さそうに思います。
また、ユーザーから「お気に入りの内容が変なんです」などの問い合わせがあった場合、シリアライズされて入っていると、調査がめんどくさいな、ともちょっと思いました。
こんにちは
具体的な数字をありがとうございます。
わかりやすくて助かりました。
テーブルを作るという考えはなかったです。
「wordpress テーブル 追加 データベース」で検索するとちらほら出てきて設定自体はできそうなのですが、質問がございます。
なぜ、ユーザーのカスタムフィールドのテーブルと別のテーブルを作ることで、利便性と速度が向上するだろいうという予測になるのでしょうか？
そのあたりまったく未経験の素人でして、もしよろしければ教えていただけませんでしょうか。
別テーブルを作成した方が良いかどうかはケースバイケースですが、今回は最大１ユーザーあたり数万件のお気に入りが登録されると想定しています。
まず、「あのページをお気に入りに登録したのに登録されていない」「別のページが登録されてしまった」などの問合せがあった場合、全てのお気に入りがシリアライズされてテーブルの１フィールドに入っていたら、そのデータをどのように探せば良いでしょうか。
お気に入りのリストを取得して表示する、管理用のPHPを作成して確認する必要がありそうです。
しかし、別テーブルになっていれば１つのお気に入りが１レコードになっているので、SQLを流せばすぐに確認できそうです。
また、私でしたらこのようなデータに登録日時や更新日時のタイムスタンプを持たせておくかもしれません。
そうすると、Webサーバーの操作のタイミングとデータベース更新のタイミングを比較することができ、操作したのに登録されていないのか、そもそも操作もされていないのか、など詳しい調査も楽になります。
また、シリアライズされていると、ある１ページがお気に入りに登録されているのかどうかを判断するのに、一旦データベースから数万件のお気に入りを取得する必要があります。
お気に入りを１件追加する場合にも、数万件全て取得して追加した後、数万件を更新する必要があります。
これはパフォーマンス的には非常によろしくないと思います。
あと、一度に送受信するデータサイズが非常に大きくなると、先述のようにフィールドの容量以外にネットワークやMySQLの通信データ量の制限などの制約にひっかかることも気にしなくてはいけなくなりそうです。
とは言え、このようなことはケースバイケースです。
独自のテーブルを作成すると自分で SQL を書いて登録・更新する必要があり、user_meta を更新するのとは開発の手間が段違いです。
ユーザー数が非常に多くても、一人当たりのお気に入り登録数が数十程度しかないなどであれば、user_meta でやったらいいんじゃないのかな、と思います。
