WEBVTT

00:00:07.980 --> 00:00:11.100
Pues buenas tardes, buenas
tardes Roberto, ¿cómo estás?

00:00:11.780 --> 00:00:14.724
Hola, hola, muy bien, con
muchas ganas de estar aquí.

00:00:15.840 --> 00:00:19.660
Bienvenido a Café Database,
bienvenido a mi casa.

00:00:20.040 --> 00:00:22.873
Mi casa es tu casa a partir
de ahora, que lo sepas.

00:00:24.000 --> 00:00:29.820
Aquí hablamos casi todo, casi siempre de
Oracle, pero hoy eres tú un invitado de lujo,

00:00:29.820 --> 00:00:33.200
tío. ¿Qué tal estás?
¿Te has hecho un café?

00:00:34.580 --> 00:00:38.310
No tengo un café. ¿Eres de café o de té?

00:00:38.510 --> 00:00:41.370
De café. Oye, una cosa, estamos...

00:00:41.370 --> 00:00:45.570
Y estamos amargos solo.
Yo también estoy con café.

00:00:46.550 --> 00:00:48.050
Cucharita, no sé si se oye.

00:00:49.150 --> 00:00:52.510
Amargo también. Bueno, le
pongo un poco de azúcar y solo.

00:00:52.510 --> 00:00:54.390
Nada, a mí me gusta la amargura.

00:00:54.390 --> 00:00:57.430
Es una de las diferencias entre
nosotros, ya vamos a ir viéndolas.

00:00:57.470 --> 00:00:59.870
Bueno. Bueno, en Windows.

00:00:59.870 --> 00:01:01.590
Lo entiendo. Lo entiendo.

00:01:04.840 --> 00:01:10.240
Oye, qué bien Pues estamos streameando en
directo Estamos en directo en Youtube Es la

00:01:10.240 --> 00:01:16.960
primera vez que estamos haciendo El
podcast así Hasta ahora lo hacíamos Siempre en Discord,

00:01:17.080 --> 00:01:24.180
grabábamos solamente Audio y no nos Veíamos
las caras Así que esto es una novedad Y

00:01:24.180 --> 00:01:31.580
vamos a dejarlo grabado Que bueno, así se
pueden ver Mejor las expresiones Y todo

00:01:31.580 --> 00:01:37.420
Pero seguimos en el formato audio Ya hay
gente en la audiencia Recuerdo, para los que

00:01:37.420 --> 00:01:41.820
estáis, si queréis participar, levantéis
la mano, subid, si nos queréis preguntar lo

00:01:41.860 --> 00:01:46.880
que sea. Va a ser una charla muy
distendida, sobre todo con Roberto, que como él es un

00:01:46.880 --> 00:01:51.820
crack en SQL Server, vas a llevar
tú la voz cantante de todo esto.

00:01:52.640 --> 00:01:54.540
Lo primero de todo,
¿qué tal por Argentina?

00:01:54.580 --> 00:01:56.500
Cuéntame muy bien, muy bien.

00:01:56.500 --> 00:01:58.340
¿Qué has liado ahí? ¿Qué has liado?

00:01:58.380 --> 00:02:02.140
Acabo de aterrizar, como el que dice,
llegué ayer de 10 días por Argentina.

00:02:02.180 --> 00:02:07.960
Estuvimos por allí pues hablando de cómo
hacería en sql server con las nuevas funciones

00:02:07.960 --> 00:02:14.040
de sql server 2025 hicimos un taller en la
universidad técnica nacional de en la sede

00:02:14.040 --> 00:02:19.330
de buenos aires ahí estuvimos en el marco
del data saturday de latinoamérica un evento

00:02:19.330 --> 00:02:25.690
de comunidad que organiza la comunidad
para la comunidad y maravilloso maravilloso pues

00:02:26.330 --> 00:02:31.750
cuando me esas novedades venga que trae de
nuevo bueno pues lo primero El soporte para

00:02:31.750 --> 00:02:38.950
vectores, que eso lo conocemos
todos, y también trae la búsqueda,

00:02:38.950 --> 00:02:45.960
la búsqueda de similitud de vectores,
tanto hombre hoy con índice como una

00:02:45.960 --> 00:02:50.990
búsqueda exacta. Tenemos dos opciones:
tenemos una búsqueda que busca a los vecinos más

00:02:50.990 --> 00:02:55.570
cercanos por índice como una función que
calcula la distancia entre dos vectores.

00:02:55.570 --> 00:03:00.170
Entonces, pasándole como parámetro una de
las de la columna de nuestra tabla, pues podemos

00:03:00.210 --> 00:03:05.050
calcular la distancia con todos los
vectores que tenemos almacenados y obtener una búsqueda

00:03:05.090 --> 00:03:12.050
un poco más exacta que con los grafos de
los índices, y además para cerrar el círculo,

00:03:12.050 --> 00:03:14.717
porque, claro, esos
vectores hay que generarlos.

00:03:14.830 --> 00:03:17.450
Incorpora un nuevo procedimiento
almacenado del sistema que nos permite hacer llamadas

00:03:17.490 --> 00:03:23.840
API Directamente desde un procedimiento
del sistema puedes hacer una llamada API y capturar

00:03:23.840 --> 00:03:28.520
la respuesta, con lo cual podemos tirar de
la API de cualquier modelo, modelo de cualquier

00:03:28.560 --> 00:03:32.060
LLM, y hacer lo que queramos con ello.

00:03:33.480 --> 00:03:35.560
¿Y incrustáis los modelos?

00:03:35.560 --> 00:03:38.900
¿Metéis los modelos dentro de
las datos como hacemos en Oracle?

00:03:38.940 --> 00:03:43.107
¿Que podemos tener el modelo fuera o
lo podemos incrustar dentro del motor?

00:03:43.260 --> 00:03:46.100
Claro, a mí no me gusta,
pero sí que está la opción.

00:03:46.140 --> 00:03:48.480
Te permite generar solo
el modelo de embeddings.

00:03:48.520 --> 00:03:54.000
Tú creas un modelo externo como modelo
externo y entonces tienes una función para generar

00:03:54.000 --> 00:03:55.440
los embeddings usando ese modelo.

00:03:55.480 --> 00:03:56.920
¿Qué es lo que no me gusta?

00:03:56.960 --> 00:04:00.580
Que eso al al final hace lo mismo que
llamar al modelo por la API, ¿vale?

00:04:00.620 --> 00:04:04.398
Pero cuando te devuelve la respuesta,
te devuelve solo el embedding.

00:04:04.600 --> 00:04:09.960
Yo lo que hago es, usando el procedimiento
almacenado de llamar a la API, le paso al

00:04:09.960 --> 00:04:14.860
modelo de embedding el texto y el modelo
de embedding me devuelve un fichero de texto

00:04:14.860 --> 00:04:20.380
plano en JSON donde viene el embedding,
pero también viene el número de tokens consumidos.

00:04:20.460 --> 00:04:25.540
Entonces yo siempre voy a recomendar usar
este sistema para poder capturar el número

00:04:25.540 --> 00:04:29.980
de tokens consumidos para poder
almacenarlo en una tabla de log para tener trazabilidad,

00:04:30.020 --> 00:04:35.080
porque la diferencia entre una demo y la
producción real es tener un sistema que registre

00:04:35.080 --> 00:04:40.160
lo que está haciendo. Entonces, para mí es
imprescindible capturar en ese momento el

00:04:40.160 --> 00:04:44.060
coste de esa generación de embedding y
dejarlo en una tabla de log, porque si no, no

00:04:44.100 --> 00:04:45.878
sabemos lo que Estamos haciendo.

00:04:47.050 --> 00:04:50.430
Oye, estoy viendo en el vídeo que
pone empezamos en unos minutos.

00:04:50.470 --> 00:04:53.770
Ya hemos empezado. Los que
estamos aquí ya hemos arrancado.

00:04:54.030 --> 00:05:01.230
Si lo tienes en directo en youtube
le daba directo no lo sé prueba

00:05:01.230 --> 00:05:07.510
no me aparece en nuestra plataforma que
estamos usando aquí de la edad al que estudió

00:05:07.510 --> 00:05:14.520
si le das al en vivo estamos en vivo si
estamos en vivo bien qué bien qué bueno eso después

00:05:14.520 --> 00:05:20.420
bueno sabes que ahora que con esto de los
vectores ya lleva tiempo dando la tabarra con

00:05:20.420 --> 00:05:23.460
el AI Database y todo esto.

00:05:25.810 --> 00:05:32.710
Al final muchas van como muy de la mano,
es decir, las grandes un poco definen aquí,

00:05:32.770 --> 00:05:39.770
marcan tendencia y siguen un
poco, y como imponiendo el nuevo

00:05:39.770 --> 00:05:46.250
estándar que se va a imponer con toda la
inteligencia artificial, no vectores el tipo

00:05:46.250 --> 00:05:53.970
de datos cómo trabajar con ellos y regularizar
a partir de ahí, no normalizar y todo

00:05:54.130 --> 00:06:01.590
eso. Sí, yo creo que al final empezó
post gre creo que fue la primera y

00:06:01.720 --> 00:06:07.810
ahí nos hemos ido uniendo todos, no, al
final es algo con lo que con lo que tenemos que

00:06:07.810 --> 00:06:15.000
tratar, el tipo de datos vector está ahí y
cada vez es más que más necesario, que bueno.

00:06:15.000 --> 00:06:19.980
Cuéntame entonces, me decías porque
estuvimos hablando la semana pasada, me decías que

00:06:19.980 --> 00:06:25.740
eran un montón de conferencias, un montón
de responsables de producto también de Microsoft,

00:06:25.740 --> 00:06:31.980
no? Vosotros los MVP, es nosotros aquí
algunos de los que están en la audiencia son del

00:06:31.980 --> 00:06:38.420
programa, es es muy similar al programa de
MVP, es no, de de Most Valuable Professionals,

00:06:38.500 --> 00:06:44.820
y cuéntame, cuéntame qué, técnicamente,
qué viste, qué te sorprendió, ya te lo sabías

00:06:44.820 --> 00:06:47.340
todo, aprendiste mucho, o...

00:06:47.340 --> 00:06:53.880
Pues en estos eventos, tú que también has
estado seguro en muchos, sabes que, bueno,

00:06:53.920 --> 00:06:58.960
las charlas técnicas son una auténtica
barbaridad, había, en concreto, este Data Satur

00:06:58.960 --> 00:07:03.420
Day, la TAM, es un evento itinerante, se
hace una vez al año, y cada año Se hace en un

00:07:03.460 --> 00:07:07.120
país de Latinoamérica. El año pasado se
hizo en Chile, este año se ha hecho en Buenos

00:07:07.160 --> 00:07:11.580
Aires y el año que viene se hará en Paraguay
que ya nos lo desvelaron en el evento.

00:07:11.620 --> 00:07:15.398
Entonces vamos viajando y ahí es
un evento de la comunidad de datos.

00:07:15.780 --> 00:07:22.800
Hay mucha IA como no podía ser de otra
manera y si hay muchos MVP de Microsoft, el

00:07:22.800 --> 00:07:26.940
evento está centrado en ecosistema
Microsoft aunque también hubo alguna charlita de Databricks

00:07:26.980 --> 00:07:32.080
y siempre hay charlas de
datos de otras tecnologías.

00:07:32.080 --> 00:07:37.080
También vino Bruno, Bruno Capuano, que es
del equipo de Microsoft de desarrollo de GitHub.

00:07:37.580 --> 00:07:44.360
Bueno, pues tenemos siempre un poquito de
participación y apoyo por parte de la gente

00:07:44.360 --> 00:07:49.680
de Microsoft. Microsoft y sí, se aprende
muchísimo, por supuesto, se aprende muchísimo,

00:07:49.900 --> 00:07:54.360
no solo casos de uso,
sino también experiencia.

00:07:55.140 --> 00:08:00.660
Y en este evento en concreto, que es tan
internacional y para nosotros, yo que fui el

00:08:00.660 --> 00:08:05.160
único que iba desde España, pues también
se aprende otras realidades, que en Europa lo

00:08:05.200 --> 00:08:09.360
vemos de una manera, pero en Latinoamérica
a lo mejor no se ve de la misma manera.

00:08:09.400 --> 00:08:14.360
Pero lo que me traigo sobre todo siempre
estos eventos o las charlas de pasillo al final

00:08:14.360 --> 00:08:19.720
a mí lo que más me gusta de los eventos es
conocer a la gente charlar con la gente estamos

