Cita: Mi problema está en optimizar los datos a guardar cada vez que se registra un nuevo mantenimiento, en donde debo guardar todos los datos del vehiculo, por ejemplo: todos los datos del auto (si es auto), datos del motor, kilometros recorridos, etc. para luego poder consultarlos y ver los datos que tenían en ese momento, pero no puedo cargarlos en una sola tabla, ya que son miles de campos y la performance se me va a piso.
Tu problema es entendible, pero nosotros tenemos el problema de que no sabemos en qué consiste tu "etcétera", por lo que no podemos saber si realmente la tabla que planteas tiene "miles de campos" o es que simplemente el sistema completo no está normalizado. Necesitaríamos saber mejor a qué te refieres con ese "miles", es decir, tendríamos que primero y antes de buscar parchar el sistema, ver completamente cuales son los requisitos del sistema, y qué entidades involucra, a fin de ver si esto no se puede resolver con un mejor diseño.
La mayoría de las veces suele ser esa la solución.
Respecto al tema de poner un DATETIME por cada cambio, eso no solo es una buena práctica, sino que es un requerimiento básico para un sistema como el que describes. Todo sistema donde hay cambios históricos en los datos
debe forzosamente contener un campo de tipo DATETIME o TIMESTAMP que permite hacer un
seguimiento cronológico de los cambios. Todos los sistemas que conozco de ese tipo lo tienen, y casi siempre en
todas las tablas, no sólo en una como esa. Incluso más: Incluyen un campo para identificar qué usuario hizo ese cambio.
Y sobre el tema de PK/FK, infiero que te refieres a que usas campos numéricos autoincrementales para crear las PK... Bueno, eso no es obligatorio; ni siquiera es un requerimiento del modelo E-R, sino una solución habitual heredada de la programación, pero no es a mi juicio una buena práctica. De eso he hablado en este foro muchas veces, si quieres ahondar ese tema.
Para que quede claro, bien podrías crear la PK como una clave de doble campo: La placa o patente del vehículo, y la fecha y hora de la modificación. Te puedo asegurar que sería mucho más eficiente y segura que usar un ID de tipo AI.