Questo è un problema comune e non esiste una soluzione perfetta. Un paio di soluzioni:
1. Definire X campi di tipo varchar2, Y campi di tipo numero e Z campi di tipo data. Questo risulta essere potenzialmente 3 volte il numero di campi personalizzati, ma non avrai più problemi di conversione.
Il tuo esempio verrebbe così:
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
Nel tuo esempio hai lo stesso numero di valori numerici e valori di caratteri su entrambe le righe, ma non deve essere così:la terza riga potrebbe non avere un campo numerico, ad esempio.
2. Definisci X campi di tipo varchar2 e applica una funzione biiettiva per memorizzare il campo numero o data (ad esempio la data potrebbe essere memorizzata come YYYYMMDDHH24miss ). Avrai anche bisogno di un campo aggiuntivo che definirà il contesto della riga. Dovresti applicare il to_number o to_char funzionano solo quando le righe sono di tipo buono.
Il tuo esempio:
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
Puoi interrogare la tabella usando DECODE o CASE:
SELECT *
FROM laptop
WHERE CASE WHEN context = 'TYPE A' THEN to_number(field3) END = 12
Il secondo design è quello utilizzato in Oracle Financials ERP (tra gli altri). Il contesto consente di definire i vincoli CHECK con questo progetto (ad esempio CHECK (CASE WHEN context = 'TYPE A' THEN to_number(field3) > 0 ) per garantire l'integrità.
