Integridad referencial a nivel de base de datos

[tmas0]

Buenas,

Revisando el esquema de base de datos observamos que hay muchas claves foráneas sin definir.

Por ejemplo:

• certifygen: usermodified
• certifygen_model: usermodified
• certifygen_context: usermodified
• certifygen_validations: certifygenid, issueid, userid, usermodified
• certifygen_repository: validationid, userid, usermodified
• certifygen_error: validationid, usermodified

Luego, vemos otros campus multivaluados, pero al estar así pueden conllevar problemas cuando algún "id" ya no exista, lo que dará lugar a errores.

Por ejemplo:

• certifygen_model: langs
• certifygen_context: contextids
• certifygen_validations: courses

Además, os pongo otra observación: tabla - campo. |certifygen_model | \<FIELD NAME="langs" TYPE="text" NOTNULL="false" SEQUENCE="false" COMMENT="Languages list seprated by commas."/>| | certifygen_validations | \<FIELD NAME="lang" TYPE="text" NOTNULL="true" SEQUENCE="false" COMMENT="Language"/>| Se está usando el mismo tipo de datos, por tanto, ambos se pueden usar de igual forma, la simple s marca si este campo debe pasarse por un explode o no.

Un saludo

[xpazv]

Respecto al segundo punto, de los campos multivaluados,revisaremos el control de errores para que no se usen o presenten valores de los campos, que puedan no estar presentes

Respecto al primer punto, el campo usermodified forma parte de la lógica del persistente. La ausencia de claves foráneas se debe a evitar borrado de datos asociados a usuarios no existentes.

[elena3ip]

Hola,

Perdona pero no veo el problema del lang y langs. Un modelo puede tener asociado varios idiomas, pero la emisión de un certificado solo tiene asociado uno. De ahí la diferencia del nombre.