Portada
mis comunidades
otras secciones
#2:
Y 49 de No te olvides de poner el Where en el Delete From.
https://www.youtube.com/watch?v=i_cVJgIz_Cs
https://www.youtube.com/watch?v=i_cVJgIz_Cs
#15:
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 suscribo la parte del articulo en la que dice que es entendible por cualquier oficinista...
gracias a lo que aprendí sigo en el sector de IT, con un salario mucho mayor al que tenía en el sector transitario, gracias todo a mi jefe y al sql, asi que feliz cumpleaños!
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 suscribo la parte del articulo en la que dice que es entendible por cualquier oficinista...
gracias a lo que aprendí sigo en el sector de IT, con un salario mucho mayor al que tenía en el sector transitario, gracias todo a mi jefe y al sql, asi que feliz cumpleaños!
#40:
#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.
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.
#8:
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 esquemas de llamada y json devuelto))
- Componentes básicos de vue 3 para la interfaz de usuario
- Modulos de Pinia con todas las llamadas de la api con los endpoints y parámetros correctos para cada llamada
- Colección automática de postman para todas las llamadas de la api, estructuradas según definición de la interfaz de usuario
- Documento de nomenclatura estandarizada para todo el proyecto
- Definición de todas la parametrización de llamada a cada rutina
- Árbol de ejecución completo para cada rutina
- Para cada tabla puedo saber que rutinas la tocan y si es CREATE, UPDATE, READ, DELETE
- Para cada tabla puedo crear un procedimiento básico de CUD
- Se inspecciona automáticamente todo el código de las rutinas de la base de datos y se crean todos los índices automáticamente.
.......
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 esquemas de llamada y json devuelto))
- Componentes básicos de vue 3 para la interfaz de usuario
- Modulos de Pinia con todas las llamadas de la api con los endpoints y parámetros correctos para cada llamada
- Colección automática de postman para todas las llamadas de la api, estructuradas según definición de la interfaz de usuario
- Documento de nomenclatura estandarizada para todo el proyecto
- Definición de todas la parametrización de llamada a cada rutina
- Árbol de ejecución completo para cada rutina
- Para cada tabla puedo saber que rutinas la tocan y si es CREATE, UPDATE, READ, DELETE
- Para cada tabla puedo crear un procedimiento básico de CUD
- Se inspecciona automáticamente todo el código de las rutinas de la base de datos y se crean todos los índices automáticamente.
.......
#61:
#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", "paños cutres"... no estás hablando de sql, eso es seguro. Seguramente para conservar la compabitibilidad con sistemas viejos y por tradición... cada vez que escucho esto me parto de risa.
Llevo unos 25 años viviendo de la informática. De ellos unos 12 fui programador (soy viejuno, aprendí a programar con MSX Basic, en mi primer curro usé Turbo Pascal + dBase, luego usé Delphi, no le hacía ascos a C++ / Ensamblador y toqué también Java, Magento y algunas cosillas más en los últimos años que aún mi pueso ponía programador). Pero me gustaban las consultas sql y tenía curiosidad por como hacerlas más rápidas y optimizarlas. Eso me llevo poco a poco a ser el que sin querer se encargaba de las bases de datos, a esto le llaman "Accidental DBA" en el gremio. Porque, al igual que hoy, ya hace 20 años muchos programadores decía que era aburrido y antiguo y blablabla. Y tras par de años así decidí dar el salto y pasé a ser DBA a tiempo completo. Unos 10 años después no puedo estar más contento, soy DBA a tiempo completo y sequel me da de comer.
Va parrafada.
La raíz de sql está en lo tan bien pensado que está para trabajar con conjuntos de datos relacionales, y a su vez está basado en el álgebra booleana y conceptos matemáticos fundamentales y básicos. Sequel es un lenguaje declarativo abstracto (ya lo dijo #18) que permite acceder a conjuntos lógicos de datos independientemente de como están almacenado físicamente. Precisamente por su implementación basada en conceptos de la teoría de conjunto y álgebra booleana puedes lograr operaciones matemáticas cerrada* y aplicar operaciones relacionales sobre el conjunto resultado. Esto se traduce en una potencia impresionante para la manipulación de conjuntos y por ende la extracción de datos de una base de datos de una manera muy eficiente. Si me dieran un céntimo por cada vez que he visto a un programador usar RBAR (Row By Agonizing Row) para acceder y manipular datos, sería millonario.
Luego ya tienes que justamente por los años que lleva usándose es ubicuo en la industria, es muy muy robusto y tiene pocas vulnerabilidades (sql injection no es problema de sequel, es problema de los programadores que no saben usarlo). Tienes bases datos como Oracle, MS SQL Server, Postgresql, MySQL y similares que llevan décadas en el mercado y por tanto multitud de personas que están familiarizados con la sintaxis y conceptos del lenguaje, que a su vez facilita la incorporación de nuevas personas al equipo así como el mantenimiento y/o administración de sistemas basados en estas bases de datos.
No sé si te suena el standard ANSI/ISO, para muchos eso es "burocracia", pero resulta que sequel es el lenguaje "de facto" utilizado en la industria para acceder a datos. Y justamente por respetar esos estándares y el que los cambios que se hacen se hacen con mucho cuidado, es completamente "backwards compatible". Para tí quizás sea "por tradición" pero ya me dirás porqué los bancos usan COBOL (y no, no es por "tradición").
Y para rematar, ACID.
Y podría seguir pero para qué. Si a mi lo que me interesa es que la gente reniegue del sequel y las bases de datos relacionales, me va de maravilla, más oportunidades pa'mi y seguridad de que los próximos 20 años no me faltará curro optimizando las cagadas de los que no les interesa aprender un poco de sequel.
Definición: cerrado (en una operación) Describe un conjunto para el cual una operación dada (como la suma y la multiplicación) da un resultado que también es miembro del mismo conjunto.
Llevo unos 25 años viviendo de la informática. De ellos unos 12 fui programador (soy viejuno, aprendí a programar con MSX Basic, en mi primer curro usé Turbo Pascal + dBase, luego usé Delphi, no le hacía ascos a C++ / Ensamblador y toqué también Java, Magento y algunas cosillas más en los últimos años que aún mi pueso ponía programador). Pero me gustaban las consultas sql y tenía curiosidad por como hacerlas más rápidas y optimizarlas. Eso me llevo poco a poco a ser el que sin querer se encargaba de las bases de datos, a esto le llaman "Accidental DBA" en el gremio. Porque, al igual que hoy, ya hace 20 años muchos programadores decía que era aburrido y antiguo y blablabla. Y tras par de años así decidí dar el salto y pasé a ser DBA a tiempo completo. Unos 10 años después no puedo estar más contento, soy DBA a tiempo completo y sequel me da de comer.
Va parrafada.
La raíz de sql está en lo tan bien pensado que está para trabajar con conjuntos de datos relacionales, y a su vez está basado en el álgebra booleana y conceptos matemáticos fundamentales y básicos. Sequel es un lenguaje declarativo abstracto (ya lo dijo #18) que permite acceder a conjuntos lógicos de datos independientemente de como están almacenado físicamente. Precisamente por su implementación basada en conceptos de la teoría de conjunto y álgebra booleana puedes lograr operaciones matemáticas cerrada* y aplicar operaciones relacionales sobre el conjunto resultado. Esto se traduce en una potencia impresionante para la manipulación de conjuntos y por ende la extracción de datos de una base de datos de una manera muy eficiente. Si me dieran un céntimo por cada vez que he visto a un programador usar RBAR (Row By Agonizing Row) para acceder y manipular datos, sería millonario.
Luego ya tienes que justamente por los años que lleva usándose es ubicuo en la industria, es muy muy robusto y tiene pocas vulnerabilidades (sql injection no es problema de sequel, es problema de los programadores que no saben usarlo). Tienes bases datos como Oracle, MS SQL Server, Postgresql, MySQL y similares que llevan décadas en el mercado y por tanto multitud de personas que están familiarizados con la sintaxis y conceptos del lenguaje, que a su vez facilita la incorporación de nuevas personas al equipo así como el mantenimiento y/o administración de sistemas basados en estas bases de datos.
No sé si te suena el standard ANSI/ISO, para muchos eso es "burocracia", pero resulta que sequel es el lenguaje "de facto" utilizado en la industria para acceder a datos. Y justamente por respetar esos estándares y el que los cambios que se hacen se hacen con mucho cuidado, es completamente "backwards compatible". Para tí quizás sea "por tradición" pero ya me dirás porqué los bancos usan COBOL (y no, no es por "tradición").
Y para rematar, ACID.
Y podría seguir pero para qué. Si a mi lo que me interesa es que la gente reniegue del sequel y las bases de datos relacionales, me va de maravilla, más oportunidades pa'mi y seguridad de que los próximos 20 años no me faltará curro optimizando las cagadas de los que no les interesa aprender un poco de sequel.
Definición: cerrado (en una operación) Describe un conjunto para el cual una operación dada (como la suma y la multiplicación) da un resultado que también es miembro del mismo conjunto.
#4:
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.
Comentarios
Y 49 de No te olvides de poner el Where en el Delete From.
#2 Temazo donde los haya. Casi 1M de visualizaciones lo abalan.
#3 una cosa es aValar y otra es aBalar (que también existe)
https://www.gciencia.com/destinos-ciencia/pedra-de-abalar-el-secreto-de-las-rocas-magicas/
#2
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 suscribo la parte del articulo en la que dice que es entendible por cualquier oficinista...
gracias a lo que aprendí sigo en el sector de IT, con un salario mucho mayor al que tenía en el sector transitario, gracias todo a mi jefe y al sql, asi que feliz cumpleaños!
#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).
#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", "paños cutres"... no estás hablando de sql, eso es seguro. Seguramente para conservar la compabitibilidad con sistemas viejos y por tradición... cada vez que escucho esto me parto de risa.
Llevo unos 25 años viviendo de la informática. De ellos unos 12 fui programador (soy viejuno, aprendí a programar con MSX Basic, en mi primer curro usé Turbo Pascal + dBase, luego usé Delphi, no le hacía ascos a C++ / Ensamblador y toqué también Java, Magento y algunas cosillas más en los últimos años que aún mi pueso ponía programador). Pero me gustaban las consultas sql y tenía curiosidad por como hacerlas más rápidas y optimizarlas. Eso me llevo poco a poco a ser el que sin querer se encargaba de las bases de datos, a esto le llaman "Accidental DBA" en el gremio. Porque, al igual que hoy, ya hace 20 años muchos programadores decía que era aburrido y antiguo y blablabla. Y tras par de años así decidí dar el salto y pasé a ser DBA a tiempo completo. Unos 10 años después no puedo estar más contento, soy DBA a tiempo completo y sequel me da de comer.
Va parrafada.
La raíz de sql está en lo tan bien pensado que está para trabajar con conjuntos de datos relacionales, y a su vez está basado en el álgebra booleana y conceptos matemáticos fundamentales y básicos. Sequel es un lenguaje declarativo abstracto (ya lo dijo #18) que permite acceder a conjuntos lógicos de datos independientemente de como están almacenado físicamente. Precisamente por su implementación basada en conceptos de la teoría de conjunto y álgebra booleana puedes lograr operaciones matemáticas cerrada* y aplicar operaciones relacionales sobre el conjunto resultado. Esto se traduce en una potencia impresionante para la manipulación de conjuntos y por ende la extracción de datos de una base de datos de una manera muy eficiente. Si me dieran un céntimo por cada vez que he visto a un programador usar RBAR (Row By Agonizing Row) para acceder y manipular datos, sería millonario.
Luego ya tienes que justamente por los años que lleva usándose es ubicuo en la industria, es muy muy robusto y tiene pocas vulnerabilidades (sql injection no es problema de sequel, es problema de los programadores que no saben usarlo). Tienes bases datos como Oracle, MS SQL Server, Postgresql, MySQL y similares que llevan décadas en el mercado y por tanto multitud de personas que están familiarizados con la sintaxis y conceptos del lenguaje, que a su vez facilita la incorporación de nuevas personas al equipo así como el mantenimiento y/o administración de sistemas basados en estas bases de datos.
No sé si te suena el standard ANSI/ISO, para muchos eso es "burocracia", pero resulta que sequel es el lenguaje "de facto" utilizado en la industria para acceder a datos. Y justamente por respetar esos estándares y el que los cambios que se hacen se hacen con mucho cuidado, es completamente "backwards compatible". Para tí quizás sea "por tradición" pero ya me dirás porqué los bancos usan COBOL (y no, no es por "tradición").
Y para rematar, ACID.
Y podría seguir pero para qué. Si a mi lo que me interesa es que la gente reniegue del sequel y las bases de datos relacionales, me va de maravilla, más oportunidades pa'mi y seguridad de que los próximos 20 años no me faltará curro optimizando las cagadas de los que no les interesa aprender un poco de sequel.
Definición: cerrado (en una operación) Describe un conjunto para el cual una operación dada (como la suma y la multiplicación) da un resultado que también es miembro del mismo conjunto.
#15 ¡Vale! Pero virguería viene de virgo. Antes se valoraban mucho y se hackeaban por manos expertas para recomponerlos cuando estaban rotos.
#35 cierto, no se porque pensaba que era con b, si hubiera conocido el origen etimologico no hubiera dudado
#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.
ohh por un momento Meneame me recordó a Barrapunto :_)
#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.
#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...
#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...
#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
#25 #28 Cada vez quedamos menos barrapunteros
Tiempos aquellos de la verdad de la milanesa 
#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 nivel avanzado aún quedan cosas pero las empresas y emprendedores prefieren Linux en gran cantidad.
GNOMe vs KDE o que exista RedHat/Fedora/Alma/Rocky/Ubuntu (que por cierto RH y Ubuntu sí hacen todo lo que tú dices y por eso destacan tanto) no ha provocado un freno en el desarrollo e implantación de Linux. Al contrario.
Lo que frena es la falta de software o la incompatibilidad (cada vez menos de tecnología y más porcentaje por programas anticuados o no, a los que está atada la gente).
Yo acabo de instalar hoy tres servidores. Dos con Ubuntu y uno con DGX OS que es de Nvidia (base Ubuntu).
#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.
#39 pues ahí lo tienes. Estoy de acuerdo. Pero ahora tienen un mercado cautivo y esa misma estrategia de mercado no funcionaría.
#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...
#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 real en ello, el mercado está copado por MS y solo se puede entrar con algo revolucionario o con un gran pastizal.
Linux como SO para servidor si que fue revolucionario y desplazó a Unix, donde MS Windows nunca tuvo una cuota relevante.
En resumen, MS se metió de llevo en el escritorio en el momento que este crecía, ahora solo se puede esperar a que muera o que alguna empresa se plantee seriamente entrar a distribuir Linux dese OEM. Tal vez Valve?
Y si, hay una cuantas empresas que ofrecen portátiles con Linux y están muy bien. Pero son pequeñas.
Y al escritorio hay que darle un par de pulidos y unificar un poco más ciertos aspectos. El gran problema es el soporte a usuarios, de hecho.
Si cada usuario de Linux tiene un escritorio diferente, nadie va a poder darle soporte. Hay maneras de unificar el soporte a escritorio, pero antes los grandes se han de poner de acuerdo.
#12 La verdad de la milanesa.
#59 Ya era hora que alguien lo reconociera. Los barrapunteros ya casi nos extinguimos
#12 ah, la milanesa... Qué tiempos
#63 Y por lo que veo en este hilo, aún funciona como trolleo
#7 #6 Ahora ya no queda nada...hasta Hacker News da penita. ¿Alguien tiene una invitación para Lobsters?...es de los últimos refugios
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 esquemas de llamada y json devuelto))
- Componentes básicos de vue 3 para la interfaz de usuario
- Modulos de Pinia con todas las llamadas de la api con los endpoints y parámetros correctos para cada llamada
- Colección automática de postman para todas las llamadas de la api, estructuradas según definición de la interfaz de usuario
- Documento de nomenclatura estandarizada para todo el proyecto
- Definición de todas la parametrización de llamada a cada rutina
- Árbol de ejecución completo para cada rutina
- Para cada tabla puedo saber que rutinas la tocan y si es CREATE, UPDATE, READ, DELETE
- Para cada tabla puedo crear un procedimiento básico de CUD
- Se inspecciona automáticamente todo el código de las rutinas de la base de datos y se crean todos los índices automáticamente.
.......
#8 pues menos mal que es personal...
¿por qué te haces eso?
#10 ...y encima en MariaDB...
#14 si al menos fuera Postgres...
#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.
#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.
#40 gracias, puede haber un buen dinero en este proyecto.
#8 superdotado o soltero?
#24 soltero seguro, superdotado ... lo justo y necesario
#8 cómo has sacado ese diagrama UML tan bien distribuido en el espacio?
#31 uso https://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
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.
#4 Un respeto por el SQL, el único lenguaje antirradares de tráfico:
#5 Es uno de los pocos lenguajes que se inyectan.
#4 seguramente hará muchas cosas pero lo que seguro que no hace es lo que dice la entradilla, almacenar datos
#13 INSERT INTO.....
Yo creo que sí que almacena datos....
#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 ...)
#45 es verdad
#45 Y todavía te preguntas por qué no te invitan a las fiestas.
#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
#65 El que verdaderamente los almacena es el disco duro del equipo. El microprocesador simplemente escribe...
Hake mathe...
#66 Mira que lo estaba pensando al escribirlo jajaja. Acepto la derrota
#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...
#77 Cintas?
Tarjetas perforadas no?
Si al final vas a ser más antiguo que el SQL.
Salud !!!!
#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
#77 Na, me pillaste poco guerrillero jajaja
#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 !!!!
#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.
#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.
#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" que es algo simple y útil, mientras otros nos obligan a usar estructuras como MERGE o directamente liarnos con bloques IF EXISTS(SELECT ...), y al crear objetos en algunos dialectos tienes que consultar si ese objeto ya existe o no en una tabla master
#34 Casi todo lo que citas, no es SQL. Lógico que cueste migrar. Y poco común tener que hacerlo.
#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.
#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.
#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 ( https://en.wikipedia.org/wiki/Merge_(SQL) ), que por cierto tampoco es soportado por todos.
A ese problema me refiero.
#57 UPSERT y sus problemas: https://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 implementación standard, clara, amplia y detalladamente documentada. Pero si coges eso y decides implemetar tu propia versión y añadir variantes no compatibles, ya no es problema de SQL, es problema de quién lo implementa. Tú como programador podrías no usar esa implementación no estándard y usar la que si lo es y por tanto podrás migrar a cualquier otro motor porque sabrá interpretarlo correctamente. Por tanto, no es sequel el problema.
#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.
#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.
#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.
#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.
#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 serializaciones de objetos (JSON o documento o diccionario) que es lo que suele usar en programación , pasar por un ETL y análisis de los datos en una SQL.
Hay alguna NoSQL como Couchbase que tienen una cosa "SQL like" como N1QL que va como el culo.
#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.
#4 SQL no es un lenguaje. No cumple los requisitos, no tiene sentencias de control de flujo.....
#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 el comportamiento físico o lógico de un sistema informático, para que de esa manera se puedan obtener diversas clases de datos o ejecutar determinadas tareas.
Yo diría que SQL cumple eso perfectamente.
¡Pero no tiene sentencias de control de flujo imprescindibles para considerarse lenguaje!
Pero si hasta tiene CASE, IF, ELSE.... https://www.atlassian.com/data/databases/how-to-use-if-then-logic-in-sql-server
#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.
#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.
#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).
#82 No, eso no es SQL
#84 En mi comentario quería decir que no es un lenguaje de PROGRAMACIÓN, sí es un lenguaje, pero no de programación.
#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.
#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.
#73 Lenguaje es. Lo que pasa es que no es Turing completo.
#89 lenguaje sí. Pero no lenguaje de programación, que es lo que quería decir.
#4 Pues lo mismo que el COBOL.
#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.
#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.
#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.
comment_minimal_length'; DROP DATABASE meneame; --
#17 tu eres el padre de bobby, no?
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.
Si PL - SQL
Ese pelito....ese culito?!!?
Perdón, me he equivocado. No volverá a ocurrir
Y el año que viene...
#1 pues...51
50 años amargando vidas.
#9 50 años haciendo la vida más simple.
#11 depende de si pones EXPLAIN delante o no...
#11 entiéndeme, es que para un programador estar pensando en objetos y de repente tener que pasar a un enfoque relacional… nos cuesta
#44 No me jodas.
#69 #53 #48 pues hijos, soy raritu, yo qué sé
#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.
#9 Pues a mi todo lo contrario, me la alegra cada día.
PS: soy senior DevOps DBA
#4Edit, leí más abajo tu otro comentario
postgres con pgvector
Sícuel !!