T1.2: Designs Advanced Schemas

Tipo de Datos %Date

El tipo de datos %Date almacena valores solo de fecha con una representación lógica como un entero que representa el número de días desde el 31 de diciembre de 1840 (día 0).

• Formato de almacenamiento: Representación entera compacta
• Rango de fechas: Soporta fechas desde 0001-01-01 hasta 9999-12-31
• Fechas anteriores a 1840: La época (día 0) es 1840-12-31, pero el entero tiene signo — las fechas anteriores a 1840-12-31 se almacenan como número de días negativo. Por ejemplo, 0001-01-01 corresponde aproximadamente al día -671.861. Por eso el rango soportado se extiende mucho antes de 1840.
• Formato de visualización: Formatos específicos de configuración regional o formato ODBC (YYYY-MM-DD)
• SqlCategory: DATE

Tipo de Datos %Time

El tipo de datos %Time representa valores de hora del día, almacenando el valor lógico como el número de segundos pasados desde medianoche.

• Rango de valores: 0 a 86399 segundos
• Formato de visualización: HH:MM:SS
• SqlCategory: TIME
• Caso de uso: Aritmética y comparaciones de tiempo eficientes

Tipo de Datos %TimeStamp

El tipo de datos %TimeStamp combina componentes de fecha y hora en un solo valor.

• Formato: YYYY-MM-DD HH:MM:SS.nnnnnnnnn
• Precisión: Hasta nueve dígitos de segundos fraccionarios
• Conversión: Valor lógico obtenido del formato $HOROLOG usando $ZDATETIME(h,3)
• SqlCategory: TIMESTAMP
• Caso de uso: Registrar momentos exactos en el tiempo (formato de marca de tiempo ODBC estándar)

Tipo de Datos %PosixTime

El tipo de datos %PosixTime ofrece una representación alternativa de marca de tiempo usando codificación de época Unix.

• Almacenamiento: Entero con signo codificado de 64 bits que representa segundos transcurridos con precisión de microsegundos
• Época: 1970-01-01 00:00:00 (época Unix, NO la época 1840 de %Date). La forma codificada en la época es 1152921504606846976; la codificación empaqueta el signo, los segundos y los microsegundos en 64 bits.
• Rango de fechas: 0001-01-01 a 9999-12-31 (el mismo rango que otros tipos temporales, logrado mediante el rango del entero de 64 bits con signo)
• Precisión: Exactamente 6 dígitos de segundos fraccionarios (microsegundos)
• SqlCategory: POSIXTS
• Nota: Las fechas anteriores a 1970 se codifican con valores con signo negativo. %PosixTime y %Date usan épocas diferentes, por lo que no se debe convertir entre ellas restando valores; usar TO_POSIXTIME() / TO_DATE() para conversiones correctas.

SqlCategory y Conversión de Tipos

Cada tipo de datos tiene una clasificación SqlCategory distinta que controla operaciones de comparación.

• Funciones de conversión: Usar DATE(), TO_TIMESTAMP(), o TO_POSIXTIME() al mezclar tipos temporales en comparaciones o índices
• Impacto en diseño de esquema: La elección del tipo de datos temporal afecta la eficiencia de almacenamiento, rendimiento de consultas e interoperabilidad con sistemas externos
• Recomendaciones:
• %Date y %Time: Almacenamiento más compacto para valores solo de fecha u hora
• %TimeStamp: Marcas de tiempo de precisión legibles por humanos
• %PosixTime: Compatibilidad con marcas de tiempo Unix y cálculos temporales de alta precisión

list Of %String — almacenamiento en línea

Class App.Patient Extends %Persistent {
  Property Name As %String;
  Property Allergies As list Of %String;
}

Vista SQL de la tabla:

ID	Name	Allergies
1	Smith	$LB("Penicilina","Maní")

La columna Allergies contiene el blob codificado con $LISTBUILD directamente; no hay tabla hija. Para buscar:

SELECT ID, Name FROM App.Patient
 WHERE FOR SOME %ELEMENT(Allergies) (%Value = 'Penicilina')

array Of %String — almacenamiento en tabla hija

Class App.Patient Extends %Persistent {
  Property Name As %String;
  Property Phones As array Of %String;
}

IRIS crea una tabla hija App.Patient_Phones con columnas (Patient, element_key, Phones). Cada teléfono es una fila. JOIN/WHERE estándar funcionan sobre la tabla hija.

Comparación

