せっかく要望のカテゴリができたので、一つ要望を出させていただきます。
MT5からリビジョン管理の機能がつきましたが、便利であると同時に（当たり前ですが）データベースの要領を消費量が増大します。
カスタムフィールドは、現在の使用では、1つ1つの項目を、別のデータベースフィールドとして作っていますよね。
普通にブログを作るとかならあまり問題ないのですが、
・ブログ記事にカスタムフィールドがまとまった数量定義されていて
・リビジョン管理が積み重なった場合
・結果として、mt_entry_metaテーブルが肥大する
傾向があります。
通常のブログとか、企業コーポレートサイトだとあまり問題ないですが、数千件を超えるデータベースサイト的に使うと、このmt_entry_metaの肥大化がちょっと気になります。と言うか最近、気になり始めました。
ブログ3個、各ブログ記事に10のカスタムフィールド、リビジョンを10まで許容、ブログ記事が各1000個ある場合
3個×10フィールド×10リビジョン×1000記事＝300,000レコード数
まで増えるので、結構な容量となります。
たぶんこれだけで、50MBぐらいMySQLの容量を消費する計算です。
上記のような使い方をしている人はあまりいないかもしれませんが、便利で御手軽に使えるカスタムフィールドなので、あまりデータベースを意識せずにウェブアプリやCMSとして使いこんでいると、知らない間にデータベースがいっぱいになる、あるいはパフォーマンスが悪化することがあるかもしれない、と思いました。
対策として
・従来のカスタムフィールドはそのままで
・ブログ記事と紐づく形でデータベーステーブルを拡張できる、第二のカスタムフィールド機能があれば、よりコアシステムとして使い込める
と思いました。
あまり需要はないかもしれませんが、なんとなく今後のMTにとって重要なポイントになりそうだったので、ご検討いただければ幸いです。
（すでに、とある方に似たようなプラグインを見せてもらった気が・・・もにょもにょもにょ）
訂正です。
・ブログ記事と紐づく形でデータベーステーブルを拡張できる、第二のカスタムフィールド機能があれば、よりコアシステムとして使い込める
は
・「ブログごと」と紐づく形でデータベーステーブルを拡張できる、第二のカスタムフィールド機能があれば、よりコアシステムとして使い込める
の間違いです。
blog-1には、テキスト型が2つ、テキストエリア型が2つ、ラジオボタン型が2つ。
blog-2には、ドロップダウン型が2つ、テキストエリア型が1つ
のような形で、各ブログのentryテーブルとカスタムフィールドテーブルが1体1になっているもの、という意味で書きました。
・・・というか、そこまでいくと、別にブログ記事と紐づく必要はないかも。
こんにちは。
肥大化は確かに問題だと思いますが、ブログ毎にカスタムフィールドのテーブルを分けると、複数のブログから情報を集める際にSQLが複雑になってしまうという別の問題が出てきます。
一定期間より過去のブログ記事はリビジョン情報を定期的に削除するなどして、データベースの肥大化を抑えるのが、現実的な解決策になりそうです。
具体的な実装についてはSAの中の人に期待する方向でいいんじゃないですかね。まぁ私も実装を考えてしまう口ですが。とりあえず、今は色々な要望を上げることが大事だと思います。
こんにちは。要望としてFogBugzに登録しました。
意図としては、それぞれのブログ毎に、複数のカスタムフィールドで構成されるような、より高度なカスタムデータ構造をスケーラブルに確保したいというような意味合いでよいでしょうか？
http://bugs.movabletype.org/default.asp?104062
http://bugs.movabletype.org/default.asp?W28
現在のカスタムフィールドの作りでは難しいですよね。MT カスタムオブジェクトを簡単に生成できる機能拡張があればよいような気がします。
>> あれ? これどこかでみたぞ
皆様
ご返信ありがとうございます。
＞金子さん、柳下さん
そうですね。まとめると
・mt_entyやmt_author、mt_commentみたいに、独立したテーブルを生成
・カスタムフィールドのように、管理画面からデータ形式を定義可能
・同じく、管理画面から、対応するMTタグを設定可能
・上記を、ブログと紐付けて、ブログ記事と連動しながら入出力可能にする。あるいは、独立したデータ項目として、メニューから遷移→入力可能
といったところでしょうか。
メリットは、大規模なサイトへのスケーラビリティ
になるかと思います。
こういったものは、単なる個人の要望レベルでも、直接FogBugzに登録して良いのでしょうか？
（FogBugz登録はまったく想像していませんでした）
＞藤本さん
現実的には、リビジョン管理をオフにするとか、あって2-3段階ですますのが現実的な対応になりそうですね。おっしゃるとおりかとは思いました。
＞ピロリーヌさん
コメントありがとうございます。「MTはコミュニティのもの、コミュニティが育てるもの」という意識がユーザーにできるだけでも、大きいですよね。
> こういったものは、単なる個人の要望レベルでも、直接FogBugzに登録して良いのでしょうか？
> （FogBugz登録はまったく想像していませんでした）
実装方法は別として、第三者にもわかるように、書かれていればよいかと思います。
＞柳下さん
ありがとうございます、今後はFogBugzに書き込もうと思います。
にっくさん、みなさん、こんにちは。
要点としては、「大規模なサイトでもより使いやすいカスタムフィールド(あるいは機能的に近いもの)が欲しい」ということでまとまっていると思いますので、些細な指摘ですが、以下の表現はちょっと正確じゃないように思いました。
> 3個×10フィールド×10リビジョン×1000記事＝300,000レコード数
ブログ記事のリビジョン間の変更情報については「mt_entry_rev」というテーブルにに保存されるので、「(mt_entry_metaテーブルの)レコード数」については、以下のようになると思います。
・3個×10フィールド×1000記事＝30,000レコード数
私の理解が間違っていたらすみません。
以上、要点ではないと思いますが、正確な議論のためにコメントしました。
にっくさんとほぼ同じようなことができたらいいなと以前より思っていたので応援をかねて書きます。
恥ずかしながらですが、私もMTの挙動がおかしくなってきたと思ったら、mt_entry_metaのデータがいつのまにか８万件ぐらいになっていて、しまいにはカスタムフィールドに値が保存されなくなてしまい、困った（ている）ことがあります。
ここに書かれてることすべて理解しきれてないのですが、私自身の要望をまとめると
「１ブログ１テーブルにして、カスタムフィールドを増やすとその各テーブルのフィールドが増えていく。」
というのが理想です。
加えて、
管理されるものは必ずしもブログの形態をとっているものだけではないので
タイトル・ボディ・概要などの区分けなく、すべてカスタムフィールドにして
ゼロの状態からフィールド１、２，３と増やせるようにするオプションがあると嬉しい。
さらに、
ダッシュボードにブログ（テーブル）を複数配置できるようにして
関連付けたいカスタムフィールドをドラッグするとリレーションが組めるようにする。そしてそれぞれのブログから関連した別ブログのデータが引っ張れるようにする。
ここまでできたらとても嬉しいです。
いままさに、カスタムフィールドのデータが増えそうなものを作ってるので、ちょっと心配になりつつ...
yasuoogleさん
「１ブログ１テーブルにして、カスタムフィールドを増やすとその各テーブルのフィールドが増えていく。」
となると、MTでなく、WPになってしまうような....w
複数ブログを容易に使えるのは、ブログ毎にテーブルが分かれてない（どのブログに格納されているのかも情報の属性でしかない）からかもしれません（素人の直観ですが）
１つのmt_entyに対して、 複数のmt_entry_metaをもつということは考えられるのでしょうか？ そうすればどのブログのカスタムフィールドが圧迫しているのかがわかりやすいし、メンテナンス対象の切り分けもしやすい
mt_entry_metaにか格納されているデータが、可変長のバイナリーなのは、パフォーマンスを上げるためなんでしょうか？ それとも将来マルチメディアデータそのものも格納してしまおうという構想あり？
あり、なし のようなboolean型的なカスタムフィールドを結構つくるのですが、型がちがうからって、格納されてる情報が小さければ、無駄に消費はしないんですよね？