web-dev-qa-db-ja.com

データベースビューを使用する=悪の化身？

私はWordPressプラグインの開発を行っているところですが、そこから私はまったく新しいプラグインを作成するか、データベースビューを作成することができます。

クライアントは、ユーザ別の単純なダウンロードログを望み、次にこれらのログをCSVにエクスポートできるようにしたいと考えています。

ロギングは十分に簡単で行われています。ログをCSVにエクスポートするための私の計画は、ログをエクスポートするべきである テーブルエクスポートプラグイン を使うことです。クライアントは基本的なインターフェースに満足しています。

ただし、ログは2つのテーブルに分割され、ログの「カテゴリ」は別のテーブルに賢明に正規化されています - ただし、これはユーザーにとって意味がありません。私はこれをデータベースビューで簡単に直すことができます。

CREATE VIEW wp_my_evil_export_view AS 
SELECT  `e`.`id`, `l`.`log_name` as 'category',`l`.`description`, `e`.`date`, `u`.`user_email` as 'email', `e`.`text`
FROM    `wp_wls_entries` as `e`,
        `wp_wls_logs` as `l`,
        `wp_users` as `u`
WHERE   `e`.`log_id` = `l`.`id`
    AND `e`.`user_id` = `u`.`id`

これはその後プラグインの中の別々のテーブルとして楽しく表示されます、クライアントはこれをクリックすることができます、そしてそれはCSVとしてうまくエクスポートします。

しかし、これは私をわずかに汚く感じさせます。その完全なハック、あらゆる面で完全にWordPress以外、誰もGoogle検索でビューを作成することさえ考えていないようです。

それにもかかわらず、その根本的なプラグインがそのデータベース構造を変更しない限り、その単純な、比較的壊れそうにない。

ですから、これが本当に悪い場合は、この質問をここにいる他の人への警告にしてください。

それ以外の場合、この場合は意味がありますか？それとも、この問題を解決するために私が見逃した簡単な方法がありますか？

plugin-developmentdatabasecsv
5
icc97

カスタムテーブルでは、必要なことは何でもします。ビューが必要なものであれば、それを使用してください。

ただし、エクスポーターでコードを分離することを検討するかもしれません。はじめにwp-admin/includes/export.phpを見てください。実際のSQLとエクスポート形式を別々にしておくと、次のことができます。

  • 別のテーブル構造用の新しいエクスポータを簡単に作成する
  • 同じフォーマットに他のデータを使用する
  • エクスポートをカスタマイズするためのユーザーインターフェースを実装する（CSV、エンコーディング、テーブル、カラムの区切り文字）

あなたが言及した プラグイン はそうしません。加えて、それはエクスポートさえ使用しません API インタフェース。データをエクスポートする場所は常に1つだけです。Tools/Export。

5
fuxia