Использование представления базы данных = воплощение зла?

Я в какой-то момент занимаюсь разработкой плагинов WordPress, из чего я могу сказать, что мне нужно создать совершенно новый плагин, или я могу создать представление базы данных.

Клиент хочет несколько простых журналов загрузки пользователем, а затем хочет иметь возможность экспортировать эти журналы в CSV.

Заготовка леса достаточно проста и выполнена. Мой план экспорта журналов в CSV – это просто использовать плагин экспорта таблицы, который должен экспортировать журналы. Клиент доволен базовым интерфейсом.

Однако журналы разбиваются на две таблицы, причем категории журналов разумно нормализуются в отдельную таблицу, но это не имеет смысла для пользователя. Я могу исправить это очень просто с представлением базы данных:

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.

Тем не менее, его простой, относительно маловероятный разрыв, если основной плагин не изменит структуру базы данных.

Поэтому, если это ДЕЙСТВИТЕЛЬНО плохо, пусть этот вопрос станет предупреждением для других, которые здесь падают.

В противном случае это имеет смысл в этом случае или есть какой-то другой простой метод, который я пропустил для решения этой проблемы?

Solutions Collecting From Web of "Использование представления базы данных = воплощение зла?"

В пользовательских таблицах вы делаете все, что хотите. Если представление – это то, что вам нужно, используйте его.

Тем не менее, вы можете подумать о том, чтобы отделить код от экспортера. См. wp-admin/includes/export.php для начала. Если вы сохраните фактический SQL и формат экспорта, вы можете:

  • легко создать нового экспортера для другой структуры таблицы
  • использовать другие данные для одного формата
  • реализовать пользовательский интерфейс для настройки экспорта (разделитель для CSV, кодирования, таблиц и столбцов)

Плагин, о котором вы говорили, этого не делает. Кроме того, он даже не использует интерфейс API экспорта. Для экспорта данных всегда должно быть только одно место: Инструменты / Экспорт .