Guardar

[PabloGarciaAr]

Hola, tengo un sistema de registro de mantenimientos con una base de datos con tablas como: usuarios, vehiculos, motores, compononetes, modelos, marcas, mantenimientos, etc, etc..
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.
Una forma que se me ocurrió es agregar por cada cambio en las tablas, (motor, vehiculo, y similares) un nuevo registro con un TIMESTAMP o DATE, y ese valor lo guardo en la tabla mantenimientos, pero queria saber si hay algo mas optimo, ya que comparar fechas no me parece lo mejor, mas cuando deberian ser pk o fk los campos.

quería saber si alguien tuvo el mismo problema antes y como lo solucionó.

Muchas Gracias!

[gnzsoloyo]

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.

[PabloGarciaAr]

Gracias por la respuesta gnzsoloyo.
Hasta donde entiendo la tabla está bastante normalizada, igualmente puede ser como decis, un error en el diseño.
Exageré un poco con lo de miles, pero son varios.
Detallo un poco mejor el problema y las tablas del sistema:

Tablas y sus campos mas importantes:

vehiculos: id, fecha, matricula, idMarca, idModelo, color, kilometraje (PK: id, matricula y fecha)
motores: id, fecha, idMarca, nroSerie, horasUso (PK: id y fecha)
componentes: id, fecha, nombre, descripcion, horasUso (PK: id y fecha)
modelos: id, descripcion
marcas: id, descripcion
mantenimientos: id, fecha, idVehiculo, idTaller, idPropietario, fechaSalida (PK: id, fecha y idVehiculo)
usuarios: id, idTaller, nombre, apellido, mail, password,
talleres: id, razonSocial, direccion,

y algunas otras mas genéricas, como provincias, localidades..

Pero de esta forma encuentro muy engorroso hacer la consulta SQL de los mantenimientos de un taller, ya que la fecha podría no ser la misma en mantenimientos y vehiculos por ejemplo, ya que si se modificó algo en el motor en un trabajo, solo la tabla motor es modificada y no la de vehiculo, y en ese caso debería preguntar por la fecha mas proxima inferior, y eso es lo que me parece poco performante.