00:08:19.720 --> 00:08:21.640
todo el día en las redes a ti Te pasará.

00:08:21.680 --> 00:08:26.120
Tenemos seguidores de todas partes del
mundo, estamos en contacto por mensaje con gente

00:08:26.160 --> 00:08:29.840
de todas partes del mundo y no nos vemos,
después ir a un evento de estos y poder verte

00:08:29.880 --> 00:08:36.960
con un montón de gente es, es una pasada,
y eso cuando, cuando fue el evento de

00:08:36.960 --> 00:08:38.404
Las Vegas del Cloud World.

00:08:39.740 --> 00:08:41.740
Fue lo mejor que me llevé.

00:08:44.240 --> 00:08:51.800
Muchos de los seis ponernos cara
y poder tocarnos, qué lujo, y ver

00:08:52.310 --> 00:08:56.370
la persona, conocer la persona que
hay detrás del técnico es buenísimo.

00:08:56.370 --> 00:09:00.730
Eso, yo estoy en Argentina, han sido tres
días de evento, pero yo he estado diez días

00:09:00.770 --> 00:09:03.650
por allí y hay gente que todavía
sigue por ahí después del evento.

00:09:03.690 --> 00:09:08.590
Al final, como es es un evento que va
pasando de país en país y van de todos los países

00:09:08.590 --> 00:09:14.590
de Latinoamérica, pues Organizan un montón
de actividades fuera del evento para los ponentes

00:09:14.590 --> 00:09:20.490
bueno y alguna existente también que va
solo de otros países y se les incluye escenas

00:09:20.490 --> 00:09:27.590
visitas guiadas paseos por un sitio o por
otro yo fue a aterrizar el primer día bueno

00:09:27.590 --> 00:09:30.750
llegué por la noche me fui a dormir para
el día siguiente ya la organización no había

00:09:30.790 --> 00:09:35.270
nada organizado todavía porque llegué muy
pronto pero Pero ya me dijeron una de las chicas,

00:09:35.310 --> 00:09:39.430
esta noche a cenar a mi casa, los que
estáis aquí, que éramos tres o cuatro que habíamos

00:09:39.470 --> 00:09:45.270
llegado ya, ya a cenar a su casa y ya hay
un no parar, ya no me han dejado solo en los

00:09:45.270 --> 00:09:48.990
diez días. O qué bueno,
qué bueno, qué bueno.

00:09:49.410 --> 00:09:56.950
Cuéntame un poco, tú tienes una comunidad
por Telegram que es tremenda y aparte

00:09:56.950 --> 00:10:03.190
estuvimos hablando y veo que los grupos
usuarios de Microsoft y los grupos privados que

00:10:03.190 --> 00:10:09.990
tenéis, tenéis un montón de movimiento y
de empuje, por decirlo de alguna forma, ¿no?

00:10:09.990 --> 00:10:13.950
Me contabas algunos eventos
que me dejaron alucinado, ¿no?

00:10:14.510 --> 00:10:18.066
Cerrar un hotel, un fin de semana
para hacer un evento gratuito.

00:10:18.750 --> 00:10:22.390
¿Sabes qué digo yo? Grandísimos.

00:10:22.510 --> 00:10:25.250
Te esperamos el año que
viene, ahí te lo dejo.

00:10:26.950 --> 00:10:29.590
Si es en Valencia, voy. Claro, claro.

00:10:29.870 --> 00:10:34.190
Si es en Valencia, voy. Alguien tiene que
venir a poner la nota discordante y hablarnos

00:10:34.230 --> 00:10:39.610
de Oracle, ¿no? Sí, la verdad es que la
comunidad Microsoft para eso está muy activa.

00:10:39.990 --> 00:10:45.430
Sobre todo en España, porque en
Latinoamérica, por ejemplo, eventos presenciales grandes

00:10:45.430 --> 00:10:47.830
no hay más que este que acabamos de hacer.

00:10:48.430 --> 00:10:51.450
Se hace alguno más, pero no son tan...

00:10:51.450 --> 00:10:53.839
Este fin de semana han
sido 900 asistentes.

00:10:54.810 --> 00:11:00.810
¡Guau! Entonces, a ver, aquí en
España no tenemos tan grandes.

00:11:01.370 --> 00:11:07.710
Tenemos, pues mira, ahora el mes que viene
tenemos el BitSummit de las Business Applications

00:11:07.710 --> 00:11:12.190
de Microsoft, que ese sí que es muy
grande, que reúne a 1 .200 personas aproximadamente

00:11:12.230 --> 00:11:18.410
de asistentes, y luego el Data Saturday
aquí en Madrid también mueve en torno a 600 personas

00:11:18.410 --> 00:11:22.310
o así, que también se hace en una universidad,
se hará ahora el primer fin de semana

00:11:22.350 --> 00:11:29.350
de noviembre, así en exclusiva, os lo puedo
decir, nos lo dijeron ayer, así que ahí

00:11:29.350 --> 00:11:33.120
tenemos también otro
evento muy interesante.

00:11:33.120 --> 00:11:37.660
Sí, la verdad es que normalmente hacemos,
nosotros tenemos nuestra comunidad, realmente

00:11:37.700 --> 00:11:42.740
es un grupo de Telegram abierto a quien
quiera participar, que le interese SQL Server

00:11:42.740 --> 00:11:49.400
o SQL en Azure. Somos ahora mismo
700 miembros, 703 para ser exactos.

00:11:49.760 --> 00:11:53.260
Sabéis que esto va fluctuando, un día
hay uno más y otro día hay uno menos.

00:11:53.300 --> 00:11:59.180
700 miembros aproximadamente de todo pues
hay de todas las partes del mundo lo único

00:11:59.180 --> 00:12:05.820
que pedimos es aquí se habla de sql server
y se habla en español si te encaja eso adelante

00:12:05.820 --> 00:12:14.420
y organizamos eventos organizamos normalmente
hacemos un evento mensual descansamos

00:12:14.420 --> 00:12:20.720
los dos meses de verano un mitad online
totalmente gratis viene nos conectamos una horita

00:12:20.720 --> 00:12:26.280
viene un ponente cada Cada mes va cambiando
y nos da una charla De algún tema.

00:12:26.320 --> 00:12:31.720
Ayer tuvimos una charla súper interesante
de Juan Irigoyen que nos habló cómo él había

00:12:31.720 --> 00:12:36.480
hecho un agente de IA para trabajar, para
optimizar el código de sus consultas de una

00:12:36.480 --> 00:12:38.180
aplicación Legacy, por ejemplo.

00:12:38.220 --> 00:12:40.260
Entonces, pues una vez
al mes nos juntamos ahí.

00:12:40.300 --> 00:12:43.580
Luego hemos empezado este año
también con un evento anual.

00:12:44.500 --> 00:12:50.380
Nos pusimos en contacto con la comunidad
de SQL Argentina, que están igual de locos que

00:12:50.380 --> 00:12:56.770
nosotros y les propusimos hacer un evento
de SQL Server en español de 24 horas seguidas.

00:12:57.810 --> 00:13:04.370
Por suerte, alguien puso algo de cabeza
ahí y dijo, hay muy poca diferencia horaria entre

00:13:04.370 --> 00:13:09.030
España y Argentina para hacer 24 horas
seguidas, pero hicimos dos días seguidos dos eventos

00:13:09.070 --> 00:13:11.770
de 12 horas. 12 más 12, sí, sí.

00:13:11.830 --> 00:13:18.810
12 más 12. Entonces hicimos una maratón de
charlas de SQL Server en español donde tuvimos

00:13:18.810 --> 00:13:26.190
de todo, desde SQL Server on -premise
hasta tuvimos AWS, SQL en Azure, tuvimos

00:13:26.190 --> 00:13:31.490
también Fabric, que es la plataforma de
datos de Microsoft, más analítica, tuvimos un

00:13:31.490 --> 00:13:38.070
poquito de todo y salieron 24 charlas,
cosa que yo no daba un duro por ello cuando nos

00:13:38.070 --> 00:13:42.590
lanzamos a esa locura. A ver si
conseguimos 24 ponentes que quieran hablar en español

00:13:42.630 --> 00:13:49.230
de esto y sí, sí, al final tuvimos que
seleccionar charla y salió, y este fin de semana

00:13:49.230 --> 00:13:52.770
en Argentina, ya me han dicho los chicos
De allí de Laguna de Argentina, que esto no

00:13:52.810 --> 00:13:58.310
puede parar, que hay que hacerlo una vez
al año y vamos, por mí encantado Polín, muy

00:13:58.310 --> 00:14:01.370
bien, muy bien, estáis on
fire, eh, estáis on fire.

00:14:02.810 --> 00:14:09.370
Tengo muchas cosas para hablar contigo y
una de ellas es de tu libro, de mi libro, hablemos

00:14:09.370 --> 00:14:16.470
de aquí, claro, no puede ser que
venga un invitado, ahí está la no

00:14:16.470 --> 00:14:23.710
guía, la no guía de optimización, la
práctica de optimización, sí, sí, sí, esto

00:14:23.710 --> 00:14:29.810
es que también yo te yo yo también tengo
uno que estoy ahora adaptando, aquí estamos

00:14:29.810 --> 00:14:36.230
hablando cada uno de él, no se habla de mi
libro, no se tiene que hablar de mí, no puede

00:14:36.230 --> 00:14:40.910
ser que venga un invitado y no hable de su
libro, así que cuéntanos, cuéntanos de tu

00:14:40.910 --> 00:14:47.930
libro, la no guía, porque no guía es
no no es no guía práctica, al final yo

00:14:47.930 --> 00:14:54.750
lo que no quería era un libro de recetas,
sabes que Amazon está lleno de libros de aprende

00:14:54.750 --> 00:15:01.890
SQL en un fin de semana, paga 15
euros por 100 páginas y te enseño SQL,

00:15:01.890 --> 00:15:07.450
yo no quería eso en mi Mi libro es un libro
bastante más avanzado y es prácticamente

00:15:07.450 --> 00:15:10.890
entero de internals del
motor de base de datos.

00:15:11.170 --> 00:15:16.950
Porque al final, los que me han seguido
en el blog desde siempre lo saben.

00:15:17.030 --> 00:15:23.150
Yo soy de los que piensa que al final
el cómo ya está en todos los sitios.

00:15:23.270 --> 00:15:26.430
Y el cómo cambia. No solo está en todos
los sitios, sino que el cómo cambia.

00:15:26.470 --> 00:15:27.830
Pero las bases son las bases.

00:15:27.870 --> 00:15:34.930
Si los que nos están escuchando
no saben nada de SQL Server, el

00:15:34.930 --> 00:15:40.130
90 % del libro les puede servir Porque las
bases de una base relacional son Las mismas.

00:15:40.220 --> 00:15:46.320
Luego simplemente tendrás que ver cómo se
hace esto en mi sistema, ya esté hablando de

00:15:46.320 --> 00:15:49.460
MySQL, esté hablando de Postgre, esté
hablando de Oracle, esté hablando de SQL Server.

00:15:49.500 --> 00:15:52.100
Pero lo que quiero hacer
es lo que quiero hacer.

00:15:52.140 --> 00:15:58.360
Todos sabemos lo que es particionar, todos
sabemos lo que es un índice; hay diferencias,

00:15:58.360 --> 00:16:01.000
las hay, pero las bases son las mismas.

00:16:02.440 --> 00:16:05.260
Entonces pues eso es lo que lo que hice.

00:16:05.260 --> 00:16:12.520
Me dio por medio la locura, también es
verdad que no me que no me volví loco

00:16:12.520 --> 00:16:17.840
en el sentido que ya estaba yo tenía el
blog desde hacía tiempo y mucho ya estaba en

00:16:17.840 --> 00:16:23.220
el blog, solo pues hubo que darle forma,
cambiar el tono porque el blog es mucho más

00:16:23.220 --> 00:16:29.840
informal y eso, pero pero al final, bueno
pues con un poco de tiempo, no voy a decir

00:16:29.840 --> 00:16:33.920
que sean pocas horas porque tú bien sabes
lo que es esto, pero con un poco de tiempo

00:16:33.960 --> 00:16:36.480
le dimos la vuelta a lo
que había en el blog.

00:16:36.540 --> 00:16:41.520
Quiero decir, la investigación ya estaba
hecha porque todo sale de artículos que, sí,

