A la espera de Oracle Database 11g Express Edition
A raíz de la liberación de la versión definitiva de Oracle Database 11g R2, estamos a la expectativa de la eventual liberación de Express Edition 11g. Sin lugar a dudas, deberíamos esperar novedades en Oracle DB 11g XE, y como novedades no solo me refiero a las capacidades propias de Oracle Database 11g como Disparadores compuestos, columnas virtuales o el acceso a los valores de una secuencia si utilizar una sentencia SELECT, como novedades me refiero incluso al relajamiento de las restricciones de la actual XE.
Como usuario de XE no tengo quejas, es un buen producto, para las pequeñas aplicaciones que desarrollo y distribuyo las limitantes no son un obstáculo, pero, si comparamos Oracle XE con DB2 Express C, HAY UNA GRAN DISTANCIA, por ejemplo:DB2 Express C no tiene límites de almacenamiento de datos, ni de número de instancias, soporta hasta 4GB de RAM y hasta 4 procesadores con Licencia de Plazo Fijo, además, IBM con cada nueva liberación de DB2(9.5,9.7), actualiza la Edición Express C(la C indica Comunidad), situación que no ocurre con Oracle XE.
Es verdad que Oracle está más preocupado por su rendimiento económico y es lógico, pero al menos debería relajar algunas limitantes para que su producto XE (un buen producto) sea más atractivo para los desarrolladores MySQL o PostgreSQL,.
¿Qué limitantes debería relajar?
A mi criterio:
Roberto.
Nota: Son bienvendios los comentarios respetuosos.
Como usuario de XE no tengo quejas, es un buen producto, para las pequeñas aplicaciones que desarrollo y distribuyo las limitantes no son un obstáculo, pero, si comparamos Oracle XE con DB2 Express C, HAY UNA GRAN DISTANCIA, por ejemplo:DB2 Express C no tiene límites de almacenamiento de datos, ni de número de instancias, soporta hasta 4GB de RAM y hasta 4 procesadores con Licencia de Plazo Fijo, además, IBM con cada nueva liberación de DB2(9.5,9.7), actualiza la Edición Express C(la C indica Comunidad), situación que no ocurre con Oracle XE.
Es verdad que Oracle está más preocupado por su rendimiento económico y es lógico, pero al menos debería relajar algunas limitantes para que su producto XE (un buen producto) sea más atractivo para los desarrolladores MySQL o PostgreSQL,.
¿Qué limitantes debería relajar?
A mi criterio:
- 1GB de RAM. A 2GB de RAM.
- 4GB de datos. Para muchas aplicaciones es suficiente, lo reconozco, pero no vendría a menos incrementar unos cuantos GB (sería mucho pedir espacio ilimitado de almacenamiento, un límite muy criticado por los desarrolladores MySQL y PostGreSQL) quizá 8 o 10GB como lo ha hecho MS con SQL Server 2008 R2.
- Una instancia por procesador, por más de una, quizá 16 o 20 instancias.
- Soporte para plataformas de 64 bits en Windows, Linux y Unix.
- Soporte para Procedimientos Almacenados Java, aunque debería darse por descarags separadas, es decir, una imagen de descarga para 11g Express Edition y otra imagen para JVM.
Roberto.
Nota: Son bienvendios los comentarios respetuosos.
Comentarios
1)XE es el nombre de la base de datos(Instancia de BD que comprende SGA y PGA, archivos físicos asociados a sus tablespaces respectivos como SYSTEM,UNDO, TEMP, USERS).
2)XE organiza de modo lógico los objetos de bases de datos(tablas,vistas, índices, stored procedures, triggers, entre otros) para cada aplicación en esquemas(schemas) que se corresponden con el nombre de un usuario de la base de datos.
En resumen, si queremos crear tablas para una aplicación de facturación, debemos crear un esquema o usuario del mismo nombre dentro de XE.
Ejemplo:
conn system
password xyx
create user facturacion
identified by xyz
default tablespace USERS;
disc;
conn facturacion
password xyz
create table producto(
producto_id number(6) primary key,
producto_nombre varchar2(60) not null,
producto_precio number(6,3) not null
);