Dies ist ein häufiges Problem und es gibt keine perfekte Lösung. Ein paar Lösungen:
1. Definieren Sie X-Felder vom Typ varchar2, Y-Felder vom Typ Zahl und Z-Felder vom Typ Datum. Das entspricht möglicherweise der dreifachen Anzahl von benutzerdefinierten Feldern, aber Sie werden nie mehr Konvertierungsprobleme haben.
Ihr Beispiel würde so aussehen:
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
In Ihrem Beispiel haben Sie in beiden Zeilen die gleiche Anzahl numerischer Werte und Zeichenwerte, aber das muss nicht so sein:Die dritte Zeile könnte zum Beispiel kein numerisches Feld haben.
2. Definieren Sie X-Felder vom Typ varchar2 und wenden Sie eine bijektive Funktion an, um Zahlen- oder Datumsfelder zu speichern (Beispiel:Datum könnte als YYYYMMDDHH24miss gespeichert werden ). Sie benötigen außerdem ein zusätzliches Feld, das den Kontext der Zeile definiert. Sie würden den to_number anwenden oder to_char funktionieren nur, wenn die Zeilen vom guten Typ sind.
Ihr Beispiel:
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
Sie könnten die Tabelle mit DECODE oder CASE abfragen:
SELECT *
FROM laptop
WHERE CASE WHEN context = 'TYPE A' THEN to_number(field3) END = 12
Das zweite Design ist dasjenige, das (unter anderem) in Oracle Financials ERP verwendet wird. Der Kontext ermöglicht es Ihnen, CHECK-Einschränkungen mit diesem Design zu definieren (zum Beispiel CHECK (CASE WHEN context = 'TYPE A' THEN to_number(field3) > 0 ), um die Integrität zu gewährleisten.