00:16:41.560 --> 00:16:46.020
que se reescribieron. Obviamente se
reescribió como capítulos del libro, pero la investigación

00:16:46.060 --> 00:16:52.520
ya estaba hecha. Se dice pronto se dice
rápido es decir muchas de las cosas estaban en

00:16:52.520 --> 00:16:59.640
blogs y muchas de las cosas están ya escritas
yo tengo otra opinión para mí me pasa

00:16:59.640 --> 00:17:06.660
un poco que es como la música no se aparece
que todo está escrito y no y siempre ya

00:17:06.660 --> 00:17:09.771
no tenía escrito yo que ya
lo había escrito yo Ah, vale.

00:17:09.900 --> 00:17:15.260
No, pero guías estas de Amazon o no sé
qué, o libros, libros de Oracle hay un montón,

00:17:15.440 --> 00:17:22.500
pero no. O sea, ves que, o
primero que estén en español, esa

00:17:22.500 --> 00:17:24.444
es la primera, escribir en español.

00:17:24.640 --> 00:17:29.000
A veces lo he comentado en algún episodio,
yo cuando he hablado de editoriales de Oracle

00:17:29.040 --> 00:17:32.320
Press para publicar en español, es
la primera barrera que me han dicho.

00:17:32.360 --> 00:17:39.440
Español no lo escribimos lo escribimos
en inglés opcional chino opcional indio

00:17:39.440 --> 00:17:46.320
son los mercados pero en español no dicen
hace más de 15 años no se publica un título

00:17:46.320 --> 00:17:50.940
técnico en oracle en español digo joder
pues como sigáis con esa política pues otros

00:17:50.980 --> 00:17:56.440
15 van a pasar claro claro pero en ese
sentido que lo hemos hablado alguna vez y no y

00:17:56.440 --> 00:18:01.460
aquí a mí nos gusta hablar de las
diferencias que tenemos entre las comunidades de Microsoft

00:18:01.500 --> 00:18:07.320
y de Oracle, en ese sentido Microsoft apoya
mucho las comunidades en idioma local es

00:18:07.320 --> 00:18:12.540
el primer interesado en que se genere
contenido en idioma local es más, tú en el canal

00:18:12.540 --> 00:18:17.120
de YouTube de Microsoft En el reactor, que
es el que tienes así de divulgación, si tú

00:18:17.160 --> 00:18:21.820
te metes vas a ver que todos los eventos
se organizan con speakers que hablan en idioma

00:18:21.860 --> 00:18:26.600
local, entonces tienes el evento en
inglés, pero lo tienes en chino lo tienes en portugués,

00:18:26.640 --> 00:18:31.340
lo tienes en español lo tienes en alemán
al final lo que la comunidad va generando vale

00:18:31.380 --> 00:18:36.440
porque al final lo que lo que intentan es
apoyarse las comunidades para todo eso y desde

00:18:36.440 --> 00:18:42.400
microsoft lo que nos transmiten a los mvp
muchas veces es eso nos no vamos a tener el

00:18:42.400 --> 00:18:46.080
mismo número de seguidores que alguien que
escribe en inglés pero no nos tenemos que

00:18:46.120 --> 00:18:52.580
preocupar ellos valoran el contenido en
idioma local porque al final es escribir en inglés

00:18:52.580 --> 00:18:58.310
es una barrera de entrada muy fuerte para
mucha gente entonces valoran mucho ese contenido

00:18:58.310 --> 00:19:05.230
yo tengo aquí el matiz oracle a los 6 si
nos anima muchísimo a crear contenido en idioma

00:19:05.230 --> 00:19:11.730
local sobre todo apoya muchísimo las
comunidades locales desde desde la divulgación pero

00:19:11.730 --> 00:19:19.030
las editoriales es otra es otra historia
cuando estamos hablando de una editorial que

00:19:19.030 --> 00:19:24.590
al final va a hacer una tirada de unos
ejemplares y hace unos balances de cuentas Y dice,

00:19:24.690 --> 00:19:30.210
tanto invertir por tanto beneficio, por
tanto que pago, tantas ventas va a haber.

00:19:30.310 --> 00:19:34.430
Al final, hacen números así con los dedos
de cuántas ventas va A haber y dice, español,

00:19:34.470 --> 00:19:35.770
nada, fuera, en español no.

00:19:35.810 --> 00:19:41.970
El libro en inglés, luego las charlas y
tal, que tampoco les cuesta mucho que las charlas

00:19:41.970 --> 00:19:47.750
las hacemos en español. Yo también te digo
que mi libro es autopublicado en Amazon.

00:19:49.190 --> 00:19:53.510
Aquí hay un concepto, no es autoeditado,
también es autoeditado, pero realmente lo que

00:19:53.550 --> 00:19:56.310
valora es que es autopublicado
en Amazon, ¿vale?

00:19:56.350 --> 00:20:01.510
Y de todas formas yo he tenido alguna
oferta de alguna editorial también, aparte de Amazon,

00:20:01.730 --> 00:20:05.850
pero son editoriales que
no al estilo clásico.

00:20:05.850 --> 00:20:08.670
No lo que tú estás hablando de
imprimir una tirada de libros.

00:20:08.710 --> 00:20:10.350
No, funcionan más bien como Amazon.

00:20:10.390 --> 00:20:16.350
Ellos tienen el archivo de la portada,
tienen el archivo en PDF del libro y cuando alguien

00:20:16.350 --> 00:20:18.410
lo compra, se imprime y se envía.

00:20:19.530 --> 00:20:20.750
Demoras un poco más los tiempos.

00:20:20.790 --> 00:20:27.790
No puedes tener esto que en
librerías no puede es verdad pero

00:20:27.790 --> 00:20:33.550
el riesgo es cero entonces yo mi libro
está publicado en amazon yo dejé no sé si lo has

00:20:33.550 --> 00:20:37.370
hecho alguna vez si quieres lo comentamos
te das de alta en la plataforma de amazon de

00:20:37.410 --> 00:20:44.390
se llama kdp kindle direct publish y te
das de alta en amazon kdp con tu cuenta de amazon

00:20:44.390 --> 00:20:51.650
en cuestión de dos minutos subes el
manuscrito en pdf eliges el tipo de papel

00:20:51.650 --> 00:20:55.750
que quieres si lo quieres a color, si quieres
tapadura, si quieres tapa blanda, todo

00:20:55.790 --> 00:21:01.480
eso define un coste de impresión luego a
partir de ahí tú pones el precio de venta y

00:21:01.480 --> 00:21:06.340
ya está, cada vez que alguien compra, se
imprime un libro y se envía, Amazon tiene

00:21:07.260 --> 00:21:11.840
imprentas en Italia en Alemania, en Estados
Unidos bueno, tiene repartidas Por Asia,

00:21:11.880 --> 00:21:16.640
tendrá algunas más, yo conozco esas,
entonces depende de donde compren, además se imprime

00:21:16.680 --> 00:21:21.347
en cualquier parte del mundo más cercana y
se envía, Amazon tiene distinción global,

00:21:21.420 --> 00:21:25.920
no me tengo que preocupar, llega a toda
Latinoamérica, me han comprado libros en Alemania,

00:21:25.960 --> 00:21:30.980
me han comprado libros en algún país de
Asia, que obviamente es uno alguien que habla

00:21:30.980 --> 00:21:34.640
español que está allí y lo
compra, pero sin ningún problema,

00:21:35.770 --> 00:21:39.714
al final esa es un poco la solución
que tenemos, porque además te diré,

00:21:40.070 --> 00:21:45.490
Ángel Jiménez, que al final de la
temporada pasada, en un libro de

00:21:46.530 --> 00:21:51.490
optimización SQL, SQL en sobre bases de
datos y hablaba un poco de SQL Server, un poco

00:21:51.490 --> 00:21:57.230
de Oracle, un poco de... Es decir, de
todas las formas teóricas de optimizar las joins

00:21:57.230 --> 00:22:02.830
y todo, él tenía desplegado en múltiples,
en los cinco escenarios, digamos, típicos.

00:22:02.830 --> 00:22:07.650
Él también recurrió a la autopublicación y
en mi libro igual, mi libro va a ir por el

00:22:07.650 --> 00:22:09.170
mismo camino, es decir, autopublicación.

00:22:09.210 --> 00:22:17.390
Eso no quiere decir que no cuente detrás
con revisores, con rectores, con diseñadores

00:22:17.390 --> 00:22:24.250
gráficos, pero me lo pago yo y, digamos,
tengo como mi propia discográfica, ¿no?

00:22:24.250 --> 00:22:31.310
Como un grupo que dice, somos la escena
independiente en la publicación editorial, ¿no?

00:22:31.310 --> 00:22:38.490
Técnica. Pero también es que
nos ponen el camino en bandeja,

00:22:38.490 --> 00:22:45.690
¿no? Nos dicen por allí. No, pero eso
ya te digo ahora con la tecnología que

00:22:45.690 --> 00:22:52.670
existe y conozco varias editoriales que
hacen esto, si quieres un día lo comentamos es

00:22:52.670 --> 00:22:58.300
muy fácil porque se imprime a demanda y ya
está, no te tienes que preocupar, es verdad

00:22:58.300 --> 00:23:00.467
que a lo mejor el coste sube un poquito

00:23:00.970 --> 00:23:06.570
bueno, no pasa nada. La otra opción es que
no salga, porque lo que tú dices, no me voy

00:23:06.570 --> 00:23:11.850
a meter en una inversión de pagar mil
libros para luego comérmelos que es la tirada mínima

00:23:11.850 --> 00:23:13.406
que te pone alguna editorial

00:23:13.610 --> 00:23:18.810
además mi tío, yo tengo un tío librero que
tenía una editorial también médica y él me

00:23:18.810 --> 00:23:22.310
decía, tú tienes que pensar que
un libro es material perecedero

00:23:23.050 --> 00:23:28.290
un libro caduca digo, pero por qué, porque
es técnico, no porque el libro se imprime

00:23:28.290 --> 00:23:34.730
las tapas se le doblan cuando alguien
lojea se deforma cuando coge polvo y todo el mundo

00:23:34.730 --> 00:23:38.452
quiere un libro nuevo todo el mundo
quiere la sensación de un libro

00:23:39.370 --> 00:23:45.110
Recién, recién, no quiero un libro sobado,
toqueteado y tal, y entonces, si tú compras

00:23:45.110 --> 00:23:49.110
100 ejemplares y los tienes en casa
cogiendo polvo, piensa que es como

00:23:50.510 --> 00:23:55.670
Material precedero, comida fruta, que se
te va a se te va a caducar, esos libros a lo

00:23:55.670 --> 00:24:01.130
mejor ya los podrás vender, se te doblará
la tapa vendrá doblada, cosas así pero fíjate,

00:24:01.230 --> 00:24:04.710
y de ahí el consejo me dijo si puedes

00:24:06.190 --> 00:24:12.110
Autoedición y es una demanda, pero una cosa,
vamos a hablar de SQL Server un poquito

00:24:12.110 --> 00:24:17.850
también, ¿no? Bueno, hemos hablado un
poquito de comunidad, hablamos de todo, ¿nos estamos

00:24:17.850 --> 00:24:22.010
tomando un café? Bueno,
sí, un poquito de todo.

00:24:22.190 --> 00:24:23.801
Vamos a hablar de SQL Server.

00:24:24.190 --> 00:24:31.550
Cuéntame, esa mandanga que estabas diciéndome
cuando hablamos, de que están montando

00:24:31.550 --> 00:24:38.590
Microsoft con PostgreSQL y Y ese,
o sea, esa historia que van a

00:24:38.590 --> 00:24:43.870
hacer con Azure y que me dejó todo loco y
digo yo, que lo cuente él, que lo cuenta mejor.

00:24:44.330 --> 00:24:46.910
Esto es, sí, tú hablas de HorizonDB.

00:24:47.870 --> 00:24:53.810
HorizonDB es una nueva base de datos en
Azure que es con base Postgre, pero optimizada

00:24:53.810 --> 00:24:55.310
para infraestructura Azure.

00:24:55.470 --> 00:25:01.290
Nos permite, creo que es una barbaridad de
réplicas secundarias, hasta 16 réplicas de

00:25:01.290 --> 00:25:04.457
lectura, aparte de la réplica
activa, hasta 3 .000 cores.

00:25:05.810 --> 00:25:14.010
Un montonazo de RAM. Creo que estaban
en torno a los 128 teras de RAM máximo,

