C'est un problème courant et il n'y a pas de solution parfaite. Quelques solutions :
1. Définissez les champs X de type varchar2, les champs Y de type nombre et les champs Z de type date. Cela représente potentiellement 3 fois le nombre de champs personnalisés, mais vous n'aurez plus jamais de problème de conversion.
Votre exemple ressemblerait à ceci :
Id Name field_char1 field2_char2 field_char3 ... field_num1 field_num2 ...
1 lap1 lappy lappy lappy ... 12 13
2 lap2 lappy2 lappy2 lapp2 ... 13 12
Dans votre exemple, vous avez le même nombre de valeurs numériques et de valeurs de caractères sur les deux lignes, mais il n'est pas nécessaire qu'il en soit ainsi :la troisième ligne peut ne pas avoir de champ numérique par exemple.
2. Définissez les champs X de type varchar2 et appliquez une fonction bijective pour stocker le champ de nombre ou de date (par exemple, la date peut être stockée sous la forme YYYYMMDDHH24miss ). Vous aurez également besoin d'un champ supplémentaire qui définira le contexte de la ligne. Vous appliqueriez le to_number ou to_char fonctionnent uniquement lorsque les lignes sont du bon type.
Votre exemple :
Id Name context field1 field2 field3 field4 field5
1 lap1 type A lappy lappy 12 13 lappy
2 lap2 type B lappy2 13 lappy2 lapp2 12
Vous pouvez interroger la table en utilisant DECODE ou CASE :
SELECT *
FROM laptop
WHERE CASE WHEN context = 'TYPE A' THEN to_number(field3) END = 12
La deuxième conception est celle utilisée dans l'ERP Oracle Financials (entre autres). Le contexte permet de définir des contraintes CHECK avec ce design (par exemple CHECK (CASE WHEN context = 'TYPE A' THEN to_number(field3) > 0 ) pour garantir l'intégrité.
