50 años de SQL

SQL es una de las tecnologías más relevantes del mundo. Es el principal lenguaje con el que se almacena, consulta y modifica la información que sustenta a gobiernos y grandes corporaciones. Sin embargo, la historia detrás del mismo es bastante desconocida, no ya por el público general sino por los propios informáticos.

[#2 O.OOЄ]

Y 49 de No te olvides de poner el Where en el Delete From.
www.youtube.com/watch?v=i_cVJgIz_Cs

[#3 angeloso]

#2 Temazo donde los haya. Casi 1M de visualizaciones lo abalan.

[#36 RoneoaJulieta]

#3 una cosa es aValar y otra es aBalar (que también existe)

www.gciencia.com/destinos-ciencia/pedra-de-abalar-el-secreto-de-las-ro

[#51 Aokromes]

#2 x.com/iangcarroll/status/1829185249391325471

[#15 Nastar]

hace cuatro años di el salto de administrativo de logistica a un puesto de "soporte IT" donde los conocimientos técnicos eran secundarios, el conocimiento de negocio era mucho mas importante.

MI mentor, 8 años mas joven que yo, es un autentico crack de la programación, y hace birguerías con SQL, me ha enseñado un poco y ahora soy capaz de interpretar triggers, procedures, hacer pequeñas modificaciones y mis propias queries y reports....

no tengo ni puta idea de programacion pero…   

[#18 PauMarí]

#15 SQL es un lenguaje declarativo (la mayoría són imperativos) cosa que indirectamente provoca lo que dices, que "se entienda" más fácilmente solo "leyendo" el código (sin analizarlo todo, para explicarlo de alguna manera simple).

[#61 elyari]

#4 Vaya, otro programador despechado con sql, que raro. EL sequel es para lo que es, leer y escribir datos en una base de datos. Es un lenguaje muy muy robusto para lo que está pensado, funciona y funciona muy pero que muy bien para esas tareas. Si intentas ponerte a hacer otro tipo de virguerías con él pues atente a las consecuencias. Podrás meter un tornillo con un martillo, pero no es la herramienta adecuada. "Manipular objetos", "montón de dialectos y extensiones",…   

[#35 woopi]

#15 ¡Vale! Pero virguería viene de virgo. Antes se valoraban mucho y se hackeaban por manos expertas para recomponerlos cuando estaban rotos.

[#38 Nastar]

#35 cierto, no se porque pensaba que era con b, si hubiera conocido el origen etimologico no hubiera dudado

[#54 elyari]

#15 Otro que suscribe todo eso. Y yo he ido más allá, vivo de las bases de datos, soy DBA a tiempo completo desde hace más de 10 años. Se acabaron las reuniones para que el cliente diga que quiere un botón verde que le lleve a la pantalla azul para decir meses después que quería el botón verde malva y la pantalla azul turquesa (pensemos en un proyecto de meses claro). Mis "clientes" son los programadores de la empresa que me tenga contratado, y con autorización de darles una colleja por su mal código y demostrarles que lo que está mal es su código. Fui programador unos 15 años antes de pasarme a DBA, por lo que algo sé del tema.

[#6 jjara]

ohh por un momento Meneame me recordó a Barrapunto :_)

[#7 mudito]

#6 La Bonilista es quizá lo más parecido que hay ahora a Barrapunto.

Hubo un momento (al principio) que Menéame recordaba un poco a Barrapunto, básicamente porque muchos de los Barrapunteros nos pasamos a Menéame y los meneos que mandábamos eran del mismo palo.

[#12 Pingocho]

#6 #7 Aunque me gusta mucho Linux y el software libre, creo que todos debemos aceptar la realidad. En esta época ya no importa si sale KDE XP o GNOME Milenium. Cuando Linux tuvo la oportunidad de ganar un poco de mercado en el escritorio, perdió tiempo y esfuerzos duplicando el trabajo ya hecho...

[#25 Jakeukalane]

#12 menuda tontería. Además, cuando han perdido tiempo ha sido en cosas como Mir, systemd, el nuevo PulseAudio... Pero resulta que X11 era un parche sobre parche lo mismos con sysV y el server de audio.
KDE y GNOME no son tecnologías core, no son revolucionarios ni abren mercado a nuevos programas o nuevo soporte. No es por eso por lo que Linux no ha conquistado el último mercado que le queda por conquista que es el ordenador a nivel usuario doméstico y empresario...

[#28 PauMarí]

#25 Linux no ha conquistado al usuario doméstico básicamente por no tener ninguna estrategia de marketing detrás que le haga creer a la gente por un lado que necesita usar Windows sí o sí por ser la única manera de usar un ordenador y a las empresas hacerles creer que si detrás hay una empresa tendrán soporte etc (pero curiosamente nadie llama directamente a Microsoft para que le solucione algún error).
Cc #12

[#30 Pingocho]

#25 #28 Cada vez quedamos menos barrapunteros Tiempos aquellos de la verdad de la milanesa

[#37 Jakeukalane]

#28 no es por eso. Y Microsoft sí da soporte a empresas y a usuarios con licencia, estás en un error.
Linux no ha conquistado al usuario doméstico porque no tiene un stack completo sin errores, desde procesamiento de audio, imagen, servidor de video, etc.
Linux ha conquistado cosas como procesamiento de datos porque hacen eso increíblemente bien, pero el mercado cautivo (y eso es otro motivo) ha propiciado que el stack de video o audio en Linux hayan ido con mucho retraso a nivel usuario. A…   

[#39 PauMarí]

#37 perdona, yo trabajaba en IRIX antes de que existiese Linux y tenía todos los "requerimientos" que dices (y éste sólo es un ejemplo de otros muchos sistemas operativos... ¿Por cierto, que fue de OS/2, por ejemplo?
Windows es marketing, marketing y marketing (y estrategia de mercado, por ejemplo fue un acierto separar su producto del hardware y hablar con fabricantes de hardware para convencerles de que no hacia falta que hicieran software para vender su hardware), esa fue la base del éxito, merketing y estrategia de mercado.

[#49 Jakeukalane]

#39 pues ahí lo tienes. Estoy de acuerdo. Pero ahora tienen un mercado cautivo y esa misma estrategia de mercado no funcionaría.

[#55 PauMarí]

#49 de hecho en cierta manera se podría decir que Linux también "domina" gracias al merketing porqué en su día había otros sistemas operativos, p.e. BSD o Minix (que algunos quizá te dirán que eran mejores p.e. Minix no era monolítico como sí lo era Linux) pero la manera que "gestionó/vendió" Linus su proyecto lo hizo mucho más "popular" que los otros...

[#76 geburah]

#28 para tener una estrategia de marqueting hay que tener una estrategia de negocio antes que ello.

Linux NO es un producto comercial. Al menos el kernel no lo es. Y prácticamente no lo son ninguna de las distribuciones de escritorio.

El marqueting comercial de Linux ha sido para con las distribuciones y soluciones de servidor y centros de datos.

Para tener una estrategia de escritorio necesitas desarrollar una relación comercial OEM con los fabricantes. No ha habido aún ningún esfuerzo…   

[#59 tpm1]

#12 La verdad de la milanesa.

[#60 Pingocho]

#59 Ya era hora que alguien lo reconociera. Los barrapunteros ya casi nos extinguimos

[#63 pawer13]

#12 ah, la milanesa... Qué tiempos

[#68 Pingocho]

#63 Y por lo que veo en este hilo, aún funciona como trolleo

[#47 MDman]

#7 #6 Ahora ya no queda nada...hasta Hacker News da penita. ¿Alguien tiene una invitación para Lobsters?...es de los últimos refugios

[#8 pingON]

Mi proyecto personal actual en mariadb va por ...
126 tablas
1272 columnas
524 indices
27971 sentencias PL SQL
399 Procedimientos almacenados
208 funciones
792 Parámetros
303 Endpoints en api (Node.js + Express.js )

Tengo rutinas (sql) que me escriben automáticamente:
- Cascadas de borrado para cada tabla, puedo podar ramas del árbol si lo necesito
- Componentes y validadores para la api
- Rutas de la api
- Documentación automática de la api (html (estructura de menus, campos formulario y…     

[#10 Cantro]

#8 pues menos mal que es personal...

¿por qué te haces eso?

[#14 Supercinexin]

#10 ...y encima en MariaDB...

[#16 PauMarí]

#14 si al menos fuera Postgres...

[#21 pingON]

#10 #14 #16
Es personal porque no hay nadie más conmigo.

Es la automatización de la planificación para comensales y restaurantes de comidas o cenas en los restaurantes.

[#40 Supercinexin]

#21 Oye: olé tus huevos.

Hace tiempo vi un artículo nosedonde de un taller mecánico, creo que era en Polonia, cuyo dueño hace ¿30? años había aprendido a programar en C++ y se había comprado su ordenador y tal. Por supuesto como proyecto personal se hizo un programa para llevar una base de datos de sus clientes, las facturas, etcétera. Pues ahí estaba el ordenador que se compró y el programa en C++ de 30 años de historia, con todas las funcionalidades que le había ido añadiendo el buen señor con los años, conforme las iba necesitando. Informática personal en estado puro.

[#41 pingON]

#40 gracias, puede haber un buen dinero en este proyecto.

[#24 Boudleaux]

#8 superdotado o soltero?

[#26 pingON]

#24 soltero seguro, superdotado ... lo justo y necesario

[#31 xaxipiruli]

#8 cómo has sacado ese diagrama UML tan bien distribuido en el espacio?

[#33 pingON]

#31 uso dbeaver.io/
tiene un organizador automático, pero yo las reparto manualmente, genera un archivo xml y lo tengo en el git, así si siempre tengo versiones decentes  

[#4 Pingocho]

Que es el lenguaje más usado (que no el único) para la manipulación de datos y administración de base de datos, no cabe ninguna duda, y nadie le quita esa corona. Pero existen pocos lenguajes tan mal construidos como ese. Con sintaxis incoherente e inconsistente, dificultad para manipular adecuadamente objetos, un montón de dialectos y extensiones que hacen incompatibles los códigos de cada motor de base de datos, apaños cutres para adaptarlo a los tiempos actuales, y un largo etc., no se logra entender cómo ha durado tanto. Seguramente para conservar la compatibilidad con sistemas viejos y por tradición. No hay otra explicación.

[#5 Penetrator]

#4 Un respeto por el SQL, el único lenguaje antirradares de tráfico:  

[#20 sovieterrimo]

#5 Es uno de los pocos lenguajes que se inyectan.

[#13 PauMarí]

#4 seguramente hará muchas cosas pero lo que seguro que no hace es lo que dice la entradilla, almacenar datos

[#43 Joder__soy_yo]

#13 INSERT INTO.....

Yo creo que sí que almacena datos....

[#45 PauMarí]

#43 el lenguaje te aseguro que no almacena nada, en todo caso el motor de base de datos que "interpreta" dicho lenguaje sí los almacena pero eso es mérito del motor de base de datos, no del lenguaje... (y por eso el emoticono ...)

[#46 Joder__soy_yo]

#45 es verdad

[#58 sieteymedio]

#45 Y todavía te preguntas por qué no te invitan a las fiestas.

[#65 manc0ntr0]

#43 El que realmente los almacena es el microprocesador que, varias capas por debajo del SQL, está ahí el hombre ejecutando código ensamblador a golpe de reloj

[#66 Trochador]

#65 El que verdaderamente los almacena es el disco duro del equipo. El microprocesador simplemente escribe...
Hake mathe...

[#71 manc0ntr0]

#66 Mira que lo estaba pensando al escribirlo jajaja. Acepto la derrota

[#77 Trochador]

#71 Esperaba que me salieras con una réplica del tipo: No siempre, porque las copias de seguridad muchas veces se almacenan en cintas...
Que decepción...

[#95 T0nech0]

#77 Cintas?
Tarjetas perforadas no?
Si al final vas a ser más antiguo que el SQL.


Salud !!!!

[#98 Joder__soy_yo]

#95 el que de verdad almacena los datos son los bits del SSD, o las posiciones de memoria RAM si es una tabla en memoria

[#99 manc0ntr0]

#77 Na, me pillaste poco guerrillero jajaja

[#70 T0nech0]

#13 La entradilla dice: "Es el principal lenguaje con el que se almacena, consulta y modifica la información que sustenta a ..."
"con el que", no sólo "que". No es lo mismo.

Salud !!!!

[#23 paco_camps_2011]

#4 Yo lo disfruté mucho hace casi dos décadas, sacaba unas consultas súper complejas para sacar datos que en la empresa flipaban. Eso si, a la semana siguiente me preguntabas por esa consulta y era como... ¡¡Y yo que se que es eso!! Encadenaba todo en un chorizo ilegible, pero que te sacaba la estadística concreta y bastante más eficiente que cualquier otro sistema. Por suerte ya apenas lo he vuelto a tocar.

[#32 torkato]

#4 Pues... no estoy de acuerdo. He trabajado también con Mongo y ahora con Elastic y me quedo de cabeza con SQL, mejor estructurado, más fácil y más estándar.

SQL mantiene su estructura en todo momento, los otros lenguajes cada cosa es completamente diferente en sintaxis.

[#34 Pingocho]

#32 Lo estandarizado de SQL es apenas las reglas básicas para construir consultas y poco más. Pero te invito a migrar procedimientos, funciones, jobs, scripts administrativos y otros objetos de un motor a otro, para que te acuerdes de los parientes de todos aquellos que decidieron crear una variante diferente de SQL para cada motor.

Algo tan simple y mundano como obtener el último ID insertado ya es diferente en todos los dialectos. Hay dialectos que ya implementan el "IF NOT EXISTS"…   

[#50 cosmonauta]

#34 Casi todo lo que citas, no es SQL. Lógico que cueste migrar. Y poco común tener que hacerlo.

[#52 Pingocho]

#50 Si no es SQL lo que critico ¿entonces qué es?

Le contesté a un usuario que dice que SQL está estandarizado. Y eso no es cierto. SQL de estándar tiene muy poco.

[#56 cosmonauta]

#52 Perdona, te entendí mal. Como dices, el estándar se centra en pocas cosas. Stores procedures, tipos propios de un motor concreto, etc, no forman parte del lenguaje.

No tengo claro ni si el UPSET forma parte del estándar.

El lenguaje es muy bueno. Quizás en único lenguaje declarativo que se usa ampliamente. Las implementaciones... Las hay mejores y peores.

[#57 Pingocho]

#56 Lo que está estandarizado en SQL es muy poco: las instrucciones para consultas y creación de objetos básicos, permisos, procedimientos, funciones y poco más. Todo lo demás lo han ido complementando los dialectos de cada motor (T-SQL, PL/SQL, PL/pgSQL, MySQL, SQLite, para mencionar solo los más conocidos).

Por ejemplo, la instrucción que mencionas (UPSERT), aunque se supone que es estándar, no se usa en todos los dialectos. La mayoría siguen usando MERGE ( en.wikipedia.org/wiki/Merge_(SQL) ), que por cierto tampoco es soportado por todos.

A ese problema me refiero.

[#62 elyari]

#57 UPSERT y sus problemas: news.ycombinator.com/item?id=37641628
 
MERGE fue incluido en el estándar ISO SQL:2003. Pero es que justamente en el enlace que compartes de Wikipedia tienes esta frase: "Database management systems PostgreSQL,[1] Oracle Database, IBM Db2, Teradata, EXASOL, Firebird, CUBRID, H2, HSQLDB, MS SQL, Vectorwise and Apache Derby support the standard syntax. Some also add non-standard SQL extensions."
 
Es decir, hay una…   

[#67 Pingocho]

#62 Es que es precisamente esa falta de estándar lo que vengo criticando en el hilo. Solo compara con Javascript antes de la estandarización ECMAScript, que era un sindiós. Al estandarizarse se resolvieron todos los problemas de compatibilidad entre navegadores. SQL está como Javascript antes de la estandarización, y creo que ya es tarde para estandarizar el lenguaje en un solo dialecto compatible con todos los motores, así que hay que seguir con lo que hay.

[#64 elyari]

#52 SI está estandarizado, existen normas ANSI/ISO muy bien documentadas al respecto. Lo que pasa es que luego hay implementaciones NO ESTANDARES en diferentes plataformas y ahí es donde está el problema. Por lo que sequel sí que es estándar.

[#88 Penetrator]

#52 El lenguaje SQL está perfectamente estandarizado, igual que muchos otros lenguajes. Otra cosa es que los motores de base de datos implementen el estándar o lo que les salga de los cojones. Igual que pasó en su momento con el HTLM/CSS y el puto Internet Explorer.

[#91 Pingocho]

#88 La comparación con HTML/CSS es precisa. En otro comentario comparo el estado actual de SQL con Javascript antes del estándar ECMAScript. El estándar SQL es muy limitado, por lo que los diferentes motores han implementado sus propias soluciones incompatibles entre sí. Que sí, que eso no es SQL estándar, lo sabemos, pero el usar SQL de forma avanzada (en procedimientos o usando cursores, por ejemplo) ya te obliga a tener mejores estructuras como condicionales y ciclos. El estándar SQL se quedó corto y atrasado en eso.

[#75 KaisserSozze]

#32 Es la diferencia entre bases de datos orientadas a OLAP y orientadas a OLTP. Lo bueno y lo malo de las NoSQL (que suelen estar orientadas a OLTP) es que suelen ser desestructuradas y te permiten meter datos a cascoporro, te da igual la estructura, la integridad de los datos, etc. ya que no tienen esquemas. Si quieres eso te lo curras tú por otro lado. Para cada problema su herramienta.
De hecho ya hace años vengo trabajando con NoSQL para entrada de datos, ya que muchas son amigables con…   

[#80 mre13185]

#32 Lo de indexar la información y relacionar colecciones (que en SQL son tablas) a través de sus índices, en Mongo como que imposible. En eso SQL todavía sigue siendo más eficiente. Puedes aumentar el tamaño de la colección o tabla sin que se varíe la velocidad de acceso, cosa que en Mongo con colecciones muy grandes ya es poco eficiente.

[#73 SlurmM]

#4 SQL no es un lenguaje. No cumple los requisitos, no tiene sentencias de control de flujo.....

[#78 paco_camps_2011]

#73 Si SQL no es un lenguaje entonces sería SQ.

Pongamos que todo internet está equivocado y no lo es, ¿qué es un lenguaje en informática?
Según la Wikipedia:

Un lenguaje de programación es un lenguaje formal (o artificial, es decir, un lenguaje con reglas gramaticales bien definidas) que proporciona a una persona, en este caso el programador, la capacidad y habilidad de escribir (o programar) una serie de instrucciones o secuencias de órdenes en forma de algoritmos con el fin de controlar

…   

[#85 SlurmM]

#78 El ejemplo que pones del CASE no supone control de flujo del programa, sino es una manera de presentar distintos supuestos dentro de una consulta SQL específica, pero a esa sentencia SQL se ha llegado a través de un flujo presente en un programa.
Por ejemplo, java es un lenguaje de programación que usa SQL para interrogar a la base de datos. Java es un lenguaje de programación, SQL es un lenguaje de interrogación a las bases de datos, pero no un lenguaje de programación.

[#87 SlurmM]

#85 #84 En mi comentario quería decir que no es un lenguaje de PROGRAMACIÓN, sí es un lenguaje, pero no de programación.

[#82 Pingocho]

#73 “no tiene sentencias de control de flujo”

Tiene IF, WHILE, procedimientos, funciones y hasta bloques TRY/CATCH. Claro, depende de cada implementación (dialecto).

[#84 SlurmM]

#82 No, eso no es SQL

[#86 SlurmM]

#84 En mi comentario quería decir que no es un lenguaje de PROGRAMACIÓN, sí es un lenguaje, pero no de programación.

[#90 Pingocho]

#86 El solo hecho de usar un cursor ya te obliga a usar alguna estructura para controlar el ciclo (por ejemplo, WHILE). El estándar de SQL es muy limitado, así que cada implementación optó por hacer sus propias instrucciones que no son compatibles entre sí, ya que no están estandarizadas. Por eso digo que es más o menos lo que ocurría con Javascript antes del estándar ECMAScript.

[#97 IngridPared]

#90 Creo que ya sé en qué te equivocas. Confundes SQL con los lenguajes de programación creados para usar SQL en cada gestor de base de datos, como pueden ser PL/SQL en Oracle o Tansact SQL en SQL Server. Por eso hablas de dialectos y de instrucciones de flujo de datos.

[#89 Penetrator]

#73 Lenguaje es. Lo que pasa es que no es Turing completo.

[#93 SlurmM]

#89 lenguaje sí. Pero no lenguaje de programación, que es lo que quería decir.

[#79 mre13185]

#4 Pues lo mismo que el COBOL.

[#83 Pingocho]

#79 Sí, pero a Cobol sí se le ha relegado a donde debería estar SQL: en nichos específicos donde se mantiene por pura compatibilidad de sistemas viejos.

[#81 lorne_malvo]

#4 La sintaxis es totalmente coherente, existe un bonito estándar. Que luego cada cual lo implemente y cambie a su gusto no es culpa del lenguaje. Y hasta donde yo se Postgresql lo sigue al dedillo. De hecho discrepo que este tan mal construido y sistemas actuales como Snowflake lo utilizan. CipherQL, MQL o EQL son bastantes insufribles (cualquier cosa basada en JSON vaya) por poner ejemplos de cosas nuevas. Y para pegarse un tiro Datalog.

[#96 IngridPared]

#4 ¿Sintaxis incoherente e inconsistente? ¿un montón de dialectos? ¿Apaños cutres? Creo que no has usado SQL en tu vida, que todo eso te lo ha dicho tu cuñado.

[#17 paco_camps_2011]

comment_minimal_length'; DROP DATABASE meneame; --

[#74 mecha]

#17 tu eres el padre de bobby, no?

[#92 leviatan]

SQL está bien, tiene sus usos, especialmente si tienes control de los datos, aunque en la vida real no suele ser el caso. Lo asombroso es que las BBDD SQL están tan optimizadas que su motor y lenguaje están detrás de algunas BBDD NoSQL.

Lo que no recomiendo en absoluto son las tecnologías ORM, especialmente si son cajas negras, esas sí que han hecho mucha pupa.

[#94 MANOLO_HARD]

Si PL - SQL
 
Ese pelito....ese culito?!!?
 
 
Perdón, me he equivocado. No volverá a ocurrir 

[#1 cenutrios_unidos]

Y el año que viene...

[#19 ikipol]

#1 pues...51

[#9 sauron34_1]

50 años amargando vidas.

[#11 MIrahigos]

#9 50 años haciendo la vida más simple.

[#22 PauMarí]

#11 depende de si pones EXPLAIN delante o no...

[#44 sauron34_1]

#11 entiéndeme, es que para un programador estar pensando en objetos y de repente tener que pasar a un enfoque relacional… nos cuesta

[#53 MIrahigos]

#44 No me jodas.

[#72 sauron34_1]

#69 #53 #48 pues hijos, soy raritu, yo qué sé

[#69 UnoYDos]

#44 En serio? Yo me dedico a la POO y no tiene nada de complicado. Por no hablar que tiene infinidad de motores de persistencia, como las muchas implementaciones de JPA en Java. Puedes declarar las entidades y relaciones en tus objetos y generar la estructura de base de datos con esa declaraciones de manera automática.

[#48 elyari]

#9 Pues a mi todo lo contrario, me la alegra cada día.
PS: soy senior DevOps DBA

[#27 neo1999]

#4Edit, leí más abajo tu otro comentario

[#29 xaxipiruli]

postgres con pgvector

[#42 nosomosnaiderl]

Sícuel !!