00:25:14.030 --> 00:25:17.610
o sea, una auténtica barbaridad
lo que podemos desplegar ahí.

00:25:17.610 --> 00:25:20.270
Y no deja de ser un
Postgre con esteroides.

00:25:22.650 --> 00:25:29.270
Optimizado para la Infraestructura Azure
Si la gente puede sonar Un poco extraño, ¿no?

00:25:29.290 --> 00:25:35.290
Que Microsoft se meta en esto A mí lo que
nos trasladó Una vez el equipo de producto,

00:25:35.450 --> 00:25:40.230
bueno, Microsoft tiene un equipo o unos
equipos de desarrollo, porque tiene varios de

00:25:40.230 --> 00:25:42.110
software libre, muy, muy grandes.

00:25:42.630 --> 00:25:48.450
Las contribuciones en el proyecto de
Postgre por parte del equipo de Microsoft rondan

00:25:48.450 --> 00:25:53.250
el 50 % ya de todo el código de
Postgre sale del equipo de Microsoft.

00:25:53.250 --> 00:25:59.470
Del core de Linux estamos hablando del
torno al 30 % también sale de equipos de software

00:25:59.470 --> 00:26:04.650
libre de Microsoft. Microsoft desde que
tiene la parte de Azure está apostando muy fuerte

00:26:04.650 --> 00:26:09.800
por el software libre y está
colaborando mucho con eso.

00:26:10.640 --> 00:26:17.360
Tenía sus plugins para Postgre Y ahora pues
Y tenía Postgre en Azure Y ahora ha dado

00:26:17.360 --> 00:26:24.320
el paso A hacer este Horizon DB Que está
en Preview Pero que desde luego promete Además

00:26:24.320 --> 00:26:27.931
va un paso más allá Con los vectores
que estábamos hablando antes

00:26:28.700 --> 00:26:33.360
Hasta el punto que tiene En
todo el tema este De vectores

00:26:34.590 --> 00:26:36.610
Tiene la generación asíncrona automática.

00:26:36.650 --> 00:26:41.470
No te tienes que molestar tú por generar
los vectores, sino que ya directamente está

00:26:41.470 --> 00:26:48.320
pensado en la IA desde el minuto 1, una
auténtica barbaridad lo que está haciendo con

00:26:48.320 --> 00:26:53.260
esta base de datos y, bueno, otra de las
cosas que tenemos de novedad en Azure antes

00:26:53.260 --> 00:26:56.380
de meternos en el mundo
SQL Server es Oracle.

00:26:56.380 --> 00:26:58.769
Oracle en Azure también
está disponible ya.

00:26:59.960 --> 00:27:05.240
No sé si habéis tenido oportunidad de
echarle un vistazo al final, bueno, pues teníamos

00:27:05.240 --> 00:27:11.720
MySQL, teníamos Postgre, pues faltaba,
teníamos un equivalente a Mongo, no, pues faltaba

00:27:11.810 --> 00:27:19.420
faltaba también la otra grande, si al
final sabes que el árbitro dijo que el

00:27:19.420 --> 00:27:24.500
mundo iba a ser multi cloud y que todas
las plataformas y todos los motores iban a estar

00:27:24.500 --> 00:27:30.160
en todas las infraestructuras y que tenían
el compromiso de montar los data centers muy

00:27:30.160 --> 00:27:37.560
cerquita, muy cerquita, para que incluso
fuera más rápido, digamos, un conectar un un

00:27:37.560 --> 00:27:45.040
moracle, un SQL Server entre OCI y Azure
de una misma región que a lo mejor entre

00:27:46.360 --> 00:27:51.720
Una misma infraestructura, o solo OCI o
solo Azure entre regiones distintas, o sea, que

00:27:51.720 --> 00:27:58.740
tenían el compromiso de hacer
urbanizaciones y que todos fueran vecinos y

00:27:58.740 --> 00:28:02.380
la conexión entre ellos fuese muy cercana.

00:28:02.380 --> 00:28:06.420
El caso de Oracle en Azure
tiene un poco más de miga.

00:28:06.420 --> 00:28:12.980
No es como Postgre o como MySQL, que
están desplegados en hardware de Azure.

00:28:12.980 --> 00:28:18.000
Esto está desplegado en el hardware que
hay en OCI, pero puesto en el CPD de Azure.

00:28:19.360 --> 00:28:21.740
Entonces se despliega
sobre el hardware OCI.

00:28:21.780 --> 00:28:28.300
Pero en Azure Entonces
sí, es muy interesante.

00:28:28.300 --> 00:28:30.660
Y al final yo creo que ese es el futuro.

00:28:30.660 --> 00:28:32.438
Lo que tú decías, el multicloud.

00:28:33.660 --> 00:28:39.060
No podemos casarnos con un proveedor, y
menos con lo que estamos viendo últimamente:

00:28:39.060 --> 00:28:43.800
se cae un cloud y nos quedamos vendidos.

00:28:43.800 --> 00:28:46.856
Hemos visto caídas en Azure,
hemos visto caídas en AWS.

00:28:47.320 --> 00:28:51.980
OCI seguro que las ha tenido y, si no las
ha tenido, las tendrá, igual que las volverá

00:28:52.020 --> 00:28:57.000
a tener AWS y las volverá a tener Azure
porque a todos nos ha pasado; quiero decir, yo

00:28:57.000 --> 00:29:03.020
he tenido incidentes Trabajando con base
de datos tan absurdos como que una ardilla se

00:29:03.020 --> 00:29:09.800
come un cable de conexión de un cpd y se
cayó el cpd y eso es inevitable, no hay de rp

00:29:09.800 --> 00:29:15.780
que te salve de todas las situaciones
posibles y el impacto siempre está, siempre está

00:29:15.780 --> 00:29:20.620
ahí, no? Entonces, al final, la
arquitectura multi cloud es es clave y qué decir ahora

00:29:20.620 --> 00:29:25.780
que hemos visto, no?, que a un dirigente
de un país x se le cruza el cable, dice esta

00:29:25.780 --> 00:29:33.060
empresa deja de poder vender y nos
quedamos sin cloud Cloud durante meses,

00:29:33.180 --> 00:29:36.080
sin un modelo de inteligencia artificial,
pues quien te dice que eso no va a pasar en

00:29:36.120 --> 00:29:41.140
la nube, que va a llegar el presidente de
Estados Unidos de turno, el de ahora o el de

00:29:41.140 --> 00:29:46.720
dentro de 10 años, me da igual, y vaya a
decir, interés estratégico, ningún usuario no

00:29:46.720 --> 00:29:51.560
estadounidense puede acceder a esto, como
dijo con el modelo de Cloud, y te cortan la

00:29:51.560 --> 00:29:58.860
nube, ¿y qué haces? Pues creo que al final
una arquitectura multicloud, incluso tener

00:29:58.860 --> 00:30:06.020
parte on -premise, Yo no lo
descarto, pero sin ninguna duda,

00:30:06.140 --> 00:30:12.400
vamos, para mí el on -premise sigue
teniendo mucha fuerza y aunque solo sea de recuperación

00:30:12.400 --> 00:30:17.380
o de backup por si pasa algo en la nube,
que para mí es al revés, es más la nube como

00:30:17.380 --> 00:30:20.560
un backup en el 90 % de
los casos, pero bueno.

00:30:20.560 --> 00:30:27.730
Sí, bueno, backup entornos rápidos de
creación necesitas un entorno de desarrollo

00:30:27.730 --> 00:30:33.250
puedes ir generando con por ejemplo en
Oracle que tenemos AutonomousDB puedes rápidamente

00:30:33.250 --> 00:30:35.710
crear con AutonomousDB tres o cuatro

00:30:36.850 --> 00:30:40.510
plataformas rápidas para entornos de
desarrollo cuando acabas los tiras abajo, es decir,

00:30:40.550 --> 00:30:45.270
para eso sí creas bases de datos a golpe
de clic las bases de datos escalan a golpe de

00:30:45.310 --> 00:30:52.220
clic es verdad, pero también es verdad que
la soberanía no es la misma No tienes la misma

00:30:52.220 --> 00:30:56.840
soberanía sobre mañana te cierra y mañana
te cierra, mañana se cae y mañana se cae.

00:30:57.340 --> 00:30:59.680
Hay mil casos que pueden pasar.

00:31:01.510 --> 00:31:03.610
Yo para eso, ¿qué quieres que te diga?

00:31:03.650 --> 00:31:08.430
Es verdad, es muy rápido, pero desplegar
máquinas virtuales cuando tienes hardware físico

00:31:08.470 --> 00:31:13.900
también es muy rápido. Sí, también, sí,
sí, sí Bueno, la diferencia siempre es lo que

00:31:13.900 --> 00:31:19.240
hablamos Cuando tú provisionas en un
premio Físico, tú siempre piensas a futuro Cuando

00:31:19.240 --> 00:31:25.440
tú provisionas en la nube Es, digamos, a
presente Lo necesito ahora y Cuando lo quiero

00:31:25.440 --> 00:31:30.800
dejar de tener, lo dejo de tener Y va
fuera Y lo mismo, es decir, no estoy consumiendo

00:31:30.800 --> 00:31:35.440
Tengo clientes que les he Recomendado
bajar la memoria Digo, ¿a dónde vais?

00:31:35.580 --> 00:31:38.220
No necesitáis tanta memoria Bajad
la mitad, ¿estáis en la nube?

00:31:38.260 --> 00:31:44.000
Pues bajad, o sea bajad gigas a la mitad,
que es que no se usan es decir, bueno, o sea,

00:31:44.000 --> 00:31:45.820
borramos aquí una pasta en...

00:31:45.820 --> 00:31:52.260
Pues para eso está puedes hacer ese
downsizing Sí, yo hice un proyecto de optimización

00:31:52.260 --> 00:31:59.760
en un cliente trabajamos intensamente
meses con las queries de la aplicación y

00:31:59.760 --> 00:32:06.780
al final terminamos reduciendo la factura
de servicios de Azure a la mitad 50

00:32:06.780 --> 00:32:10.120
.000 euros, estaban en 100 Bajo a 50

00:32:11.940 --> 00:32:17.820
Simplemente Porque puedes Y porque sobre
todo Esa optimización la he podido hacer también

00:32:17.820 --> 00:32:21.900
Un cliente on -premise y le he dicho No
vendas el hardware, no te quites ese hardware

00:32:21.940 --> 00:32:27.080
Porque mañana lo puedes necesitar Al de
Azure no, porque mañana Coges el slicer en la

00:32:27.080 --> 00:32:34.100
web y haces Pum, a la derecha Y ya está, y
suben los ceros En la factura, pero está disponible

00:32:34.100 --> 00:32:40.460
El recurso, esa es la ventaja De la nube,
poder escalar La desventaja, que no te dejan

00:32:40.460 --> 00:32:45.740
escalar como quieres Porque teóricamente
Puedes escalar como quieras En la práctica ya

00:32:45.740 --> 00:32:50.200
sabes que te dicen que Necesitas más
disco, uy que pena Pues con 8 cores es todo el disco

00:32:50.240 --> 00:32:54.640
que podías tener Tendrás que escalar los
cores Y dices, vale, dame 12, no, no, no De

00:32:54.680 --> 00:32:59.280
8 pasa a 16 ¿Verdad? Que
se va multiplicando por 2.

00:32:59.280 --> 00:33:03.840
Y tú solo necesitabas 10 gigas más de espacio
en disco, porque te habías quedado sin

00:33:03.880 --> 00:33:10.300
espacio en disco. Pero, a ver, 10 gigas es
un decir, ¿no?, pero me entiendes, tú necesitabas

00:33:10.300 --> 00:33:14.660
algo más barato y te dicen, no, pero ahora
este está ligado a los cores y además sube

00:33:14.700 --> 00:33:19.580
la memoria, porque, claro, en vez de tener
el plan de 5 GB de memoria por core, vas a

00:33:19.580 --> 00:33:21.580
tener el de 7 GB de memoria por core

00:33:22.430 --> 00:33:29.620
y te... Sí, sí, sí, totalmente de
acuerdo con lo que dices, totalmente de

00:33:29.620 --> 00:33:34.820
acuerdo. Quiero hacer un recordatorio un
poquito en el punto en el que estamos ahora

00:33:34.820 --> 00:33:39.340
mismo. Va a haber unas personas que van a
estar escuchando esta charla bien en Apple

00:33:39.380 --> 00:33:42.940
Podcast o bien en Spotify, porque lo
grabaremos o lo subiremos a las plataformas de podcast

