Respetuosamente, si Epic tiene una limitación de 1000 caracteres, entonces el culpable más probable es el lenguaje de programación MUMPS con el que entiendo que se desarrolló Epic. No tiene nada que ver con el backend RDBMS.
Una pequeña historia:
MUMPS se desarrolló a mediados de la década de 1960 como un lenguaje de programación de cuidado de la salud interpretado, multitarea y multiusuario con una base de datos jerárquica incrustada que almacenaba sus datos en arrays dispersos persistentes, una solución elegante a las limitaciones de las arquitecturas de máquinas de esa época. MUMPS se convirtió en el lenguaje de desarrollo de facto para las aplicaciones de cuidado de la salud de los años 1960 y 1970, al igual que COBOL, que se desarrolló a fines de la década de 1950, se convirtió en el lenguaje de programación de negocios de facto de esa época.
Actualmente, muchos sistemas de información de atención médica en uso se basan en MUMPS: el EMR VistA desplegado por la Administración de Veteranos, el Sistema Compuesto de Atención Médica (CHCS) del Departamento de Defensa diseñado por SAIC a un costo de más de $ 2 mil millones y el SunQuest LIS (clínica sistema de información de laboratorio) utilizado por muchos de los laboratorios de referencia clínica en el país, incluidos Stanford, TriCore, PAML y Quest.
Fui director de inteligencia de negocios para un laboratorio regional de referencia clínica que usa SunQuest, y mi mayor desafío fue trabajar para compensar las limitaciones de los componentes internos de MUMP de SunQuest LIS.
El límite de 1.000 caracteres no es el único muro que los ingenieros de software han atacado con MUMPS. La estructura jerárquica de la base de datos utilizada por MUMPS presenta problemas importantes de almacenamiento y recuperación de información, almacenamiento de datos y análisis clínicos, que se abordaron en 1970 cuando EF Codd publicó su artículo seminal que describe el modelo relacional.