Las tablas de base de datos no centrales son obligatorias si sus datos son más complejos que el modelo de publicación de WordPress, serán enormes y tendrán muchos detalles meta que se buscarán.
El formato de EAV que WordPress usa para su meta meta no se presta bien para la búsqueda de criterios múltiples.
Si divide su meta en muchas entradas, tendrá numerosas entradas por publicación en la tabla de meta de publicación, y la búsqueda de cualquier publicación a través de metas será mucho más lenta.
Si almacena todas las metas serializadas en una matriz y las tiene como una sola entrada en la meta posterior, esta vez se verá obligado a hacer solo búsquedas de texto dentro de esa meta, y no podrá usar operadores de comparación directamente en su consulta sql.
No es un gran problema si su complemento no va a tener miles de entradas y meta asociada.
Pero un problema importante si su complemento va a hacer algo grande.
Su situación, un nombre de archivo como entrada independiente y 3 entradas de metadatos adjuntas a esa entrada no parecen tan grandes. Puedes usar wordpress post table y meta table para ello.
PERO, si la gente va a buscar estas 3 metas mucho, ESPECIALMENTE en conjunto, entonces te recomiendo que configures tablas separadas.
Con ese formato, solo una tabla con una sola entrada, que también contiene todas las metas, estaría bien y haría consultas rápidas.
Por cierto, si usa tablas de WordPress y también usa el almacenamiento en caché de consultas, las búsquedas de los usuarios de sus datos se almacenarán en el caché con el tiempo e incurrirán en menos carga. Pero eso no sería tan prudente como hacer tablas separadas.