00:33:42.980 --> 00:33:48.720
y lo escucharán en diferido, pero para las
personas que están en directo ahora, si quieren

00:33:48.720 --> 00:33:51.740
participar, pueden simplemente levantar la
mano, subir al escenario, que nosotros sea

00:33:51.780 --> 00:33:56.720
hablar. Y recordar que es la primera vez
que estamos emitiendo en directo en YouTube,

00:33:56.800 --> 00:33:59.640
en tu canal, en el YouTube de Soy de Bea.

00:33:59.740 --> 00:34:03.580
Está por aquí, tenemos dos personas
mirando el directo ahora mismo.

00:34:03.700 --> 00:34:07.800
Para no haber... Dos personas,
no, soy yo, yo no soy y yo no soy.

00:34:08.360 --> 00:34:10.920
¿Sabes el chiste? El chiste
que dice, ¿qué tal te va?

00:34:10.960 --> 00:34:16.800
Dice, ah, pues grabé Un disco, ah, sí,
lo compré, dice, ah, fuiste tú, sí,

00:34:17.800 --> 00:34:22.244
es algo así, dos personas y un delito,
muy bien, y aquí tenemos unas cuantas que

00:34:23.140 --> 00:34:28.200
están aquí, son muchos fieles, si alguien
tiene alguna alguna pregunta puede levantar

00:34:28.200 --> 00:34:34.420
y unirse a nosotros libremente, porque
pues estamos tomándonos un café de verdad, estamos

00:34:34.420 --> 00:34:41.540
tomando un café de verdad, y quien ya lo
vea grabado, no, quien lo vea grabado ya tendrá

00:34:41.540 --> 00:34:45.140
que que contactarnos en la forma, quien lo
está viendo grabado puede darle al pausa y

00:34:45.180 --> 00:34:48.210
se hace un café y tomárselo
aquí con nosotros.

00:34:50.100 --> 00:34:55.240
Exacto Bueno Te están preguntando si te
gustó Buenos Aires ¿Qué pregunta es esa, Daniel?

00:34:55.600 --> 00:35:00.480
Claro que le gustó Si es más, estábamos
comentando Tú no vas solamente a las charlas

00:35:00.480 --> 00:35:05.920
Vas a las charlas y a ponerte Ciego de
carne De buena carne que tienes en Buenos Aires

00:35:05.920 --> 00:35:07.476
Pero bueno, que responde tú.

00:35:07.620 --> 00:35:08.720
Te gustó Buenos Aires, ¿no?

00:35:08.760 --> 00:35:12.360
Sí, la verdad es que me encantó la ciudad.

00:35:15.540 --> 00:35:17.800
¿Qué decir? Es impresionante.

00:35:17.880 --> 00:35:21.940
Es impresionante visto también
desde la perspectiva europea.

00:35:21.940 --> 00:35:28.580
Aquí no vemos esas avenidas con
20 carriles y el caos de tráfico.

00:35:29.640 --> 00:35:34.340
Y luego, Buenos Aires es una ciudad que en
muchos aspectos recuerda a una ciudad europea.

00:35:34.380 --> 00:35:36.900
No es más que a una
ciudad de Latinoamérica.

00:35:37.160 --> 00:35:39.380
Y me gustó, me gustó mucho.

00:35:39.640 --> 00:35:45.700
Pasé mucho, visité todos los sitios
turísticos, pero lo que más me gustó fue la gente.

00:35:45.860 --> 00:35:52.340
Me trataron espectacular, me estaban
esperando casi como una estrella.

00:35:53.200 --> 00:35:58.060
Bueno, en el evento un montón de fotos,
yo ya no sabía dónde meterme, ¿no?

00:35:59.240 --> 00:36:03.760
Fotos, fírmame el libro.
Impresionante, impresionante.

00:36:03.760 --> 00:36:09.720
La verdad es que recibí un cariño
impresionante y bueno, pues ese es el motivo también

00:36:09.720 --> 00:36:16.400
por el que fui, ¿no? Al final yo este año
tenía la posibilidad de ir al evento de MVP

00:36:16.400 --> 00:36:22.580
de Microsoft en Seattle o ir a este evento
aquí en Buenos Aires, porque el dinero no

00:36:22.580 --> 00:36:27.820
da para todo, obviamente, y al final, bueno,
pues como hemos hablado antes, yo tengo

00:36:27.820 --> 00:36:31.420
la comunidad en Telegram y mi
comunidad es SQL Server Español.

00:36:31.420 --> 00:36:36.580
Yo siempre desde el primer minuto existía
una comunidad SQL Argentina y yo podía haber

00:36:36.580 --> 00:36:40.900
hecho una comunidad SQL Server España,
pero yo no quería una comunidad SQL Server España.

00:36:40.940 --> 00:36:45.718
Yo desde el primer minuto dije, aquí lo
que nos une es SQL Server y hablar en español.

00:36:46.660 --> 00:36:51.420
Entonces yo quería una comunidad que fuese
en español para toda Latinoamérica, entonces,

00:36:51.460 --> 00:36:53.904
bueno, pues después de
años con la comunidad

00:36:55.240 --> 00:37:01.480
Dije, pues, creo que es momento de ir y
reunirme con esa comunidad, con esa comunidad

00:37:01.480 --> 00:37:06.640
que llevo años viendo y interactuando con
ellos en el blog, en comentarios de los vídeos

00:37:06.640 --> 00:37:12.540
de YouTube, en LinkedIn, ya sea
comentarios, mensajes, de todo, eventos online, porque

00:37:12.540 --> 00:37:17.540
organizamos un montón de eventos online
que nos vemos en videollamada un montón de veces,

00:37:17.600 --> 00:37:20.780
en eventos online un montón de veces,
pero no los conocíamos en persona.

00:37:20.820 --> 00:37:23.720
Entonces, pues llegar allí
y ver a los amigos de...

00:37:23.720 --> 00:37:27.380
Además, claro, como es un evento de toda
Latinoamérica, aunque se celebra en Buenos Aires,

00:37:27.420 --> 00:37:31.700
pero es un evento de toda Latinoamérica,
pues amigos de Chile, de Panamá, de Costa Rica,

00:37:31.740 --> 00:37:34.880
de Guatemala, de todos sitios.

00:37:34.880 --> 00:37:37.400
Pues sabes por donde te voy a ir yo ahora.

00:37:37.400 --> 00:37:44.660
En esta comunidad lo que nos une es las
bases de datos y el café, que si alguien es

00:37:44.660 --> 00:37:48.440
de té o de cerveza o de
whisky, también es bienvenido.

00:37:49.660 --> 00:37:56.960
Pero así que son las bases de datos
realmente Y fíjate que Nos hemos conocido A

00:37:56.960 --> 00:38:03.860
raíz un poco de Querer abrir Café Data
Base A más bases de datos que no sean solamente

00:38:03.860 --> 00:38:07.720
Si, por ejemplo, hemos hecho otros
episodios en el podcast en el que hemos hablado, pues,

00:38:07.760 --> 00:38:14.620
SQL Server, perdón, Oracle versus Mongo,
Oracle versus Postgres, es decir, hemos contrastado

00:38:14.620 --> 00:38:20.920
un poquito infraestructuras para saber qué
tienen unas, qué tienen las otras y tal, pero

00:38:20.920 --> 00:38:23.500
con SQL Server no había hecho ninguna.

00:38:23.500 --> 00:38:30.500
Y además, a mí el proyecto de Café
Database lo quiero ampliar a otros

00:38:30.500 --> 00:38:36.760
motores y que sea más, no solamente bases
de datos Oracle, sino que cada base de datos

00:38:36.760 --> 00:38:37.980
tenga aquí su representación, ¿no?

00:38:38.020 --> 00:38:45.040
Muchas veces tomo como ejemplo en la web
esta de DevEngines, que digamos hace un

00:38:45.040 --> 00:38:48.640
ranking de las bases
de datos más usadas y…

00:38:48.640 --> 00:38:52.800
Cuidado, es curioso y
eso hay que aclararlo.

00:38:52.880 --> 00:38:55.620
Hace un ranking de popularidad
de las bases de datos.

00:38:55.660 --> 00:39:02.770
No de las más usadas la más
usada sigue siendo SQLite, pero

00:39:02.770 --> 00:39:10.750
en popularidad no. Claro claro
claro lo que cuenta es publicaciones

00:39:10.750 --> 00:39:18.030
en blogs en foros y ese tipo de preguntas
en esta cover flow bien y en buscadores ahora

00:39:18.030 --> 00:39:24.550
se estarán reinventando a ver cómo
consiguen controlar las preguntas la guía pero mide

00:39:24.550 --> 00:39:30.550
popularidad no uso es saber el uso de la
base de datos es imposible Sí Sí, pero bueno,

00:39:30.610 --> 00:39:37.110
en esa popularidad, por ejemplo, sí, como
indicador, muchas veces, por lo que veo, sí

00:39:37.110 --> 00:39:43.810
me parece bastante consonante con la
realidad muchas veces, por ejemplo, estábamos viendo

00:39:43.810 --> 00:39:50.070
hace poco que había subido Snowflake, que
había subido Databricks, que Postgres había

00:39:50.070 --> 00:39:53.670
escalado puestos y cuando pregunté a
la gente, oye, ¿qué pasa con Postgres?

00:39:53.710 --> 00:39:59.790
Que sí que sí que mucha aceptación que el
proyecto es bastante sólido que funciona que

00:39:59.790 --> 00:40:06.950
aunque sea un open un producto open source
que está muy estabilizado y hay muchísimo

00:40:06.950 --> 00:40:15.100
apoyo y mucha solvencia por detrás y ese
cual es server también está ahí si mira

00:40:15.100 --> 00:40:20.820
por ahí nos lo decían antes no deberíamos
tener el avance de postgre yo no creo que sea

00:40:20.820 --> 00:40:27.160
tener avance de postgre creo cada base de
datos tiene su mercado no y es muy interesante

00:40:27.160 --> 00:40:34.290
creo que ahora que tiene su mercado s cual
se perdió su mercado tienen sus puntos fuertes

00:40:34.290 --> 00:40:40.630
en común y diferencias en el caso de en
común es el soporte de una empresa como es microsoft

00:40:40.630 --> 00:40:47.170
pues es hora que detrás ahora que tiene más
fama más estabilidad más en entornos más

00:40:47.170 --> 00:40:52.370
críticos s cual server tiene toda la
integración con el ecosistema microsoft que es muchísimo

00:40:52.370 --> 00:40:58.130
más grande en muchos otros aspectos
postgre tiene sus cosas si tiene sus cosas como base

00:40:58.130 --> 00:41:04.670
de datos gratuita es de código abierto Es
una pasada pero pero tienes que tener en cuenta

00:41:04.670 --> 00:41:12.230
el soporte y al final qué opciones tienes
de postgre con soporte oficial con alta disponibilidad

00:41:12.230 --> 00:41:17.710
oficial no montándote un servicio de alta
disponibilidad por fuera porque no tenemos

00:41:17.710 --> 00:41:22.210
un orgulloso no tenemos un rack no tenemos
que montarnos una alta disponibilidad por

00:41:22.250 --> 00:41:25.870
fuera si queremos poner una alta
disponibilidad si azules nos lo da pero ya estamos pasando

00:41:25.910 --> 00:41:32.600
por el aro de microsoft y también nos da
soporte pasando por el aro de microsoft bueno

00:41:33.050 --> 00:41:39.830
oye y en alta disponibilidad que plantea
que plantea microsoft porque a mí es algo montando

00:41:39.830 --> 00:41:45.910
racks había tocado montar racks en windows
y ha sido bueno en racks en windows y de atacarse

00:41:45.910 --> 00:41:52.430
en windows con activos pasos para mí esto
ha sido un dolor de cabeza tremendo como se

00:41:52.430 --> 00:41:55.870
lo contaste con este por el principio se
puede ser el tema alta disponibilidad que tal

00:41:55.910 --> 00:42:01.090
lo lleva alta disponibilidad de verdad es
de verdad o sea que pegas un botonazo a un

00:42:01.090 --> 00:42:07.170
a una de las dos máquinas y aquello
aguanta dos o tres o cinco máquinas no es el cual

00:42:07.170 --> 00:42:11.670
server tiene varios sistemas de alta
disponibilidad lo ha tenido siempre más sencillos

00:42:11.710 --> 00:42:18.270
más avanzados, pero bueno desde 2012
tenemos el Always On Availability Group que es el

