19450


あるアカウントが作成されるごとに、そのアカウントに応じて別々のテーブルを動的に生成したいのですが、CakePHPで提供されているライブラリのようなものを見つけることができませんでした。  
なので、query() を使って直接SQL文を投げる方法も考えたのですが、あまり推奨されていないようでした。

動的にテーブルを生成するようなことはあまり行わないのでしょうか。  
もし、生成するとするならばquery() を使う以外で方法をご存知の方がいらっしゃいましたら、  
教えていただけると助かります。  
また以下は生成したいテーブルのqueryです。

[code]

    CREATE TABLE `comment_table` (
      `comment_table_id` int(11) unsigned NOT NULL AUTO_INCREMENT ,
      `post_id` int(11) NOT NULL ,
      `user_id` int(11) NOT NULL ,
      `id` int(11) NOT NULL ,
      `text` text NOT NULL ,
      `img` text ,
      `create_at` datetime NOT NULL,
      PRIMARY KEY (`colony_comment_table_id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=36 DEFAULT CHARSET=utf8;
    
[/code]

* * *

現在開発しているアプリがツイッターのように１つのタイムラインで全員が会話するものではなく、2chの掲示板のように複数あるコミュニティ（このコミュニティはユーザー‌​が作成することができる）の中で、タイムラインが存在するようなものなんですが、そういった場合１つのテーブルの中ですべてのコミュニティのタイムライン情報が管理されてい‌​るのでしょうか。
直感的ではありますが、コミュニティごとのタイムラインを管理するようなテーブルがあったほうがスムーズのような気もするのですが。 いかがでしょうか。


CC BY-SA 3.0
2015-11-28T19:00:20.377
19418
2015-12-01T03:43:16.430
2015-11-30T00:03:28.633
5793
12470
question
php mysql cakephp sql
CakePHPを使って動的にテーブルを生成する


アプリケーションから動的にテーブルを作成するのは全くナンセンスな手法です。すでにテーブルに`user_id`があるのでそれで識別するようアプリケーションを設計しましょう。

アプリケーションが触っていいのはデータのみで、データ構造には触ってはいけません。これは、RDBを使う場合のセオリーというか作法というか決まり事というかそういう話なので、アプリケーションの中身とは全く違うレイヤの話です。

言われるようなテーブルの分割を実際にやったとしても困ることが出てきます。「コミュニティ」ごとのテーブルを作ったとしましょう。(「アカウント」なのか「コミュニティ」なのかぶれていますが、追加情報の方に従って)

あるユーザーの投稿をすべて取得したい、ということがあったとき、複数のテーブルを一度に検索ということがSQLでは素直に出来ないので、面倒なSQLを書くか、あきらめてテーブルごとに検索を繰り返す必要があります。セオリーを外すとこういうことになります。

普通は一つのテーブルに`community_id`カラムをもうけることで識別します。それで十分です。

なお、パフォーマンスなどの問題で同じ種類のテーブルを複数に分割する手法もあるにはあるのですが、極めてまれな事例ですし、それにしてもアプリケーションから動的に作るということはありません。

こういう手法を使うには詳細な設計が必要です。「何となく使えば大量データでも平気」みたいな銀の弾丸ではありません。それどころか素直な設計より遙かに遅くなることもあり得ます。本当に単純にはさばききれないほどのデータが想定されているのであれば、まずはDBアーキテクトを探して設計に入ってもらう方がいいでしょう。


CC BY-SA 3.0
2015-11-29T11:20:14.570
19439
2015-12-01T03:43:16.430
2015-12-01T03:43:16.430
5793
5793
19418
answer


CakePHPでは特にCREATE TABLEに関する機能はないので、CREATE文のSQLで発行していますね。

動的にCREATE TABLEでテーブルが作られていく設計にした場合、いくつか懸念点があるのですが、

  * テーブルを横断的に検索する機能なり画面があると検索処理が大変になるのではないか 
    * 例えばユーザーAさんが発言した内容を全てのテーブルから取得する場合など
    * 索引（インデクス）はテーブルごと
    * 増え続けるテーブルのサイジングやメンテナンス

もちろん、想定されているユーザ数や書き込みがあまりに多い場合やコミュニティの増加が読めない場合によってはテーブルを分けて作ったほうが、索引はわかれますので良い面もあります。

参考になれば幸いです。


CC BY-SA 3.0
2015-11-30T00:42:05.013
19450
2015-11-30T00:42:05.013
5778
19418
answer