Últimamente hay muchos medios (como SDJournal) que van haciendo eco de una nueva versión, según algunos más fácil, de SQL.
Según vemos en la página oficial del proyecto, NewSQL dispone a día de hoy de dos posibles gramáticas a implementar. Una de ellas está basada en la Java Database (JDB) y otra sería la evolución propia de SQL (SQL II, o S2). Aún no se ha decidido qué versión será la empleada como newSQL, por lo que, podemos decir que es un proyecto a futuro y no hay implementación real de momento.
Actualización 02/07/2021: revisando otro artículo posterior llegamos a otra visión diferente de NewSQL y como derivó en algo completamente diferente, recomiendo leer este otro artículo sobre NewSQL.
Implementación JDB
La sintaxis que se desea implementar al estilo JDB tendría esta forma en comparación con el SQL actual:
| SQL | NewSQL JDB |
|---|---|
|
CREATE TABLE TEST ( ID INT PRIMARY KEY, NAME VARCHAR(255) ) |
test = new table( int id, string name, key(id) ) |
| INSERT INTO TEST VALUES(1, 'Hello') | test.add(1, 'Hello') |
| SELECT * FROM TEST | test.get() |
| SELECT T1.ID, T2.NAME FROM TEST T1, TEST T2 WHERE T.ID = T2.ID | t1 = test; t2 = test; t1.join(t2[t1.id==t2.id]).get(t1.id, t2.name) |
| UPDATE TEST SET NAME='Hi' WHERE ID=1 | test[id==1].set(name='Hi') |
| DELETE FROM TEST WHERE ID=1 | test[id==1].delete() |
| DROP TABLE TEST | test.drop() |
La sintaxis puede parecer bastante clara y limpia, sobre todo para los que programan con lenguajes del estilo de Java, C++, PHP y de sintaxis derivada. No obstante, si tenemos en cuenta que esto sustituye a SQL, pero no a la forma de enviar las consultas, generar una cadena de texto de este estilo para enviarla al Sistema Gestor de Base de Datos, puede resultar bastante tedioso igualmente.
Hay bastantes dudas sobre, por ejemplo el INSERT, ya que, ahí nos muestran una inserción completa, pero, ¿y si queremos que haya datos por defecto y solo declarar algunos? Igualmente, en la cadena de búsqueda, da la sensación de haber empleado XPath para seleccionar las tuplas. ¿Cómo se haría si se busca por un criterio en lugar de un ID? Al final puede quedar algo difícil de entender, realmente.
SQL II (S2)
La otra opción, es una versión evolucionada de SQL (o simplificada, según se mire), que tiene la siguiente forma:
| SQL | NewSQL JDB |
|---|---|
|
CREATE TABLE TEST ( ID INT PRIMARY KEY, NAME VARCHAR(255) ) |
create table test ( id int; name string; primary key(id) ) |
| INSERT INTO TEST VALUES(1, 'Hello') | insert test (1, 'Hello') |
| SELECT * FROM TEST | select test |
| SELECT T1.ID, T2.NAME FROM TEST T1, TEST T2 WHERE T.ID = T2.ID | select t1:test join t2:test on t1.id == t2.id get t1.id, t2.name |
| UPDATE TEST SET NAME='Hi' WHERE ID=1 | update test set id=1 where name=='Hi' |
| DELETE FROM TEST WHERE ID=1 | delete test where id==1 |
| DROP TABLE TEST | drop test |
Revisándolo, se ve claro que no aporta mucho, realmente, a lo que se usa de hoy en día. Es más, se intenta introducir de forma fija el uso del operador == en lugar de =, lo cual resulta extraño e inapropiado, desde mi punto de vista, ya que, en todo caso, cambiaría mejor el = del UPDATE por un <-.
Conclusiones
Desde mi punto de vista, más que centrarse en cómo escribir mejor los sistemas SQL, deberían de centrarse en agregar dichas sentencias para que se mezclasen con el código, algo como SQLJ, de cara a integración con los lenguajes, y de cara al mejor uso de SQL, hacer estándares del uso de las fechas (que cada sistema los usa a su forma), así como los LIMIT, funciones básicas y tipos de datos, entre otras muchas cosas, para que los SGBD fuesen más compatibles entre ellos.