00:42:18.270 --> 00:42:23.470
más avanzado, sin llegar a ser un cluster
triple A, pero es el más avanzado Y funciona

00:42:23.530 --> 00:42:29.130
de una manera completamente distinta como
lo conocéis en Oracle, que yo sepa lo que funciona

00:42:29.710 --> 00:42:35.210
con el Always On Availability Group lo que
tienes es varias réplicas de la base de datos

00:42:35.210 --> 00:42:40.170
varios servidores con la instancia corriendo
de manera independiente cada uno con su

00:42:40.170 --> 00:42:44.390
almacenamiento Y lo que hace es replicar
la transacción en tiempo real entre todas las

00:42:44.430 --> 00:42:49.850
instancias. Lo puedes hacer de manera
síncrona, de manera que cuando tú mandas la transacción

00:42:49.850 --> 00:42:54.150
al listener se escriben todos los servidores
y cuando todos los servidores confirman

00:42:54.190 --> 00:42:58.850
la escritura entonces se hace el commit y
realmente se confirma esa transacción de manera

00:42:58.890 --> 00:43:02.690
que es totalmente síncrono, pero
depende de la latencia de la red.

00:43:02.690 --> 00:43:08.750
En red local con redes buenas no tienes
problema porque la velocidad de filtro en disco

00:43:08.750 --> 00:43:13.850
siempre más lenta pero en redes
distribuidas pues puedes tener un problema y para eso

00:43:13.850 --> 00:43:19.010
existe la réplica síncrona no que la
transacción se escribe en el lot de transacciones

00:43:19.010 --> 00:43:21.770
que nosotros tenemos los de transacciones
por base de datos otro concepto que se hace

00:43:21.810 --> 00:43:27.930
yo voy a la cabeza y entonces se persisten
en los de transacciones por lo menos hasta

00:43:27.930 --> 00:43:33.270
que se hasta que se confirmen las réplicas
secundarias Eso nos implica que el log de

00:43:33.270 --> 00:43:36.820
transacciones no se vacía aunque se
haga backup, cosa que es Un peligro.

00:43:36.860 --> 00:43:38.860
Hay que tener muy bien monitorizado.

00:43:39.120 --> 00:43:44.240
Eso en cuanto a alta disponibilidad
con, digamos, cero downtime.

00:43:44.580 --> 00:43:51.940
Yo esto lo he visto en escenarios funcionar
con una red buena, tiempos de balanceo

00:43:51.940 --> 00:43:53.640
menores a un milisegundo.

00:43:54.000 --> 00:44:00.140
Se perdían dos pings. La transacción
ni se abortaba en un balanceo.

00:44:00.140 --> 00:44:05.360
Quiero decir, es una alta disponibilidad
completa y, como la información está escribiéndose

00:44:05.360 --> 00:44:09.700
en los dos servidores a la vez, hay cero
pérdida de datos y cero pérdida de servicio.

00:44:09.740 --> 00:44:16.820
¿Qué pasa? Que esto requiere una versión
SQL Enterprise para poder funcionar, cosa que

00:44:16.820 --> 00:44:20.440
para los que venimos del mundo SQL Server
es muy caro porque cuesta lo que cuesta Oracle

00:44:20.480 --> 00:44:25.800
básico. Entonces es caro, pero bueno...

00:44:25.800 --> 00:44:29.400
Bueno, y 10 nodos multiplica
por 10 el almacenamiento.

00:44:30.400 --> 00:44:33.360
Y la propagación y la
sincronización entre 10.

00:44:33.700 --> 00:44:38.000
Claro, pero te aseguras que, al no haber
un almacenamiento compartido, el almacenamiento

00:44:38.040 --> 00:44:39.707
no es un punto único de fallo.

00:44:39.820 --> 00:44:44.653
Porque tienes 10 almacenamientos
distribuidos, tienes el dato distribuido en 10 sitios.

00:44:45.380 --> 00:44:47.400
Claro, pero ves multiplicando, ¿eh?

00:44:47.540 --> 00:44:49.580
No, pero el almacenamiento es barato.

00:44:49.620 --> 00:44:51.453
El almacenamiento no es problema.

00:44:52.150 --> 00:44:53.983
El almacenamiento no es problema.

00:44:55.190 --> 00:44:56.968
El almacenamiento es muy barato.

00:44:58.220 --> 00:45:03.520
Fíjate cuando miramos Precios en la nube
El almacenamiento está a pocos euros el tera

00:45:03.520 --> 00:45:07.740
O a menos de un euro el tera
Depende en que servicio es cloud No

00:45:08.640 --> 00:45:14.220
En los pagos mensuales El almacenamiento
no es un problema realmente Ahora comprar discos

00:45:14.800 --> 00:45:18.560
A ti o a mi comprar un disco
de 8 teras Nos cuesta 300 euros

00:45:20.740 --> 00:45:22.440
El almacenamiento no es problema.

00:45:22.480 --> 00:45:24.869
El coste del almacenamiento
no es problema.

00:45:25.360 --> 00:45:27.620
Por lo menos. En mi opinión.

00:45:27.620 --> 00:45:29.840
Luego tenemos otra opción, ¿vale?

00:45:29.900 --> 00:45:35.900
Que es un poco más simple, que se puede
usar ya con licencias más básicas, que es el

00:45:35.900 --> 00:45:39.360
clúster de conmutación de instancia.

00:45:39.800 --> 00:45:44.240
Eso al sí tiene un almacenamiento compartido,
montas un clúster de Windows entre los

00:45:44.280 --> 00:45:49.920
dos servidores y atachas al clúster
de Windows el almacenamiento.

00:45:49.920 --> 00:45:55.320
por comparte los discos por y es casi por
pasar por como quieras vale el protocolo que

00:45:55.320 --> 00:46:00.740
quieras el caso windows permite muchísimos
tipos de almacenamiento compartido y básicamente

00:46:00.740 --> 00:46:06.500
lo que tienes es dos servidores con la
instancia instalada pero sólo está corriendo en

00:46:06.500 --> 00:46:11.220
uno que es la que tiene los discos
asignados en caso de servidor caiga balance al otro

00:46:11.260 --> 00:46:18.340
y el otro levanta tiene que arrancar el
servicio mis pruebas durante muchos años siempre

00:46:18.340 --> 00:46:22.280
me dan un tiempo de alrededor de unos 20
segundos de parada de servicio pero tampoco

00:46:22.320 --> 00:46:29.830
hay pérdida de datos porque el disco es el
mismo así que realmente no es tampoco un gran

00:46:29.830 --> 00:46:36.830
problema problema que así en windows en el

00:46:36.830 --> 00:46:43.870
almacenamiento si estaba en un
lugar y únicamente podía estar

00:46:43.870 --> 00:46:51.330
asignado a uno de los los
servidores o conmutar a al otro

00:46:51.330 --> 00:46:55.630
y entonces implicaba parar de forma
ordenada arrancar y ahí si hay un momento en el que

00:46:55.670 --> 00:47:02.010
Está parada y arranque si estás con él a
ver yo te digo mis pruebas son unos 20 segundos

00:47:02.010 --> 00:47:09.210
porque en en sql server han mejorado
mucho todo el tema de el ruido y

00:47:09.210 --> 00:47:15.210
del mundo en el arranque con una nueva
funcionalidad que me tiene en 2019 que se llama

00:47:15.210 --> 00:47:21.690
adr acelera y database recovery al final
lo que hace es usa un nivel de transacciones

00:47:21.690 --> 00:47:26.170
por snapshot igual que el que usa el que
usa oracle y entonces para revertir las transacciones

00:47:26.210 --> 00:47:30.510
no necesita irse a los de transacciones y
revertir transacción a transacción sino que

00:47:30.550 --> 00:47:37.750
tiene el snapshot entonces es
prácticamente instantáneo es esa recuperación en eso en

00:47:37.750 --> 00:47:39.972
sql server vamos aprendiendo de vosotros

00:47:41.730 --> 00:47:46.870
Aunque no es el modo por defecto de
aislamiento Sí que permite el modo de aislamiento

00:47:46.870 --> 00:47:54.380
por Snapshot El ritmo de Snapshot sí que
lo permite Es más, tenemos desde 2025 en

00:47:54.380 --> 00:48:01.790
On -Premise Y desde 2024 en Azure Tenemos
los bloqueos optimizados Que es llevar el

00:48:01.790 --> 00:48:06.450
aislamiento por Snapshot a las escrituras
Eso es una barbaridad Escrituras no bloquean

00:48:06.490 --> 00:48:12.840
escrituras Por fin Sí O sea, la lectura no
bloquea escritura, la escritura no bloquea

00:48:12.840 --> 00:48:16.451
lectura, por fin. No, no, no y la
escritura no bloquea escritura.

00:48:17.750 --> 00:48:19.990
¿La escritura no bloquea escrituras?

00:48:21.370 --> 00:48:28.430
A ver, en Oracle existe una
cosa que se llama los lock -free

00:48:28.430 --> 00:48:35.690
reservations. Que es, más que hacer un
bloqueo, tú lo que haces es una reserva.

00:48:35.810 --> 00:48:38.150
No, esto es completamente...

00:48:38.150 --> 00:48:41.190
¿No se vive eso? ¿Una escritura
no bloquea una escritura?

00:48:41.230 --> 00:48:45.897
¿Vamos a ver, un update no bloquea a la
gente que está esperando que haga el update?

00:48:46.450 --> 00:48:48.590
Efectivamente, y te cuento cómo funciona.

00:48:48.630 --> 00:48:54.610
Tú haces un bloqueo sobre la transacción y
lo que almacenas en tus tablas de sistema

00:48:54.610 --> 00:48:57.690
es esta fila ha sido alterada
por esta transacción.

00:48:58.130 --> 00:49:05.310
De manera que cuando hay otra escritura,
yo puedo ver el código de la primera, compararlo

00:49:05.310 --> 00:49:10.810
con la segunda y si no coinciden los
predicados afectan a filas distintas no se bloquean

00:49:10.810 --> 00:49:17.840
muy Bien es comparar predicados porque el

00:49:17.840 --> 00:49:24.650
bloqueo se hace en transacción no se hace
en fila ni en página ni en tabla se hacen transacción

00:49:24.650 --> 00:49:29.470
y lo que almacena es cada fila tiene un
metadato de la última transacción que lo ha modificado

00:49:29.510 --> 00:49:36.660
es una pasada es una pasada tiene
que ver funcionando esto está

00:49:36.660 --> 00:49:43.140
funcionando tiene implicaciones vale claro
porque porque puede ser que tú estés accediendo

00:49:43.140 --> 00:49:47.220
a la misma fila con distintos predicados y
entonces la transacción se puede perder por

00:49:47.260 --> 00:49:51.980
eso obviamente esto se habilita aparte
pero quien accede normalmente en un entorno productivo

00:49:52.020 --> 00:49:56.980
a la misma fila de dos maneras distintas
nadie todos accedemos por idea para eso te cuidado

00:49:57.020 --> 00:50:04.180
cuidado si me dieran un euro por
cada de blog ya si me dieran un euro

00:50:04.180 --> 00:50:07.540
por cada de blog ahora
mismo estaríamos hablando…

00:50:07.540 --> 00:50:09.960
Yo me hubiera ido a
verte, hubiera cogido una…

00:50:10.000 --> 00:50:13.020
Me hubiera ido a verte, en
tu caso me hubiera vuelto.

00:50:13.220 --> 00:50:15.831
Se me hubiera contado un
euro por cada bloqueo.

00:50:17.460 --> 00:50:23.220
Pero no es lo mismo, porque no estoy
hablando de que no accedan a la misma fila en distinto

00:50:23.220 --> 00:50:25.140
orden. Estoy hablando de distinta manera.

00:50:25.180 --> 00:50:28.513
Normalmente tú accedes a la
fila por su identificador único,

00:50:28.560 --> 00:50:34.080
Para escribirla. Accedes por el…

00:50:34.080 --> 00:50:38.080
Sí. Todo depende, un
update, where, lo que sea.

00:50:39.930 --> 00:50:43.070
Es que he visto mucho mundo, compañero.

00:50:43.310 --> 00:50:45.170
O sea, por eso te digo...

00:50:45.170 --> 00:50:49.850
A ver, por eso te digo, normalmente, y que
puede pasar, y que por supuesto esto se habilita

