Using a database view = evil incarnate?

Question

I'm at a point in doing some WordPress plugin development where from what I can tell I either have to create an entirely new plugin or I can create a database view.

The client wants some simple logs of downloads by user and then wants to be able to export these logs to CSV.

The logging is easy enough and done. My plan for exporting the logs to CSV is just to use a table export plugin that should export the logs. The client is happy with a basic interface.

However the logs are split into two tables, with the log 'categories' being sensibly normalised into a separate table - but that makes no sense to a user. I can fix this super easy with a database view:

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`

This then shows up happily as a separate table in the plugin, the client can click on this and it exports nicely as CSV.

However this makes me feel slightly dirty. Its a complete hack, totally non-WordPress in any aspect and no-one else seems to even consider creating views in Google searches.

Nevertheless its simple, relatively unlikely to break unless the underlying plugin changes its database structure.

So if this is REALLY bad, let this question be a warning for others who fall here.

Otherwise does it make sense in this case or is there some other simple method I've missed for solving this issue?

Answer 1

In custom tables you do whatever you want. If a view is what you need, use it.

However, you might consider separating the code in an exporter. See wp-admin/includes/export.php for a start. If you keep the actual SQL and the export format separate you can:

• create a new exporter for another table structure easily
• use other data for the same format
• implement an user interface to customize the export (separator for CSV, encoding, tables and columns)

The plugin you mentioned doesn’t do that. Plus, it doesn’t even use the export API interface. There should always be just one single place to export data: Tools/Export.