DB Design para almacenar campos personalizados para una tabla

Este es un problema común y no existe una solución perfecta. Un par de soluciones:

1. Defina campos X de tipo varchar2, campos Y de tipo número y campos Z de tipo fecha. Eso resulta ser potencialmente 3 veces la cantidad de campos personalizados, pero nunca más tendrá ningún problema de conversión.

Tu ejemplo quedaría así:

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

En su ejemplo, tiene la misma cantidad de valores numéricos y valores de caracteres en ambas filas, pero no tiene por qué ser así:la tercera fila podría no tener un campo numérico, por ejemplo.

2. Defina campos X de tipo varchar2 y aplique una función biyectiva para almacenar el número o el campo de fecha (por ejemplo, la fecha podría almacenarse como YYYYMMDDHH24miss ). También necesitará un campo adicional que definirá el contexto de la fila. Aplicarías el to_number o to_char funcionan solo cuando las filas son del tipo correcto.

Tu ejemplo:

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

Puede consultar la tabla usando DECODE o CASE:

SELECT * 
  FROM laptop
 WHERE CASE WHEN context = 'TYPE A' THEN to_number(field3) END = 12

El segundo diseño es el utilizado en el ERP Oracle Financials (entre otros). El contexto le permite definir restricciones CHECK con este diseño (por ejemplo, CHECK (CASE WHEN context = 'TYPE A' THEN to_number(field3) > 0 ) para garantizar la integridad.