00:50:49.890 --> 00:50:56.580
aparte. Porque es verdad que es peligroso,
sobre todo porque llevamos 50 años trabajando

00:50:56.580 --> 00:50:59.800
de la misma manera, no porque
tenga más implicación que esa.

00:50:59.840 --> 00:51:04.060
Sí, sí, sí porque llevamos 50 años
acostumbrados a trabajar de una manera, y si nos la

00:51:04.100 --> 00:51:09.211
cambian, pues igual no estábamos haciendo
las cosas bien, pero llevamos 50 años haciéndolas.

00:51:09.300 --> 00:51:13.320
Claro, en hora que tú tienes los bloqueos,
los bloqueos son para empezar a nivel de fila.

00:51:13.360 --> 00:51:17.220
Es la fila la que tiene el bloqueo porque
se controla la transacción a nivel de cada

00:51:17.260 --> 00:51:23.420
una de las filas. Puede ser que en un bloque,
cuando se satura con transacciones, el

00:51:23.420 --> 00:51:30.480
bloque pueda estar causando esperas porque
el bloque esté cargado de transacciones,

00:51:30.540 --> 00:51:35.620
no hay espacio de control de transacciones
y el bloque cause hay unas esperas.

00:51:35.680 --> 00:51:40.060
No es lo normal, el mecanismo
de bloqueo suele ser la fila.

00:51:40.300 --> 00:51:44.200
Pero en eso, por ejemplo, para que veas un
poco por dónde ha ido Aracle, Aracle ha creado

00:51:44.240 --> 00:51:48.560
lo que te estaba contando, que eran las
Lockfield Reservations, que es decir, yo voy

00:51:48.600 --> 00:51:54.820
a establecer para aquellas columnas en las
cuales, imagínate, decimos el ejemplo, Rosalía

00:51:54.820 --> 00:52:00.520
viene a España a hacer cuatro conciertos,
van a salir a la venta 200 .000 entradas y

00:52:00.520 --> 00:52:02.131
en un minuto se van a vender.

00:52:02.320 --> 00:52:05.900
En cinco minutos se van a
vender 200 .000 transacciones.

00:52:06.380 --> 00:52:13.640
¿Cómo haces, es decir, el control De 200
.000 menos una, 200 .000 menos dos, 1

00:52:13.640 --> 00:52:20.160
.999 menos uno, cómo vas haciendo todo ese
control de updates de no vender más entradas

00:52:20.160 --> 00:52:25.640
de las que hay? Oracle tiene como una
tabla journal para esa columna en la cual dices,

00:52:25.740 --> 00:52:30.462
bueno, cuando se hagan updates y mientras
esos updates no estén pendientes de commit,

00:52:30.560 --> 00:52:37.580
yo en una tabla externa voy gestionando
la disponibilidad de ese update y

00:52:37.580 --> 00:52:42.740
está muy limitado. Es cuando haces campo
es igual a campo menos uno, campo es igual a

00:52:42.740 --> 00:52:46.320
campo más uno, es decir, transacciones
que tienen una aritmética simple, ¿no?

00:52:46.360 --> 00:52:52.300
De control de stock o de ventas para no
bloquear sobre todo por reserva, ventas.

00:52:52.300 --> 00:52:57.240
SQL Server eso siempre lo ha gestionado de
otra manera a mi parecer más eficaz y es que

00:52:57.240 --> 00:52:59.880
tiene un sistema de escalación de bloqueos

00:53:01.020 --> 00:53:07.060
es decir, a priori escala por fila o sea,
bloquea por fila pero cuando tienes muchas

00:53:07.060 --> 00:53:11.140
filas en la misma tabla bloqueadas o en la
misma página directamente el B que es más

00:53:11.180 --> 00:53:15.060
sencillo bloquear la página de datos y
bloquear la página de datos sabes que los datos

00:53:15.100 --> 00:53:19.440
en SQL Server se almacenan en páginas de
8K entonces te bloqueo la página directamente

00:53:19.480 --> 00:53:23.000
ya no te bloqueo la fila sino que te hago
el bloqueo a la página Que puede haber efectos

00:53:23.040 --> 00:53:25.520
colaterales porque una fila no
se estaba editando y ya está.

00:53:25.560 --> 00:53:29.420
Bueno, pero es un Daño menor
comparado a lo que me estás contando.

00:53:30.080 --> 00:53:32.858
Incluso puedo escalar el
bloqueo a nivel de tabla.

00:53:33.950 --> 00:53:35.690
Entonces el bloqueo puede escalar.

00:53:35.730 --> 00:53:40.990
Si tú miras la tabla de sistema de los
bloqueos, donde ves los bloqueos, tú ves el bloqueo

00:53:40.990 --> 00:53:42.030
y el bloqueo de intención.

00:53:42.070 --> 00:53:46.730
Él registra ya un bloqueo En este caso un
bloqueo exclusivo que lo representa Con una

00:53:46.770 --> 00:53:52.190
X, del tipo X Y representa, a nivel de
fila, y representa Un bloqueo IX, que es intención

00:53:52.190 --> 00:53:57.800
de exclusividad En la página En caso de
que empiece a haber Muchas filas de esa página

00:53:57.800 --> 00:54:03.960
con bloqueo X Directamente, elimina todos
Esos bloqueos y escala Al que tenía ya registrado

00:54:03.960 --> 00:54:05.940
Como de intención de página

00:54:06.980 --> 00:54:13.520
Wow, yo esa Eso ha funcionado así siempre
De toda la vida en SQL Server Y han ido escalando.

00:54:13.640 --> 00:54:18.020
De manera que simplificas mucho esa carga
de trabajo de no tener que estar gestionando

00:54:18.060 --> 00:54:21.580
millones de filas en mi tabla
de metadatos de los bloqueos.

00:54:22.640 --> 00:54:26.807
Pero ahora va un poco más allá y el
bloqueo lo hace a nivel de transacción.

00:54:26.880 --> 00:54:31.380
La fila almacena qué transacción la ha
modificado y puedo comparar predicados.

00:54:31.380 --> 00:54:36.160
Y puedo decir, si este está actualizando
todos los que tengan, todos los empleados de

00:54:36.160 --> 00:54:40.100
sueldo menor que 1000 y este está
actualizando todos los empleados con sueldo mayor que

00:54:40.140 --> 00:54:43.540
10 .000, no se chocan entre
ellos, adelante las dos.

00:54:45.450 --> 00:54:49.270
Porque este está mirando en el web menos
que 1000 y este en el web pone más que 1000.

00:54:49.310 --> 00:54:53.880
Es que en Oracle no se hubieran
chocado, porque son filas distintas.

00:54:55.800 --> 00:55:01.280
Hubieran podido convivir y avanzar
cada uno por su lado sin cuestionar.

00:55:01.280 --> 00:55:05.560
Pero si la tabla tiene muchos datos, en
SQL Ese bloqueo hubiese escalado Y entonces sería

00:55:05.600 --> 00:55:12.980
a nivel de tabla o a nivel de página
Claro Oye, y aprovechando que El pizorga

00:55:12.980 --> 00:55:19.040
pasa por Veo de Lid Oye, ¿y por qué
no te unes A un café de atabase?

00:55:19.160 --> 00:55:22.600
Como el frontman De SQL Server

00:55:23.600 --> 00:55:28.960
Está en el radar Pero ya sabes
tú que mi agenda es complicada.

00:55:29.760 --> 00:55:33.140
Lo sé, lo sé, pero pero
tengo que intentarlo.

00:55:33.260 --> 00:55:39.000
Tengo que intentarlo. Sería muy
interesante porque cada vez veo, así como estamos hablando

00:55:39.000 --> 00:55:44.960
de que cada vez más el mundo es más multicloud,
cada vez de lo que veo en LinkedIn y

00:55:44.960 --> 00:55:50.420
lo que me comentan muchos alumnos y tal,
muchas veces las ofertas empleables y el rol

00:55:50.420 --> 00:55:54.980
de DBA pasa también por
dominar varios motores.

00:55:54.980 --> 00:56:02.400
No solamente nos pide en Oracle
y otra cosa más, vaya melón bueno

00:56:04.610 --> 00:56:05.930
¿Tú crees que se puede ser?

00:56:05.970 --> 00:56:08.810
Ahora te voy a entrevistar yo a ti.

00:56:09.390 --> 00:56:11.446
Hola, ¿qué tal, Roberto? ¿Cómo estás?

00:56:12.620 --> 00:56:19.040
A ver, Javier, ¿tú crees que se puede ser
un buen especialista en una base de datos si

00:56:19.040 --> 00:56:23.360
tocas más de una? ¿Tú crees que se puede
alcanzar el nivel de especialización que tienes

00:56:23.400 --> 00:56:27.520
tú o yo en Oracle o en SQL
Server tocando más de una?

00:56:27.940 --> 00:56:30.384
Yo creo que no. ¿Alcanzar
este nivel en dos?

00:56:30.980 --> 00:56:32.180
Yo no puedo. Yo creo que no.

00:56:32.220 --> 00:56:36.440
Yo tengo nociones básicas de Postgre, yo
tengo, con Oracle trabajo poco, tengo nociones

00:56:36.480 --> 00:56:41.160
básicas de Postgre, pero tengo nociones
básicas de Postgre, soy un junior total en Postgre.

00:56:41.200 --> 00:56:46.480
Yo menos que junior. A lo largo
de mi carrera he tenido...

00:56:46.480 --> 00:56:49.280
Te sorprendería porque sabes lo que
quieres hacer, es lo que hablábamos antes, tienes

00:56:49.320 --> 00:56:50.860
los fundamentos de una base de datos.

00:56:50.900 --> 00:56:54.240
Sí. Te sorprendería.
Pero, pero, no, no, pero.

00:56:54.240 --> 00:57:01.160
Pero desde que empecé con Oracle, cada vez
que me habían propuesto algo, es decir, horizontalizarme

00:57:01.160 --> 00:57:04.382
en infraestructuras de base
de datos, siempre dije que no.

00:57:04.860 --> 00:57:12.680
Porque a mi entender, uno se
hace experto verticalizando y,

00:57:12.740 --> 00:57:15.780
digamos, completando esa pirámide
de conocimiento vertical.

00:57:15.820 --> 00:57:19.709
Claro, como ahora me estás interesando,
te lo cuento yo en mi opinión.

00:57:21.000 --> 00:57:25.500
Con conocimiento de
apoyo de esa tecnología.

00:57:26.060 --> 00:57:31.420
Entonces, nunca he tocado ni SQL
Server, ni Postgres, ni Mongo, ni nada.

00:57:31.580 --> 00:57:36.960
Solo he tocado Oracle. Y si puedo decir que
sé algo de Oracle es porque no he tocado

00:57:36.960 --> 00:57:40.680
nada más. Así que,
respondiendo a tu pregunta…

00:57:41.600 --> 00:57:45.800
Pero claro, eso no quiere decir que una
persona que empiece ahora y que quiera ver niveles

00:57:45.840 --> 00:57:51.560
básicos o quiera aprender administración
de Oracle, le diga, oye, veo dos palos, veo

00:57:51.560 --> 00:57:57.300
tres palos o abro juego
a decir algún motor más.

00:57:57.300 --> 00:58:03.760
Ahí estoy de acuerdo contigo, y lo que yo
suelo ver es que estas ofertas cross database,

00:58:04.320 --> 00:58:07.600
como yo las suelo llamar, no son senior

00:58:09.100 --> 00:58:10.380
No son senior, son junior.

00:58:10.420 --> 00:58:14.420
O sea, yo he trabajado en equipos
así y funcionaba realmente bien.

00:58:14.480 --> 00:58:20.260
Teníamos un equipo de primer nivel cross
database, que tocaba Oracle y tocaba SQL Server,

00:58:20.460 --> 00:58:23.960
y luego teníamos un segundo nivel de SQL
Server, un segundo nivel de Oracle, un tercer

00:58:24.000 --> 00:58:26.730
nivel de SQL Server y un
tercer nivel de Oracle, ¿vale?

00:58:26.770 --> 00:58:29.730
El primer nivel sí que era cross database.

00:58:30.090 --> 00:58:35.710
Y a partir de ahí, los chavales entraban,
empezaban a tocar, tocaban Mongo, tocaban Oracle,

00:58:35.890 --> 00:58:38.690
tocaban Postgre, tocaban
MySQL y tocaban SQL Server.

00:58:38.730 --> 00:58:42.270
Y a partir de ahí, tú
veías en qué destacaba.

