Drupalは良いですか：カスタムテーブルかCCK？

Question

Drupalサイトを開発する必要があります。そのサイトでは、多くのカスタムフィールドを持つ連絡先や予定のリストを含むフォームをユーザーがコンパイルできます。

私は、カスタムMySQLのテーブルを持つ

間を行うには良いことだか分かりません。カスタムコンテンツタイプ

を使用してCCKテーブルを持つ

私はCCKが私のために仕事の一部になることを知っているが、私はフィールドを作成し、取り扱いにはそれが少し重い見つけます。

あなたの意見は？

Answer 1

Drupalコミュニティは、MPDの答え、主にCCKとビューを使用しています。

個人的には、私はそれほど良い解決策を見つけることはほとんどありません。 IMO ViewsとCCKが時間と労力で本当の利益をもたらす唯一の場所は、最終結果が不十分であるか緩やかに定義されている場合です。ただし、ワイヤーフレーム、モックアップ、またはデザインを使用する場合、views + cckにはlot of undoingが必要です。

もう一つの重要な考慮事項は、Drupalsが展開していないことです。 CCK +のビューを作成し、テーマのソースとカスタム（フォームの変更）コードをその上にスローすることがよくあります。 チャンスは醜い展開です：新しい設定（たとえば、あなたが定義した新しいCCKフィールド）がなければテーマが壊れます。しかし、新しいテーマがなければ、あなたの新しいCCKフィールドが壊れます。いくつかのダウンタイムで「解決」されることが多いDrupalでは、新しいコードが展開され、直ちにこれらのフィールドを手動で再設定します。強力な機能や特徴の形でこれにいくつかの複雑な "解決策"があります。

CCK、ビュー、CCKフィールドモジュール、VIEWアドオン、およびたくさんのグルーコードのbucketloadで終わることになります。テーマ面では、Divに感染したオーバーライドが大きくなります。

このすべては、単一の最適化されたクリーンなモジュールを使用して、シンプルでクリーンで保守性が高く最適化されたカスタムモジュールで可能でしたが、

コードでどのように感じるかは、すべて家庭で起こります。私は、個人的には、いくつかの（きれいな、よくアーキテクチャされた）PHPの行を始める気にしないでください。他の人はコーディングから離れてクリックを好む（しかし、私の経験では、最終的にはより複雑なインターフェースをコーディングすることになります）

Answer 2

個人的には、CCKフィールドでのカスタムコンテンツタイプの使用は、ほとんどの場合、CCKが他のDrupalモジュール（特にビュー）と密接に統合されているため、ほとんどの場合最適です。