Aspecto	list Of	array Of
Almacenamiento SQL	columna en línea, codificada $LISTBUILD	tabla hija separada
Tiene clave	posicional (ordinal)	con clave (arbitraria por elemento)
Uso típico	multi-valor pequeño y fijo (alergias, etiquetas)	atributos con clave (teléfonos por tipo)
Búsqueda	FOR SOME %ELEMENT	JOIN sobre tabla hija
Indexado	índice de elemento de colección sobre el padre	índice sobre la tabla hija

Class App.Address Extends %SerialObject {
  Property Street As %String;
  Property City As %String;
}

Class App.Person Extends %Persistent {
  Property Name As %String;
  Property HomeAddress As App.Address;
}

Proyección SQL de App.Person:

ID	Name	HomeAddress_Street	HomeAddress_City
1	Smith	Calle Mayor 42	Madrid

Para consultar un campo interno: SELECT Name, HomeAddress_City FROM App.Person. Las columnas aplanadas con guión bajo son direccionables desde SQL; la clase App.Address en sí no es una tabla.

Class App.Document Extends %Persistent {
  Property Title As %String;
  Property Content As %Stream.GlobalCharacter;
  Index ci On (Content) As %iFind.Index.Basic;
}

Operaciones típicas:

-- OK: recuperar stream (el cliente ensambla el stream desde el cursor)
SELECT Title, Content FROM App.Document WHERE ID = 1

-- NO soportado: WHERE sobre columna stream directamente
SELECT * FROM App.Document WHERE Content LIKE '%confidencial%'   -- error o resultados incorrectos

-- Forma correcta: %CONTAINS con índice iFind
SELECT ID, Title FROM App.Document WHERE %ID %FIND search_index(ci, 'confidencial')

// FullName — siempre fresco, recomputado en lectura, no indexable
Property FullName As %String [ Calculated,
  SqlComputeCode = {Set {*} = {FirstName}_" "_{LastName}},
  SqlComputed ];

// Age — almacenado, auto-actualizado cuando cambia DateOfBirth, indexable
Property Age As %Integer [
  SqlComputed,
  SqlComputeCode = {Set {*} = $SYSTEM.SQL.Functions.DATEDIFF("yy",{DateOfBirth},$HOROLOG)},
  SqlComputeOnChange = DateOfBirth ];
Index AgeIdx On Age;

Para una tabla de 10M filas consultada frecuentemente con WHERE Age = 30, la segunda forma es correcta — el valor computado se materializa en la fila, y un índice sobre Age hace que la búsqueda sea O(log n) en lugar de full table scan.

El almacenamiento columnar se configura directamente en DDL — no hace falta una definición de clase.

-- Mixto: tabla row-storage con columnas en columnar para las que dirigen la agregación
CREATE TABLE App.Sale (
  OrderId  INTEGER PRIMARY KEY,
  RegionId INTEGER,
  Amount   NUMERIC(18,2) WITH STORAGETYPE = COLUMNAR,
  Quantity INTEGER       WITH STORAGETYPE = COLUMNAR
);

-- Tabla totalmente columnar — cargas analíticas puras
CREATE TABLE App.SalesFact (
  Id       BIGINT PRIMARY KEY,
  RegionId INTEGER,
  Amount   NUMERIC(18,2),
  Quantity INTEGER
) WITH STORAGETYPE = COLUMNAR;

-- Añadir una nueva columna columnar a una tabla existente
ALTER TABLE App.Sale ADD COLUMN Discount NUMERIC(18,2) WITH STORAGETYPE = COLUMNAR;

El mismo efecto se puede expresar en una definición de clase ObjectScript (Property Amount As %Numeric(SCALE=2) [ Columnar ] para una columna, o el flag [ StorageStrategy = Columnar ] a nivel de clase para una tabla totalmente columnar) — ambos caminos producen el mismo layout físico.

Class App.Order Extends %Persistent [ VersionProperty = Version ] {
  Property Quantity As %Integer;
  Property Version As %Integer [ InitialExpression = 0 ];
}

Patrón de aplicación:

-- Lectura
SELECT Quantity, Version INTO :qty, :ver FROM App.Order WHERE ID = :id

-- ... el usuario edita ...

-- Update protegido por la versión
UPDATE App.Order SET Quantity = :newQty WHERE ID = :id AND Version = :ver
IF %ROWCOUNT = 0 THEN
   -- lost-update: otra sesión modificó la fila
END