00:58:42.430 --> 00:58:47.230
Y luego iban subiendo, pero cuando llegaban
al segundo nivel, era una, un motor ya.

00:58:47.530 --> 00:58:51.510
Ya era un motor. Ya,
olvídate de todo lo anterior.

00:58:51.510 --> 00:58:55.850
Te viene muy bien todo lo que has
aprendido de las otras tecnologías, pero ahora te centras

00:58:55.890 --> 00:59:00.650
en esta y vas a verticalizarte en esta, lo
que tú dices, y vas a especializarte aquí.

00:59:00.650 --> 00:59:06.050
Entonces, para mí, un equipo
multidisciplinar de base de datos puede tener sentido en

00:59:06.050 --> 00:59:12.770
un nivel junior, en un nivel 2 podrías
encontrar a alguien, pero un nivel 2 ya muy básico,

00:59:12.770 --> 00:59:15.690
pero en un nivel 3 de soporte, imposible.

00:59:15.690 --> 00:59:20.250
O sea, no vas a encontrar a nadie
con un nivel 3 multiplataforma.

00:59:20.250 --> 00:59:26.230
Bueno, sí, el puto loco de Brent Nozar en
Estados Unidos, que es un referente número

00:59:26.230 --> 00:59:32.530
uno en SQL Server, digamos que es el
número uno en SQL Server en el mundo, fácil, fuera

00:59:32.880 --> 00:59:37.920
de Microsoft, ¿vale? Te hablo de fuera de
Microsoft porque obviamente Bob Ward lleva

00:59:37.920 --> 00:59:42.460
haciendo SQL desde que SQL es SQL y es el
Product Manager desde el principio de los tiempos

00:59:42.500 --> 00:59:44.760
hasta hoy y no le vas a superar.

00:59:44.760 --> 00:59:50.000
Pero entonces eres número uno en SQL
Server y sí que tiene un nivel de Postgre muy, muy,

00:59:50.000 --> 00:59:55.780
muy avanzado. No es el mismo que en SQL
Server, por supuesto que no, pero es muy avanzado

00:59:55.780 --> 01:00:00.820
y mucho más de lo que podría tener
cualquiera de los incluso nivel 3 que vas a ver por

01:00:00.820 --> 01:00:07.850
aquí. Voy a ir más allá. Incluso
en Oracle tengo que elegir

01:00:07.850 --> 01:00:13.210
en qué me especializo porque tampoco puedo
tocar todos los Palos de un único motor.

01:00:13.670 --> 01:00:18.830
Eso te iba a decir, yo tengo colegas en
SQL Server centrados en optimización, tengo colegas

01:00:18.830 --> 01:00:23.550
en SQL Server centrados en alta
disponibilidad y tengo colegas centrados en ramas específicas

01:00:23.590 --> 01:00:26.150
que son unos verdaderos cracks en eso.

01:00:26.350 --> 01:00:33.450
Obviamente tienen el conocimiento mayor que
la mayoría de todo lo demás, pero el que

01:00:33.450 --> 01:00:40.210
tienen en su especialización, yo mal que
me pese me estoy especializando en el rendimiento

01:00:40.210 --> 01:00:43.170
porque a mí me gusta mucho más la
infraestructura, las cosas como son.

01:00:43.210 --> 01:00:46.590
Yo vengo de la rama de infraestructura y
me gusta mucho más la infraestructura, pero

01:00:46.630 --> 01:00:50.450
por cómo han ido los proyectos y por cómo
han ido las cosas, pues me he especializado

01:00:50.490 --> 01:00:51.970
mucho más en el rendimiento.

01:00:52.010 --> 01:00:57.730
Obviamente la infraestructura me gusta y
como tal le dedico mucho tiempo, pero el grueso

01:00:57.730 --> 01:01:03.790
laboral es performance, es
optimización de código y es lo que hay.

01:01:04.570 --> 01:01:08.650
Entonces también no depende de ti, sino de
la suerte que hayas tenido en el proyecto

01:01:08.690 --> 01:01:16.720
que hayas ido cayendo. Ah, yo aquí
discrepo yo creo que hay que ser valiente y tirarse

01:01:16.720 --> 01:01:23.800
a Elegir un camino y decir, a mí
me gusta la alta disponibilidad,

01:01:23.800 --> 01:01:30.780
pues venga, intento rechazar proyectos, me
vendo proyecto, mi autoridad hacia alta disponibilidad,

01:01:30.780 --> 01:01:35.640
estudio alta disponibilidad, me certifico,
voy empujando hacia allí y digamos que todo

01:01:35.640 --> 01:01:36.940
vaya un poco de tu consonancia.

01:01:36.980 --> 01:01:42.400
Eso puede pasar, pero no te hablo de eso,
aquí todos somos de veas por accidente, es

01:01:42.400 --> 01:01:49.420
verdad, o sea, es así, porque a ver,
tienes la escuela, pero qué formación reglada hay

01:01:49.420 --> 01:01:54.100
de base de datos, todos los que hemos
llegado de vea o hemos estudiado sistemas o hemos

01:01:54.140 --> 01:01:57.900
estudiado desarrollo, yo vengo de la rama
de sistemas, muchos tienen de la rama de desarrollo

01:01:57.940 --> 01:02:02.460
y al final termina siendo el de sistemas
que toca la base de datos o el de desarrollo

01:02:02.500 --> 01:02:06.220
que toca la base de datos y de ahí vas
tocando cada vez más la base de datos y y haciendo

01:02:06.260 --> 01:02:10.160
menos sistemas o menos desarrollo,
pero todos somos de veas por accidente.

01:02:10.200 --> 01:02:11.820
No hemos elegido estar aquí.

01:02:12.020 --> 01:02:14.160
Otro melón que acabas de abrir también.

01:02:14.200 --> 01:02:20.920
O sea, ¿cuántas veces he oído que SQL
es la asignatura María de la carrera?

01:02:20.940 --> 01:02:23.180
¿Y qué bases de datos
es la asignatura María?

01:02:23.220 --> 01:02:25.860
Porque hacer un join es un sobresaliente

01:02:26.760 --> 01:02:32.370
en la carrera. Claro. Si lo que te
exigen es hacer una query con un join.

01:02:33.060 --> 01:02:39.570
Una función, como mucho. Mi
caso fue un poco distinto.

01:02:39.830 --> 01:02:43.630
Yo sí toqué Oracle y sí toqué...

01:02:43.630 --> 01:02:50.750
pero no porque esté en el plan,
porque dicen con un profesor

01:02:50.750 --> 01:02:53.440
que te lo enseñó. Sí, sí.

01:02:53.500 --> 01:02:55.480
Porque el plan de estudio es el que es.

01:02:55.520 --> 01:02:58.960
El plan de estudio es
hacer código SQL básico.

01:02:59.630 --> 01:03:02.870
Sí, sí. Hacer un Ayoide es un excelente.

01:03:04.480 --> 01:03:08.440
¡Qué grande! Oye, pues se
nos está quedando corto.

01:03:08.440 --> 01:03:10.940
Se ha pasado una horita.
¿Qué tal has estado?

01:03:11.140 --> 01:03:13.260
Pues muy a gusto, la verdad.

01:03:14.840 --> 01:03:17.440
Una conversación muy interesante
como siempre contigo.

01:03:17.480 --> 01:03:19.647
Tenemos muchas cosas de las que hablar.

01:03:20.520 --> 01:03:26.140
Mi casa es tu casa, Roberto tío, cuento
contigo para que pienses algún tinglao para hacer

01:03:26.140 --> 01:03:27.900
Encafeada a base de SQL Server.

01:03:27.900 --> 01:03:33.240
Podemos lanzar una sonda a que todos
aquellos que queráis que Roberto haga alguna

01:03:34.440 --> 01:03:41.960
Alguna mandanga en Café de Atabase, lo
que sea, me escribís amigo a él y...

01:03:45.150 --> 01:03:46.610
Y lo hacemos, lo hacemos.

01:03:47.630 --> 01:03:51.230
Tengo muchas ganas. También te digo, ayer
me cancelaron una charla que tenía este mes,

01:03:51.270 --> 01:03:54.470
por suerte, porque era la octava del mes.

01:03:56.520 --> 01:03:58.760
No, si me compartiste tu agenda.

01:03:59.000 --> 01:04:01.460
Me compartiste tu agenda
y dije, yo dije, bueno...

01:04:01.500 --> 01:04:04.260
Y dijiste, este hueco es el
único que tienes y aquí estoy.

01:04:04.300 --> 01:04:07.633
Este señor se ha apuntado el
divorcio, tengo que advertirle.

01:04:08.960 --> 01:04:16.060
Y por suerte mi chica también está en la
comunidad como asistente normalmente, pero

01:04:16.060 --> 01:04:18.980
le gusta mucho. Me intenta
acompañar a todos los eventos.

01:04:19.020 --> 01:04:23.920
Argentina no ha podido ser porque
económicamente es un gran desembolso, pero bueno, ahora

01:04:23.960 --> 01:04:29.420
todos los que quedan de aquí a final
de año espero que pueda estar también.

01:04:29.420 --> 01:04:35.820
Entonces, por eso no me cuesta puntos de
familia ir a los eventos, pero si no, sí que

01:04:35.820 --> 01:04:39.560
podría ser un problema. Pero sí,
haremos cosas juntos, seguro.

01:04:39.600 --> 01:04:45.240
Hay mucho que hacer. Y yo también te
invito a que te pases un día por nuestras comunidades

01:04:45.240 --> 01:04:47.920
de datos a ver esa diferencia.

01:04:50.940 --> 01:04:57.760
Cuenta con ello, cuenta con ello, claro
que sí, y también cuando me invites a tu casa

01:04:57.760 --> 01:05:02.280
voy encantado. Si es un podcast,
si es una charla o lo que sea,

01:05:03.320 --> 01:05:08.460
y tenemos muchas cosas a hablar de
optimización, tenemos muchas cosas a hablar de optimización

01:05:08.500 --> 01:05:16.060
porque ahí hay mucho matiz de cómo se
hace, es decir, la teoría es pero el

01:05:17.020 --> 01:05:20.980
cómo se materializa en cada uno uno de los
motores, seguro que es súper fascinante ver

01:05:21.020 --> 01:05:27.400
cómo... Bueno, aquí estamos hablando de
bloqueos que no estaba preparado, no estaba pensado,

01:05:27.440 --> 01:05:30.620
y ha salido ahí una charla interesante.

01:05:30.700 --> 01:05:34.000
Es que no tenemos guión. Es
que estamos sin guión aquí.

01:05:34.400 --> 01:05:40.150
O sea, ya... ¡Sin guión! Os vamos a
contar, hemos dicho, vamos a hablar un poco de comunidad,

01:05:40.350 --> 01:05:47.370
del MVP, y la diferencia con el
Ace de Oracle, y un poco de lo que

01:05:47.370 --> 01:05:52.950
queramos, de los libros, Y de lo que vaya
surgiendo Ha surgido los bloqueos Como podía

01:05:52.950 --> 01:05:56.910
haber surgido Bueno, y la alta
disponibilidad como podía haber surgido otra cosa Pero

01:05:56.950 --> 01:06:04.270
son los temas que nos han surgido
Que bueno Pues lo dicho Roberto,

01:06:04.390 --> 01:06:07.590
nos estamos yendo un poquito ya del tiempo
A lo mejor siempre suele ser solo una hora

01:06:07.630 --> 01:06:12.250
No nos liamos Si, lo
dicho Mi casa es tu casa

01:06:13.770 --> 01:06:15.890
Hagamos algo juntos.
Hagamos más cosas juntos.

01:06:15.930 --> 01:06:21.130
Un placer, es un tío muy
grande, muy potente, así que

01:06:22.650 --> 01:06:26.370
Un placer hablar contigo,
lo que quieras pide.

01:06:26.870 --> 01:06:31.710
Muchas gracias, yo he estado muy a gusto y
nada, lo que dije en Argentina te lo digo

01:06:31.710 --> 01:06:34.543
a ti, he estado tan a gusto
que amenazo con volver.

01:06:34.750 --> 01:06:37.050
Que, bueno, ahí queda la amenaza.

01:06:38.640 --> 01:06:43.740
Pues te tomo la palabra compañero vale, te
mando un fuerte abrazo y todos los que estéis

01:06:43.740 --> 01:06:49.500
aquí pues un abrazo un abrazo también a
vosotros, gracias por estar Adiós Chao, chao