Buenas a todos, una vez leído lo que quieres implementar te hago mi sugerencia:
Lo primero, que no lo más sencillo, pero si lo correcto es la normalización de tablas en DB con regularidad se suelen hacer hasta la 3FN, casi nunca se llega a la 4FN o más. (dejo un enlace por si a alguien le puede interesar)
https://guru99.es/database-normalization/
Dicho esto, se que puede sonar a "si es una aplicación pequeñita para mi, no necesito esto".
Esto que os comento y relaciono aquí es la forma correcta a nivel empresarial de trabajar, si se coge como patrón de trabajo habitual, primero facilita enormemente la escalabilidad, que para un proyectito pequeño puede ser añadir un campito más, pero para proyectos de gran embergadura puede ser vital. Yo solo lo expongo como patrón de metodología luego ya, cada uno es cada cual.
Yendo al meollo del asunto y según mi visión para lo que tu quieres implementar, y solo basandome en lo que has indicado yo haría 3 tablas:
Primera tabla:
PARTES
ID (PK) Fecha Detalle (opcionalmente la columna de tipo de trabajo que sería FK de otra tabla a discutir)

Segunda tabla
PARTES-VISITAS
ID Parte_ID (FK) Visita_ID (FK)

Tercera Tabla
VISITAS
ID (PK) Descripcion

El nombre es totalmente orientativo y la verdad no se si fuese correcto.
(PK - Primary key)
(FK - Foreing key)
En el momento de poder trabajar con la recuperación CRUD de los datos solo tendrías que hacer el típico INNER JOIN para la unión de tablas la inserción sería de la misma forma, en las tres tablas.
Vale, una vez soltado todo el rollo, si por cualquier motivo ves que algo no te cuadra, me pasas los requerimientos del desarrollo y la parte de DB me ofrezco a realizarla yo mismo, te paso el script y luego tú ya lo desarrollas a nivel de Front y Back.
Saludos.