Modelado de Bases de Datos Relacionales para GraphQL

Bienvenidos a la masterclass de hoy. Soy Adrian. Esto es modelización relacional con GraphQL en mente. Así que hay algunos requisitos previos que se señalan. Por supuesto, nadie tiene que seguir el ritmo. Sin embargo, he orientado este material hacia hablar sobre temas particulares y luego trabajar realmente con todos ustedes a través del contenido.

Así que habrá algo de codificación, habrá algo de diseño, y luego habrá la puesta en marcha de servicios y cosas así. Así que si quieres seguir el ritmo para sacar el máximo provecho de esta masterclass, puedes hacerlo absolutamente. Y he puesto aquí que estaré usando un poco de Postgres Docker, pero lo he hecho de manera que ni siquiera necesito usar eso. Lo único que necesitarás es una cuenta, a la que puedes registrarte incluso ahora mismo, es bastante rápido poder hacerlo, con DB diagram y Hasura y prospectivamente Heroku. Heroku estará proporcionando la base de datos Postgres database de vuelta para Hasura cuando llegue a esa parte de la masterclass. Y habrá tiempo para registrarse en cada uno de ellos rápidamente si aún no lo has hecho.

He dividido esto en dos partes. Pasaremos por la primera parte, construiremos un esquema de database, diseñaremos algunas cosas, gracias Daria, y luego haremos una breve pausa, básicamente una pausa biológica, antes de entrar en la segunda parte. Así que la primera parte, de nuevo, modelización relacional, construiremos un esquema real. Algo así. Eso es dbDiagram por cierto. Así que eso es en lo que estaremos trabajando. Y luego en la segunda parte, profundizaremos más en los modelos de data relacionales. Lo que obtenemos cuando hacemos consultas multi-unidas y las relaciones dentro de la database, pero también lo que obtendríamos usando una herramienta como Hasura, que usaré para mostrar cómo ve las relaciones y cómo las construye para las consultas GraphQL basadas en las relaciones y la modelización de la base de datos subyacente. Y así es como se ve la herramienta Hasura. Usaremos principalmente la sección GraphQL, que facilita mucho la construcción de las consultas GraphQL y veremos algunas de las otras partes, como el Explorador, el CodeExporter, cosas así. También estaremos mirando la sección de data para interactuar directamente con la database en algunos de los diseños y todo. Y para ejecutar algunos de nuestros SQL iniciales que escribiremos. Y puede que use un poco la Hasura CLI. Es una gran herramienta para conseguir, si vas a usar Hasura y vas a construirte el flujo de trabajo de desarrollo alrededor de ella, definitivamente consigue la CLI también. Tiene muchas características geniales para hacer migraciones, rellenar los metadatos, y simplemente trabajar e interactuar de una manera automatizada, o ser capaz de construir un camino automatizado para tus tooling. Y luego voy a tomar el tiempo para pasar a la siguiente parte de tus tooling.

Muy bien, vamos a empezar con los conceptos relacionales. Mencionaré algunas cosas sobre las bases de datos NoSQL. Principalmente, sin embargo, esta masterclass entera va a estar orientada a las bases de datos relacionales. Así que centrado en las ideas detrás de eso. Pero mencionaré algunos de los otros porque son bastante prevalentes en estos días. Y hay muchos conceptos compartidos entre muchos de estos. Y ayuda a conocer la diferencia entre los conceptos allí versus los conceptos en el modelo relacional. Así que mencionaré eso en algunas partes.

Y esas cosas que mencioné principalmente están sólo enfocadas en torno a las bases de datos distribuidas basadas en columnas y documentos como Mongo y Apache Cassandra. Y mencionaré un poco sobre las bases de datos de gráficos como Neo4j o algo así. Neo4j, Titan y los otros. No voy a mencionar las series de tiempo. No voy a mencionar algunas de las otras bases de datos NoSQL de nicho en este punto. Sin embargo, si tienes curiosidad, asegúrate de seguirme y registrarte para futuras masterclass y eventos en Hasura y bajo mis cuentas que proporcionaré al final de esto. Así que no hay razón para preocuparse por esos ahora. Hago mucho streaming y otras cosas así en torno a todo tipo de tipos de bases de datos. Así que he hecho mucho trabajo en eso, me encantaría compartirlo.

Muy bien, comenzando en el mundo relacional para cubrir la forma estándar en la que se diseñan las cosas para las bases de datos relacionales. Tenemos un esquema design que establece las relaciones entre las tablas. Ahora, en la base de datos relacional, estas son las tablas, estos son los elementos centrales dentro de la base de datos que se van a utilizar para almacenar datos. Puedes pensar en una tabla casi como una hoja de cálculo o lo que sea. Va a almacenar todas las cosas que vamos a introducir y lo hace dividiendo las cosas en columnas.

Así como la tabla de origen aquí tiene un ID, una marca de tiempo, nombre, URI, detalles. Y tienen un tipo de datos, marca de tiempo, texto, etc. Luego, las tablas tienen relaciones que son de varios tipos. En una base de datos relacional, principalmente tienes una relación de uno a muchos o de muchos a muchos o tienes una relación recursiva, es decir, una tabla que vuelve a sí misma. Si miras la tabla NoteJot allí y ves en el lado más lejano esa es en realidad una línea de relación recursiva que se dibuja de vuelta a ella. Si alguna vez trabajas con datos de gráficos, bases de datos de gráficos, notarás que los datos de gráficos están orientados hacia los bordes y lados de los datos y cómo se conectan.

Así que las relaciones varían y pueden tener muchos tipos diferentes de formas en las que ocurren las relaciones más allá de solo uno a muchos y muchos a muchos, cosas así. Pero en una base de datos relacional, se centra en relacionar uno a muchos, muchos a muchos o muchos a uno, dependiendo de cómo mires la relación. Aquí, he conectado estas tablas donde el ID de origen, verás el ID de origen y las notas de origen aquí. Está conectado de vuelta al ID aquí para dibujar esa relación. Y en la herramienta que vamos a utilizar, dbDiagram, está la clave primaria, designada con un uno y un asterisco, que designa una clave extranjera, lo que haría que esta fuera una relación de uno a muchos entre esa tabla. Hay otra donde señalé directamente lo que es, así que esta nota va de uno a muchos a las notas de origen. Y lo que he creado en esta situación particular muestra una relación de muchos a muchos. Debido a esa tabla intermedia, puedo relacionar la fuente con las notas y puede haber una o muchas fuentes para cada nota o una o muchas notas por fuente. Y eso es lo que es una relación de muchos a muchos, donde puedes relacionar eso de ida y vuelta, pero no hay límite para cuántas de la cosa pueden estar relacionadas con la otra cosa. Con la relación recursiva, dibujada en la nota aquí, significa que una nota, a la que he llamado nota, puede estar relacionada con otra nota, lo que haría que lo que esté relacionado con ella sea el padre de esa nota. Y las que están relacionadas con ese padre serían los hijos de esa nota. Y en ese sentido, puedes dibujar una relación recursiva con esos datos. Y la forma más fácil que siempre he encontrado que se muestra en las computadoras todo el tiempo de una relación recursiva, solo piensa en un árbol de carpetas dentro de la estructura de directorios de tu computadora. Esa es una relación recursiva. Puedes tener tantas carpetas como quieras, tantos archivos como quieras en las carpetas, en general, y simplemente se anida en palabras a medida que avanzas. Así que esa es una relación recursiva. Y puedes simular el mismo tipo de cosa en una base de datos relacional haciendo lo mismo allí.

Muy bien, construyendo un modelo de datos. Esto es lo que voy a construir, ¿verdad? Así que algo de una base de datos mínima. Estábamos mirando solo estas tres tablas, fuente, notas de fuente y nota. Pero aquí hay una tabla principal llamada conexión, y otras tres llamadas formateador, esquema y acción. Y voy a mostrarte en dbDiagram cómo construir una estructura como esta. Y hablaremos de algunas de las partes particulares de este modelo y por qué también. Elaboraré sobre por qué elegí ciertos tipos de datos, ciertos nombres de columnas, etc., a medida que avanzamos en esto. Esto es lo que vamos a hacer. Muy bien, así que abre dbDiagram si aún no lo has hecho. Cuando vayas al sitio por primera vez, terminarás aquí y necesitarás crear una cuenta. Así que adelante y hazlo si aún no lo has hecho. Si ya lo has hecho, cuando hagas clic en Ir a la aplicación, debería dispararte justo aquí como esto. En general, viste ese esquema fantasma que mostró. Una gran manera de trabajar con dbDiagram es usar uno de los diagramas de referencia que te da. Y si te desplazas aquí a este menú desplegable y simplemente haces clic en Cargar Muestra, cargará la muestra para ti. Y te da información en el marcado en el lado izquierdo de la pantalla aquí sobre cómo dibujar todas las relaciones y construir las tablas aquí en esta herramienta. Puedes ver aquí una clave primaria con un valor de incremento automático. Están usando un var char aquí, marca de tiempo aquí. Y llegaré a más de eso en solo un minuto mientras empiezo a trabajar en esto. Y muestra algunas de las referencias. Esto aquí es una relación de muchos a muchos entre, ¿qué es? El código de país a países y luego comerciantes a países.

Entonces, los comerciantes pueden tener muchos países, los países pueden tener muchos comerciantes y sus respectivos códigos de país, etc. Y hay algunos otros puntos de referencia aquí también. Así que esta es una gran herramienta y la vamos a usar para construir nuestro esquema inicial.

Así que hagamos eso. Voy a hacer clic en el menú desplegable y hacer clic en nuevo diagrama. Y luego aquí, voy a empezar mi primera tabla así. Y simplemente la voy a llamar origen, abrir y cerrar llaves. Y luego veamos si vamos a ID UUID. Así que un UUID es un valor entero de 16 bits. Parece, usualmente se representa con guiones en él para hacerlo un poco más legible. Cada database lo tiene. Es una forma de asegurar que tu ID es único. Y a diferencia del auto incremento donde puedes tener conflictos porque irá uno, dos, tres, cuatro, cinco, y luego si más de una persona está tratando de insertar algo, puedes tener un conflicto donde de alguna manera obtienen el cinco y luego el cinco se sobrescribe, o el cinco se borra, y luego alguien más intenta agregarlo y puede haber una colisión entre esos porque no son números particularmente únicos. Alguien puede terminar con el mismo ID en esa situación. Sin embargo, un UUID, si usas un generador de UUID, que cada database tiene una función o algo que te permitirá crearlo automáticamente. Y la mayoría de las bases de código, ya sea que estés usando JavaScript o Python o lo que sea, hay algo que te permitirá crear un UUID. Así que puedes insertar sin preocuparte por el conflicto y puedes hacer referencia sin preocuparte por tener que, necesitar deduplicar por alguna razón como que alguien apague la llave alrededor del UUID que lo mantiene único. Así que en este caso, voy a empezar de inmediato, estableciendo este UUID como la clave primaria, P-K-A. Luego voy a agregar una marca de tiempo. Así que a menudo, y esto es algo muy importante para el modelado de data. Es una buena idea tener un conjunto predeterminado de columnas que básicamente se duplican en todas las tablas que te ofrecen capacidades de auditoría. Especialmente cuando se trabaja en el entorno enterprise donde las auditorías ocurren de manera semi-regular, siempre es genial tener ciertas cosas que la auditoría requerirá, como la marca de tiempo para representar cuándo se cambió por última vez la data y otra información pertinente que puede ser requerida por la auditoría. Como el usuario que hizo el último cambio. Y da un camino, un rastro en el que se puede hacer la auditoría para que sepas todas las cosas que han cambiado o alterado o manipulado la data de alguna manera a lo largo de la database. Algunas de las cosas predeterminadas que siempre agrego son la marca de tiempo y a menudo, pondré en el usuario del sistema, no particularmente el usuario de la database, sino el usuario del sistema. Porque muchas veces el sistema de la database llevará un registro del usuario que está cambiando la data de todos modos. Así que si quieres hacerlo fácil para ser consultable en las tablas mismas, quieres agregar una marca de tiempo, quieres agregar un usuario, tal vez el usuario del sistema o el usuario de la database dependiendo de cuáles sean tus requisitos. Así que en este caso, lo estoy manteniendo simple y solo voy a tener la marca de tiempo, no voy a entrar en los usuarios y todo eso. Así que para eso es. Y de nuevo, la database tiene una función que podemos usar para que marque la hora, pone la marca de tiempo en la columna. Así que no tenemos que ingresar eso manualmente o derivarlo del code o algo así. Puede ser sobrescrito, pero la database también puede hacerlo por nosotros. Creo que respondí a la pregunta del UUID, Pravin. Así que si tienes alguna otra pregunta sobre eso, no dudes en preguntar y entraré en eso más. Y también veremos un ejemplo. Así que más allá de solo hablar de esto, verás que la database genera uno cuando ingresamos algunos data en la database en breve. Muy bien, entonces lo siguiente en origen, quiero hacer nombre, así que pongo texto y luego URI. Así como el nombre de la fuente, estoy pensando en esta tabla como algo que proporciona fuentes de donde está la data o una referencia a data, donde está la data. Piénsalo como algo donde tuviste que buscar en un diccionario o en una biblioteca o algo así, pero en este caso, sabes, es internet, lo has buscado en internet y quieres el URI, así que la ubicación real del indicador de recurso universal, y quieres un nombre para poder darle un nombre amigable que nosotros los humanos podemos leer y entender qué es, y luego finalmente, voy a agregar detalles, y los detalles serán básicamente algo como solo notas que podríamos mantener sobre una fuente particular que hemos recogido por alguna razón. Como si encuentro una página impresionante sobre GraphQL y React o algo así, pondría el URI allí, agregaría un nombre amigable, y luego agregaría más detalles sobre qué es específicamente. Así que básicamente una tabla muy glorificada de marcadores.

Luego agreguemos uno para las notas de origen así, y agregaré un ID de origen. Así que ese ID de origen, la razón por la que lo nombré así, porque no es el ID de la tabla. Es el ID que hace referencia a otra tabla a la que esta tabla estará relacionada. Así que haré un UUID porque necesita ser el mismo que la tabla a la que hace referencia, y luego voy a agregar una referencia. En dbDiagram, eso es ref colon chevron, el nombre de la tabla a la que está relacionado,.id, la columna a la que está relacionado. Así que eso es, y los detalles del texto, y luego sello, voy a tener marca de tiempo para esta tabla también Hubo una pregunta de Nebertec, ¿qué es más rápido, UUID o auto incremento? Si estás hablando de un gran volumen de data siendo insertado, vas a ganar con los UID's, UUID's, y te diré una razón. Si tienes un solo sistema, solo un sistema, con solo ese rendimiento de sistemas escribiendo inserciones en una database con auto incrementos, puede ser bastante rápido, y los auto incrementos pueden ser rápidos en todo sentido de realidad. Sin embargo, a menudo si tienes muchas inserciones, también tienes muchos clientes tratando de hacer las inserciones.

Se van a poner muy lentos con los auto incrementos porque van a tener colisiones, y van a surgir otros conflictos a medida que trabajas con estas inserciones. Si también tienes actualizaciones y eliminaciones, aún más conflictos. Los UUIDs no van a tener los conflictos. Si estás realmente preocupado por las inserciones, sin embargo, no hagas que la database llame a ninguna función para crear UUIDs o hacer auto incrementos y crea el identificador único puramente en el lado del cliente. Haz que el cliente haga ese trabajo. Sin embargo, de nuevo, eso puede ser complicado en su naturaleza porque estás, de nuevo, tomando algo que va a ser una referencia específica de la database, el UUID, y las relaciones de clave primaria y clave externa. Y estás poniendo la responsabilidad en el cliente, que no es la database. No sabe por qué estaría creando esto. Eliminas muchos de los conflictos y problemas a nivel de la database, pero también eliminas algunas de las responsabilidades de la base de datos. Me gusta que la database use una función de la database para crear un UUID, pero a veces necesitas que el código del cliente o el cliente, lo que sea que esté creando estos data, necesitas que realmente cree el UUID. Pero en cuanto al performance, la forma más rápida es no hacer que la database lo haga. Si tienes un solo cliente escribiendo data, el auto incremento es bastante rápido. Si tienes varios clientes escribiendo los data, necesitas pasar a los UUIDs independientemente del performance. Lo otro que agregaría es la diferencia entre una función UUID y una función de auto incremento en casi todas las database relacionales es tan insignificante que no debería afectar tus inserciones. Lo otro a tener en cuenta son las inserciones por lotes, si realmente tienes grandes volúmenes de data para insertar en la database. Así que esas son algunas de las cosas a tener en cuenta allí. Desafortunadamente, la respuesta no es sencilla, depende de cómo vayas a escribir esos data en la database.

Muy bien. Así que aquí está la fuente y los nodos fuente, y ahora voy a conseguir la cosa del tomador de notas. Vamos a añadir nota jot así. Y de nuevo, tendremos un ID ahí, UUID, y lo haremos la clave primaria, ¿de acuerdo? Y luego añadiremos un sello de nuevo. Lo haremos sello de tiempo y añadiremos el ID de la nota. Y esto es esa oreja de elefante, esa relación recursiva de vuelta a, la propia tabla, ¿verdad? Nota jot dot ID. Y lo ves aparecer en el diagrama a la derecha. Una característica realmente genial de esto es que lo dibuja a medida que haces esto. Déjame añadir detalles. Y luego volvamos a las notas fuente, y lo relacionaremos. Pongamos ID de nota, referencia UID, nota jot dot ID, oops ID. Así que ahora, movamos esto alrededor para que podamos verlo mejor. Puedes ver que tenemos esa relación mini a mini y esa recursiva aquí, ¿verdad? Así que esa fue la primera parte del esquema que miramos cuando discutí los detalles específicos. Bueno, los detalles para la nota serían como el cuerpo de la nota en sí. Como si quisieras tener una recursiva, amplia gama de notas alrededor de una fuente particular, ¿verdad? Y en la fuente, los detalles son específicos sólo para la cosa correlativa que se guarda en esa tabla, en este caso sólo el URI. Y también, es sólo un ejemplo. Probablemente no tendría detalles en ambos a menos que hubiera una razón muy específica para tenerlos estrechamente acoplados a cada una de esas entidades de esa manera. Pero en este caso, parecía una cosa fácil de añadir que podría ser de utilidad a medida que se va desarrollando. Como cuando alguien empieza a hacer desarrollo de aplicaciones contra él, podrían prospectivamente usar los detalles en ambos de esos relacionados específicamente a la nota o a la fuente, ¿verdad? Muy bien, así que lo siguiente, quiero crear la conexión. Y veamos, haremos ID, UID, haremos eso clave primaria. Luego vamos a tener un sello de nuevo. Otro sello de tiempo, porque, de nuevo, con los sellos de tiempo, es para cualquier actualización o cambio en los data en absoluto, ¿verdad? Sello, y luego veamos, aquí queremos, vamos a hacer dos otras cosas. Así que la conexión, sólo para describir lo que estoy pensando con la conexión, son estas cosas aquí, estas tres tablas, cambiaremos su color. Cambiémoslas a este color. Puedes ver en el marcado, lo cambian aquí como esto, el color de la cabeza. Sólo para que podamos ver estas diferenciadas de lo que estoy a punto de hacer. Así que esto es sólo puramente la fuente y las notas sobre la fuente que se recogen. Con la conexión, voy a conectar las fuentes a acciones particulares. Así que la idea es, si la fuente es digamos, no sólo una página web, sino una ubicación de FTP, como una ubicación de transferencia de archivos, o alguna otra ubicación de API REST o una ubicación de GraphQL, podría configurar acciones, ¿verdad? Y otras cosas, como digamos, decirle qué tipo de formato es. ¿Es XML o JSON o algo así? ¿O hay un esquema para los data contra los que podría cometer una acción y bajar de esa fuente particular? Así que con la conexión, añadiré un sello. Y luego va a haber una acción, un formato y un esquema. Así que añadamos las tablas para eso. Y luego volveremos y añadiremos el ID. Así que volveremos y añadiremos los ID a esto. Primero, veamos, oops, tabla, esquema. Y de nuevo, ID, igual que en todas partes. Iremos PK. Y luego iremos tabla formato, formateador. Sólo voy a copiar esto, lo pondré ahí ya que es lo mismo en todos. Y luego tabla, ¿qué más dije? Oh sí, acción. Quiero hacer una acción. Así, está bien. Así que están ahí. Y ahora podemos relacionar estos de vuelta aquí con... Veamos, para la conexión queremos hacer... ¿Cómo quiero hacer esto? Creo que lo que haremos es que haremos un ID de acción y luego haremos un ID de fuente. Vamos, ID, necesitaremos eso. Oh, cambiar el color es una característica pro. Debo haber sido, ¿cuál es el término? Incluido en el paquete o algo así. No, yo no, no estoy pagando.

Sí, tengo el botón de actualización. Así que no lo sé. Debo haberme metido allí de alguna manera. Lo siento por eso. Leyendo las preguntas rápidamente. Dame solo un segundo. Nicks, esto es cierto, sin embargo, puedes deducir que 41 probablemente existe, pero como dijiste, énfasis en que probablemente existe, pero puede que no. Puede que ni siquiera haya existido nunca. Esto es algo que no sabemos porque la database puede haber matado eso y saltado al siguiente incremento. Así que aunque parece algo bueno para un rastro de auditoría, no es muy fiable.

No es muy fiable, y no estoy diciendo que UUID solucione esto según tu referencia allí, pero en una auditoría, uno definitivamente necesita tener eso en cuenta desde la perspectiva de la auditoría. Que solo porque hay un auto incremento no significa que siempre haya la siguiente sucesión de números en orden. La database podría haber saltado cosas por varias razones, podría haber habido conflictos y las saltó, y nunca se ingresó eso, un montón de cosas. Un administrador de database podría haber entrado y dicho que salte un montón de cosas, comienza a incrementar desde 4,000 cuando solo llegó hasta como 399 o algo así. Así que desde la perspectiva de la auditoría, uno definitivamente necesita tener en cuenta que no hay realmente un vaivén suave, como no hay una lista vinculada del flujo de data. La mejor manera de obtener un flujo de data es que vas a tener que tener una marca de tiempo, vas a tener que tener data adicional e información y registros sobre la tabla y los data en la tabla. Pero eso es un buen punto a destacar, buena llamada allí. Muy bien, entonces veamos, puse eso aquí, aquí y aquí y luego metamos esto. Así que esto es ref, esto puede ser action.id. Y esto va a ser ref. Source.id. Ahora como puedes ver, mi nombramiento generalmente sigue un enfoque con IDs donde puedo determinar fácilmente cuál es la relación sin mirar la relación física dibujada en la database. Puedo mirar el nombre y saber que action.id apunta a la tabla de acción. Puedo mirar source.id y saber que apunta a la tabla de origen. El único que es un poco raro es note jot. La razón por la que lo llamé note jot es porque uno podría anotar una nota, que es una forma coloquial de decirlo, pero note sin embargo es a menudo en la mayoría de las bases de datos una palabra reservada, he encontrado. Así que realmente no puedes llamar algo una nota como el nombre de la tabla, al menos en algunas bases de datos. No sé acerca de todas ellas. En ese caso llamo a la tabla note jot para eliminar ese conflicto, pero rutinariamente me refiero a esa tabla cuando estoy llamando a una relación solo como note dot algo. Porque en el fondo, solo está destinado a almacenar notas que alguien escribiría sobre un URI particular. Muy bien, así que tenemos estos en allí, esquema, veamos aquí, ¿qué más queremos allí? Queremos, básicamente haremos el estándar marca de tiempo muy rápido. Woops, marca de tiempo. Y luego tendremos el ID de conexión, queremos relacionarlo con eso. Así. Y luego, hagamos un mapa de formateador. Y luego, porque esto va a ser respaldado por Postgres, haremos JSON como el tipo de data. Así que eso es solo un final abierto, va a describir el formato o el esquema quiero decir de cualquier manera que necesite para que podamos saber cuál es el esquema de los data subyacentes que están en el URI o que serían extraídos del URI. Muy bien, ¿qué no le gusta de mi cosa aquí? Nada como errores mientras estás haciendo cosas en vivo. Solo suéltalo por un segundo. Y luego conexión. ID de conexión. Oh, sé lo que hice. No establecí el tipo derp. Ahí vamos, está bien, todo arreglado. Y luego para Formatter, iremos con sello de nuevo. Y luego creo que necesitaremos el ID de conexión allí también. Así que solo copiaré eso y luego haremos Formatter. Haremos un mapa de eso también, básicamente hacerlo un mapa JSON. Veamos aquí, y luego acción. Añadir Sello.

¿Necesitamos el ID de acción? No, porque pueden tener lugar múltiples acciones en una conexión. Entonces, según la relación en la conexión, será una relación uno a muchos con la acción. Eso debería darnos lo que necesitamos allí. Realizar una acción. Oh sí, necesito declarar algo para ser la acción. Así que lo haremos JSON también. Entonces podemos definir acciones y realmente extender y elaborar sobre lo que sería. Porque realmente no sé cómo sería el sistema del cliente aquí. Esto es solo, de nuevo, una idea de cómo construir un modelo para un sistema que prospectivamente haría todas estas cosas. Así que allá vamos. Tenemos, tenemos ese modelo de data que había mostrado previamente en las diapositivas. Así es como lo construirías. Ahora, lo siguiente importante es para todos ustedes construir un modelo ustedes mismos que luego usaremos momentáneamente cuando lo pongamos en marcha en el producto Hasura. Así que todos tomen 10 minutos, tomen un descanso biológico, tomen una bebida rápidamente, y también comiencen a si aún no lo han hecho comiencen a construir un modelo de data que tenga al menos alguna clave primaria, clave externa y algunas relaciones de muchos a muchos como hemos hecho aquí. Podrías, si quieres básicamente solo usar esto y lo haré súper fácil. Veamos aquí, lo pegaré en el discord. Boom, ahí está. Así que si quieres agarrar eso del discord puedes tener este exacto modelo de data o puedes construir lo que quieras. Así que toma 10 minutos, actualmente son las 9.38. Volveremos a las 9.48 y comenzaremos la segunda parte. También en este interludio, si tienes más preguntas o pensamientos sobre esto o preguntas sobre cómo modelar estas cosas por favor haz esas preguntas y cubriré cualquier cosa que surja cuando regrese. Así que volveré exactamente en 10 minutos a las 9.48 o 48 después de la hora donde sea que estés, en cualquier zona horaria en la que te encuentres. Bueno, nos vemos en un rato. Bueno, espero que todos hayan podido tomar una bebida, tomar un descanso, etc. Algunas preguntas que voy a repasar verbalmente ahora mismo. Nick preguntó, ¿por qué estaba usando PascalCase? ¿Fue solo una elección personal o alguna razón específica? En Discord también publiqué una entrada de blog donde hablé un poco más sobre eso, especialmente en el caso de las convenciones de nomenclatura de database y demás. En las bases de datos, sugeriría firmemente siempre seguir con Camel o PascalCase. No siempre importa con cuál te vayas. Sin embargo, personalmente tiendo a seguir con la nomenclatura de caso que se usa en la pila de tecnología. Entonces, si es .NET, a menudo uso PascalCase porque mucho del code .NET generalmente tiende a seguir la convención de ser PascalCase. Con Java, por ejemplo, a menudo cambiaré a CamelCase para que entonces la database, las tablas, las entidades que podrían generarse a través de GraphQL o lo que sea generalmente tienden a ser en minúsculas. Sin embargo, los programadores que están escribiendo code contra estas tablas y estas entidades y otras cosas que se crearán a partir de la database, estarán usando el mismo caso que ya usan en su base de code. Así que entonces parecerá lo que sea para ellos, sus objetos o sus entidades o sus tuplas o elementos o lo que sea fomenta la familiaridad desde esa perspectiva. Oh, interesante. Usas, Nivertec menciona que usan herramientas de diagramación ERD CLI y extensiones de VS Code, pero no genera SQL DDL. Eso parece extraño. Revisaría las herramientas de JetBrains, revisaría varias otras herramientas porque muchas, muchas, muchas herramientas de diagramación ERD que he visto casi siempre tienen especificaciones DDL que exportarán. Así que definitivamente revisaría algunas herramientas nuevas aquí. Tiene que haber algo en algún lugar. Hubo otra pregunta también de Melody Burger. Dice, ¿cómo generalmente comparto, comunico e itero en el modelo de data con el equipo? Así que la herramienta de diagrama DB, que veremos en un segundo realmente hace la exportación del DL. Te da un SQL, te dará imágenes y luego puedes poner eso en el repositorio. También en la herramienta misma, puedes compartir estos diagramas como el diagrama mismo, en el diagrama DB al equipo a través de un enlace. Y luego pueden incluso ir, si les das permisos, pueden ir y pueden editarlo o agregarle cuando necesiten. Muchas de las otras herramientas que uso tienden a tener este tipo de capacidad. Así que puedes al menos poner una imagen en el repositorio o poner el SQL en el repositorio. Quiero decir, necesitas el SQL en algún momento de todos modos, especialmente cuando estás construyendo ese diseño inicial y necesitas meterlo en la database. Si no tienes eso, entonces necesitas recrear a mano todas las tablas y todo en la database. Eso es bastante frustrante. Eso sería mucho trabajo redundante.

Entonces, en este punto con db diagram, obtendremos el SQL y luego, lo exportaremos a la herramienta que vamos a usar, que es el servidor API GraphQL de Hastur. Con eso, vamos a empezar. Entonces, tenemos nuestro esquema de database. Vamos a ponerlo en marcha y realmente a construirlo, ejecutando algo de SQL. Vamos a ver algunas consultas GraphQL alrededor de eso. Vamos a revisar algunas de las consultas y los planes de ejecución de esas consultas, poner algunos data en la database, cosas así. Discutiremos más a fondo el modelo de data y cómo se aplicaría o no al GraphQL. Y también, asegúrate de preguntarme si tienes alguna pregunta sobre NoSQL, porque voy a dejar eso un poco abierto. Pero una de las cosas que voy a abordar un poco hacia el final aquí es cómo lidiarás con lo que obtienes de una database distribuida desde una perspectiva de GraphQL porque puede depender de la database distribuida, puede depender de la database de gráficos o lo que sea. Y realmente tienes que hacer mucho del trabajo pesado para el GraphQL tú mismo para determinar las relaciones o los gráficos de vuelta a las cosas, como en el caso de Apache Cassandra, no hay relaciones. También no hay uniones en esa database, mucho más escalable por muchas razones porque es distribuida, escalable horizontalmente, etc. Pero luego en el GraphQL, para obtener el valor y el poder de poder relacionar las entidades y tal, necesitarás hacer esas conexiones en cualquier servidor que estés usando para tu GraphQL. Así que un poco complicado. Con Hasura y una database relacional, sin embargo, puedes dibujar esas, lo que lo hace muy, muy poderoso en ese sentido. Así que antes de hacer cualquier otra cosa, si no tienes una cuenta de Hasura y el backend de database requerido a través de Heroku, ve a registrarte ahora mismo para obtener una cuenta en Hasura y Heroku. Con Heroku, todo lo que necesitas hacer es crear ese inicio de sesión y luego en Hasura, podrás hacer una authentication contra eso para obtener la database. Muy fácil en ese sentido. Solo como un clic de un botón. Así que si no tienes eso, comienza a registrarte para esos ahora mismo. Voy a continuar solo un poco y volveremos a eso. Así es como se ve la interfaz cloud en la solución de Hasura. Haremos clic en nuevo proyecto, lo que nos creará un nuevo proyecto que se verá exactamente así. Y luego usaremos el nivel gratuito. De nuevo, Heroku y Hasura combinados te dan una database gratuita y una API GraphQL gratuita. Y en ella, solo ingresas el nombre del proyecto, la región, y luego pasas por, hay un botón para hacer clic. Creará la database de Heroku para ti siempre y cuando tengas esa cuenta autenticada, que el botón hará eso. Iniciará ese proceso y te permitirá terminarlo fácilmente haciendo clic en algunos botones. Luego haces clic en crear proyecto y genera un proyecto que se verá exactamente así. Y luego haremos clic en lanzar console y eso es en lo que estaremos trabajando durante la mayor parte del resto de esta masterclass. Y de nuevo, esto es lo que construí y prospectivamente tú construiste, o puedes obtener el code de, el code del diagrama DB en el chat de Discord. En DB diagram, justo en la exportación, puedes exportar un PDF a Postgres, o un servidor SQL MySQL o a PNG. Por supuesto, PNG es un formato de imagen. Así que obtendrás una imagen solo del diagrama, creo que eso es lo que es. Y Postgres, MySQL y SQL Server te darán SQL que es específico para esa database relacional que puedes ejecutar contra esa database en particular. En nuestra situación particular, estaremos usando Postgres porque Hasura trabaja principalmente contra Postgres en este momento. Y ni siquiera necesitamos lidiar con el PDF. No necesitamos un PDF de nada de esto, pero está ahí si lo necesitas. Y no sé si puedes sin una cuenta pagada o cualquier cuenta con la que estoy protegido ya que he podido guardar el diagrama. Así que eso es otra cosa que puedes hacer. Puedes guardarlo y puedes compartirlo y te dará a las personas el enlace que apuntará de nuevo al diagrama que acabas de crear. En Hasura cuando iniciamos sesión, y no te preocupes, navegaré a través de esto. Solo te estoy mostrando una rápida visión general de lo que estamos a punto de hacer. Entraremos y pegaremos el code SQL que obtenemos en la pestaña data en la sección SQL de la pestaña data es un lugar donde podemos publicar, vaya, SQL en bruto y luego ejecutar ese SQL en bruto. Un poco más sobre eso en solo un segundo. Haremos eso y una vez para la database, podremos dibujar conexiones, mirar las relaciones, mirar las entidades y ejecutar consultas GraphQL contra ella y hacer todo tipo de lo que necesitemos hacer en ese punto. También echaremos un vistazo al análisis de consultas. A medida que ejecutamos algunas consultas GraphQL, podremos ver esas y mirar el SQL que en realidad está siendo ejecutado por el servidor GraphQL. Esto es muy importante ya que con cualquier esquema de data, diagrama de data, quieres saber cómo el servidor está ejecutando realmente el SQL, cómo está ejecutando la consulta, lo que sea que sea. En este caso particular, es solo una consulta básica contra algo que he ejecutado. Debajo del SQL generado, ves el plan de ejecución porque incluso si tienes la declaración SQL, no sabes particularmente cómo un servidor de database ejecutará algo a menos que mires el plan de ejecución.

El plan de ejecución te muestra el tiempo y otras características alrededor de eso. Postgres lo tiene, Oracle lo tiene, SQL server lo tiene. Cada base de datos relacional tiene alguna forma de ver el plan de ejecución. Entonces, Hasura proporciona esa capacidad para ver qué declaración SQL ha creado y proporciona el plan de ejecución justo debajo de eso. Así que lo veremos, hablaremos de eso un poco más.

Bien, a la acción. Entonces, si volvemos aquí a exportar, Postgres. Y, incluso si no has hecho ninguno de los pasos hasta ahora, tengo un truco fácil para ti. Te pondrá justo donde estamos. Voy a copiar todo este SQL en el chat de Discord. Entonces, en dos segundos, uno, dos, boom. Todo está ahora en el chat de Discord. Entonces, incluso si no hiciste nada de eso, aún puedes seguir desde este punto si te gustaría.

Ahora si, solo quiero cubrir algunos detalles, pequeño detalle pedante alrededor de la base de datos relacional. Especialmente si quieres hablar en gran detalle pedante sobre una base de datos. Estas son tablas, como mencioné. Estas cosas en las tablas son columnas. Los datos que se almacenan en esas columnas dentro de una tabla se refieren en realidad como una tupla. Es una sola fila de una tabla. Dentro de eso, es esa sola fila de datos. Cada fila individual se considera una tupla. Ahora en lenguaje de programador, eso podría ser un poco confuso porque en algunos, una tupla puede ser una cosa con dos o tres valores o lo que sea. Depende un poco, varía un poco en los lenguajes de programación, pero en las bases de datos, las bases de datos relacionales, una tupla es la fila. El esquema de relación es el esquema con todas estas relaciones aquí. Un esquema podría ser solo tablas sin la relación. Entonces a veces escuchas muy específicamente declarado esquema de relación versus solo esquema. Un grado es el número total de atributos. Entonces los valores individuales dentro de una fila, atributos, eso es lo que es un atributo, que en relación se llama el grado de la relación. Entonces como referencias, ves esas, esos son tus grados dentro de tus atributos, etc. La cardinalidad, esa es una palabra que surge bastante a menudo con las bases de datos relacionales. La cardinalidad es el número total de filas presentes en la tabla, ¿vale? Entonces una alta cardinalidad proporcionaría muchos datos sobre varias cosas. Una columna, que he mencionado, son estas. Veamos qué más. Asegurándome de que no me he perdido nada. He pasado por una pequeña lista de verificación en mi cabeza aquí. La clave de relación, a veces las cosas se refieren específicamente como esta es la clave de relación, ¿vale? Y la clave primaria o la clave foránea, esta otra cosa a la que está relacionada, se refieren generalmente como una clave, ¿vale? Ahora desde una perspectiva de rendimiento, estas reciben un índice. Cuando haces algo una clave primaria o clave foránea, reciben un tipo de índice. Puedes agregar índices al nivel de la base de datos a otras columnas. No voy a entrar en eso, pero es algo que es muy importante saber, especialmente en las bases de datos relacionales, porque los índices pueden mejorar dramáticamente el rendimiento de las exploraciones, que a su vez, como vemos en estas consultas, verás en los planes de ejecución lo que están haciendo las exploraciones. Entonces si ves algo que toma mucho tiempo en una columna en particular, como si dijeras algo basado en esto, puedes mejorar ese rendimiento a menudo asegurándote de que una columna en particular contra la que estás haciendo esa exploración está indexada. Sí, Nevertech señala, también hay una cardinalidad de los valores distintos en una columna específica. Cardinalidad es una de esas palabras que puede significar una cosa o muchas cosas dependiendo del contexto específico en el que estás hablando, y se usa bastante a menudo. Lo verás en los artículos de periódicos, lo verás en los artículos de bases de datos, etc. Así que es importante tener en cuenta lo que significa específicamente en un sentido general, y luego específicamente a lo que se aplica en el contexto particular para lo que se usa. Eso es lo mismo con la tupla. Y lo menciono porque, a medida que pasas de la pila de tecnología de desarrollo en JavaScript o C sharp o Java o Python o cualquier lenguaje que puedas estar usando a la base de datos, y luego de nuevo, puedes ver estas palabras similares, que tienen significados ya sea muy distintivamente diferentes o solo ligeras variaciones en el significado, ayuda a conocer la diferencia para que sepas cuál es el contexto de ella con la pila de tecnología en particular o la base de datos. Bien, creo que eso cubre la base de solo algunos de esos detalles pedantes allí. Bien, entonces tenemos el SQL y espero que hayas creado tu cuenta de Historia y tu cuenta de Heroku, y voy a seguir adelante y crearemos un nuevo proyecto, y lo llamaré el Proyecto de la Masterclass Increíble. Solo voy a hacer clic en Free Tier, y voy a, seleccionar la región. La región gratuita es Ohio.

Hay muchas otras regiones dependiendo de dónde te encuentres que podrías querer usar, pero yo solo voy a usar la versión gratuita porque así todos podemos usarla y podemos hacer exactamente lo mismo y hacer que funcione. He puesto un nombre demasiado largo. Debería saberlo mejor que eso. Llamémoslo simplemente la Increíble Masterclass. Ahí vamos, está bien. Entonces vamos a la Configuración de la Base de Datos. Voy a hacer clic en Probar con Heroku. Voy a hacer clic en el botón de Heroku. Aquí, si aún no lo has hecho, es donde comenzaría la autenticación. Harías clic en Aceptar, etc. y luego te redirigiría y luego crearía la aplicación de Heroku, instalaría Postgres, obtendría la URL de la base de datos, la pondría aquí. Y entonces, oh, nota rápida. Puedes tomar esto, este enlace de la base de datos, y puedes usarlo en un conector de Postgres en cualquier herramienta que puedas estar usando con Postgres si estás haciendo eso. Entonces, es útil saber que eso es lo que es. Hago clic en Crear Proyecto. ¿Acabo de borrar algo? Bueno, voy a refrescar rápidamente. Puedo hacer eso de nuevo. Ahí vamos. No sé, creo que cuando resalté eso, podría haber estropeado el enlace. Pero de todos modos, aquí estamos. Mientras estamos en esto, solo un poco de contexto mientras está generando el servidor. Es útil saber dónde están las variables de entorno. Si haces esto, una de las primeras cosas que a menudo quieres hacer es eliminar la consola de la vista en vivo, porque literalmente cualquiera, como todos ahora mismo, podría ir a la consola de cada uno si estás creando esto, porque inicialmente se crea completamente abierta. Pero lo que haces es simplemente añadir una nueva variable de entorno y bajas. Y bueno, voy a escribirlo, porque lo hará más rápido. Habilitar consola, y querrías poner eso en falso. Voy a dejarlo habilitado por ahora, solo para que tengamos algo con lo que trabajar aquí. Ahora parece que estamos listos, todo bien. Y lanzar consola. Ahí vamos. Así que ahora mismo, es un GraphQL. No tenemos nada aquí. Si haces clic en los datos, irá y mostrará que solo tenemos estos dos esquemas en nuestra base de datos. El Catálogo HTTP Pro no está relacionado. No tienes que lidiar con eso en absoluto. Public es simplemente nuestro esquema público general que tenemos. Y por supuesto, no hay nada aquí porque no hemos creado nada aquí. Es una base de datos vacía con un servidor API GraphQL respectivamente vacío. Pero haz clic en SQL y cambiará todo eso. Así que literalmente voy a copiar, así que si me equivoqué en mi copia y pega anterior en Discord, yo también lo conseguiré. Voy a copiar ese SQL de ahí y lo voy a pegar aquí. Ahí vamos. Así que como puedes ver, hace un bonito código de colores para nosotros. Tenemos todas nuestras notas y todo en nuestros tipos, etc. Así que deberíamos estar listos. Otra cosa, puedes desmarcar o marcar esto, haz clic en seguir esto para que inicialmente siga todas estas tablas y empiece a añadir los metadatos necesarios en el servidor, para que sepa qué tipos de consultas y capacidades GraphQL y otras conexiones que queremos. Así que voy a hacer clic en ejecutar y en unos segundos, tendremos una base de datos. Vale. SQL ejecutado y notarás a la izquierda aquí acción conexión notas formateadas, esquema de trabajo, las notas de origen acaban de aparecer a medida que se creaban. Ahora haz clic en los datos una vez más y dejará la pantalla de SQL y simplemente irá a la pantalla de datos general que sueles ver cuando te conectas.

Ahora hay algunas relaciones de clave extranjera que no se están rastreando actualmente. Así que rastreó las tablas pero no rastreó las relaciones de clave extranjera, eso es algo que vamos a querer hacer. Pero antes de hacer eso, echemos un vistazo a la relación para ver qué obtenemos aquí. Acción, por ejemplo, si hago clic en acción y luego voy aquí a relación, verás que la relación no se ha agregado actualmente. Así que no hagas clic en nada todavía, volveremos a eso. Lo otro que puedes hacer es como, digamos fuente, ve a fuente, tenemos insertar fila, modificar. Esto modifica la tabla en sí. Tenemos, de nuevo, las relaciones y las dos conexiones que cree que podríamos querer inferir para que las entidades de GraphQL sepan que están conectadas de esa manera, ¿verdad? La database sabe porque dibujamos las conexiones de la database en las relaciones de la Forma Clave primaria en el SQL. Pero el servidor de servicio no ha hecho esa conexión en sus metadatos para conectar fuertemente esos todavía porque nos ha dado la opción de hacerlo. Pero ve en la database que esos están obviamente allí porque son conexiones reales dentro de la database en sí. Así que volvamos a hacer clic en data y luego haga clic en rastrear todo. Eso va a agregar todas esas relaciones. Debería tomar solo un segundo o dos aquí. ¿Cómo es el tamaño de la fuente, por cierto, todos? ¿Está bien el tamaño de la fuente? ¿Debería aumentar el tamaño de la fuente? Cualquier otra queja de ese tipo, avísame. Veré si puedo ajustarlo hacia arriba o hacia abajo o algo así. Porque sé que algunas de estas fuentes se vuelven un poco pequeñas en el tamaño de pantalla de 1080p. Muy bien, entonces se agregaron las relaciones, así que, vamos a tener un poco de un elemento transicional así que, se agregaron las relaciones. Ahora, si vamos a, digamos, acción, ve a relaciones, ves ahora que es una relación real, ya no hay un botón de agregar, solo hay un editar, así que haces clic en eso y podrías cambiar la relación si quisieras, pero no necesitas hacer eso. Sin embargo, hay algunas otras cosas que queremos hacer en esta database que no se hizo antes.

Bien. Este es un punto en el que si estuviera haciendo esto desde una perspectiva de equipo, desde una perspectiva de flujo de trabajo, con el intento de meter todo en el repositorio, como mencionó Melanie anteriormente, ¿cómo compartes todo esto con un equipo? En este punto, este sería el primer punto donde inmediatamente configuraría las migraciones para automatizar la creación o cambios de la base de datos. Sin embargo, no voy a hacer eso hoy porque estamos enfocados en un tema diferente, pero es muy importante que eso se inicie lo antes posible para que puedas tener un flujo limpio de migraciones desde tus migraciones de la versión uno a tu base de datos de la versión dos, y pueden mantenerse sincronizadas con tu desarrollo de software o tus redactores de informes o quien sea que esté usando tu base de datos y ejecutando consultas GraphQL, etc., contra la base de datos. Como, quieres mantener eso sincronizado con ellos para que siempre puedas darles la especificación de la versión y ellos sepan exactamente lo que están obteniendo en la base de datos. Entonces. Si miramos las relaciones, eso está bien, pero lo otro es, vamos a modificar, veremos que esto es UUID, clave primaria, y es único. Eso es lo que queremos, pero queremos cambiar el valor predeterminado al UUID aleatorio para que la base de datos cree el UUID para nosotros. Ahora, hacer esto en Postgres, así como en muchas otras bases de datos, obtienes el UUID, la base de datos lo genera para ti. Sin embargo, eso no te impide en el lado del cliente, si necesitas, crear un UUID. Y esto es algo muy interesante que puedes hacer con UUID que no puedes hacer con incrementos automáticos, y es muy importante, especialmente si tienes un sistema con muchos usuarios leyendo y escribiendo datos y cosas que van a tener relaciones entre los datos primarios creados y los datos de clave extranjera creados que pueden necesitar ser escritos en varias tablas. Pero no quieres hacer muchos viajes a la base de datos porque quieres acelerar el rendimiento del sitio web. Entonces la forma de hacer eso es tener el sitio web que crea ese valor de clave primaria inicial. En este caso, digamos fuente, de acuerdo. Pero tan pronto como crean eso, está configurado, está listo para ser guardado. Pero el usuario también quiere hacer algunas otras cosas como crear la acción, el formateador u otra información como las notas alrededor de la fuente en el momento de la creación de la fuente en sí. Si ese es el caso y todavía están creando esos datos. Como si tuvieras todas estas cosas en un formulario donde pueden crear estas cosas. Puedes querer que creen más de esa información y luego escriban todo a la vez en la base de datos. La única forma de hacer eso es usar UUIDs. Y luego cuando dibujas la relación de clave primaria y extranjera en el cliente, a medida que crean esos datos, has creado ese UUID para poder pasar a la base de datos para que la base de datos correctamente dibuje estas correlaciones entre estos datos que se crean en el lado del cliente. Puedes empujar todo a la vez. Entonces tienes básicamente una inserción por lotes contra una multitud de tablas y los UUIDs te permiten hacer eso, mientras que los incrementos automáticos no te permitirían hacer eso porque puedes tener conflictos a medida que varios usuarios intentan escribir cosas en la base de datos. Y necesitaría un viaje de ida y vuelta cada vez. Escribirías la inserción y tendrías que pedir ese ID implementado automáticamente de vuelta y luego tomar eso para los datos relacionados con la clave extranjera y usarlo para eso a medida que haces esas cosas y luego enviar esos datos. Así que hay todo ese viaje de ida y vuelta que se requiere en esas situaciones, mientras que con UUIDs no es necesario. Esto también es muy, muy importante con GraphQL porque si tomas una entidad compleja y tienes los elementos relacionados dentro de esa entidad de entidades y tratas de escribir todo eso de vuelta, puedes tener solo las cosas pertinentes que necesitas. Pero necesitas, quieres minimizar los viajes a la base de datos y los bucles de ida y vuelta que ocurren. Entonces en GraphQL ocultaremos eso, pero como administrador de la base de datos, la persona que está gestionando la base de datos, querrías asegurarte de que no está haciendo más viajes de ida y vuelta de los necesarios. Y eso se soluciona usando UUIDs como tu clave primaria, relaciones de clave extranjera a lo largo de tu modelo de datos. Entonces voy a guardar eso con el generador allí. De esa manera no siempre tengo que obtener eso desde el lado del cliente si no quiero. Y luego para el sello, voy a tomar el valor predeterminado y voy a ir con ahora. Observa cómo Hasura te dio el autocompletado, pero te lo dio basado en el tipo de datos. Muy, muy genial. Eso es parcialmente, ya sabes, es del tipo de datos. El nombre lo saca de eso. Ayuda mucho cuando estás tratando de pasar por y hacer algunos cambios rápidos para obtener los autocompletados que son específicos para lo que estás tratando de hacer. Entonces, bien, tenemos el ID y el sello allí. Así que clock underscore timestamp. Creo que eso depende del tipo de base de datos. Ahora, así que en realidad no sé la diferencia específica entre eso. Elabora si sabes, Bravan. Solo uso ahora porque eso también... Tiende a ser la función predeterminada entre otras bases de datos también, lo cual me gusta. Los upserts son interesantes. Y dependiendo de la base de datos, se comportan de manera diferente. Porque esta es definitivamente una buena pregunta de NoSQL. En tu consulta, ¿cómo la almacenas? En tus documentos XAML, ¿tienes una variable que define un nuevo elemento en cada bucle? Entonces, ¿almacenas un solo elemento que no está destinado a ser llevado a la siguiente consulta? Como, en Apache Cassandra, los upserts pueden ser, pueden ser peligrosos. Porque puedes tener un ID, que es tu clave primaria. Y puede ser de varias columnas, porque una clave primaria puede tener varias columnas.

Se llama a, digamos, una columna de candidatura. Entonces, si tienes eso, y una columna es un UUID, una columna es un nombre, y una columna es una dirección de correo electrónico, y luego intentas insertar un nuevo registro con el mismo nombre y dirección de correo electrónico, porque solo quieres actualizar el nombre y la dirección de correo electrónico, si estás usando UUID, terminas con un duplicado. Porque el UUID se generaría de manera diferente. Y sería un valor diferente. Entonces, incluso si el nombre y la dirección de correo electrónico son los mismos, crearía una nueva fila en la database. Ese es uno de los problemas con los upserts. Y los upserts no son una cosa funcional que ocurre. Todavía solo está ocurriendo una inserción, pero se le llama upsert porque tienes que mapear específicamente cuál es tu ID en el upsert para asegurarte de que la actualización que esperas está ocurriendo realmente. También es probablemente bueno mencionar que las actualizaciones son una especie de connotación mítica dentro de las bases de datos, porque lo que realmente está sucediendo es una operación de eliminar-insertar en el lado de la database, cada vez que haces una actualización. Cuando haces una actualización, ocurren esas dos cosas. Así que ten en cuenta que estás haciendo dos acciones cada vez que haces una actualización en una database.

Oh, ¿qué más hay que mencionar sobre eso? Hay mucho. Hay mucho en qué pensar en un diseño y desarrollo de database. Entonces sí. Volviendo a la database específicamente aquí alrededor de estas tablas. En acciones, he actualizado eso. Voy a actualizar la fuente porque voy a jugar un poco con la fuente para mostrar algunas cosas. Así que vamos a obtener esto y agregar el UID allí. Y añadiremos el sello. Bien, ahí vamos. Y luego vamos a hacerlo para... Las notas de la fuente no lo necesitan porque en cada situación siempre estarías tomando el ID de la fuente y el ID de la nota para dibujar esta relación mientras haces la inserción en las notas de la fuente, por lo que no es necesaria ninguna función allí. Sin embargo, en el sello quieres hacer ahora también. Excelente, ahora puedes hacerlo. Entonces, ¿cuál es la diferencia, como preguntó Previn, entre ahora y el sello del reloj? Así que una pequeña desviación lateral aquí en el buen viejo intercambio de pilas. Dice que no veo ninguna diferencia, sin embargo afirman, ah, no hay diferencia. Así que las funciones estándar de SQL devuelven un valor basado en la hora de inicio de la transacción actual, la marca de tiempo actual, la marca de tiempo de la transacción, equivalentes a la marca de tiempo actual. Este es el equivalente tradicional de Postgres a las marcas de tiempo de la transacción. Así que ahí vamos. Bueno saber. Así que supongo que ahora es básicamente un envoltorio para eso, al igual que ahora es a menudo un envoltorio en otras bases de datos para esas cosas. Es una muy buena pregunta, sin embargo. Y para elaborar sobre la preocupación de la que a menudo se deriva la pregunta, necesitas asegurarte de que, cada vez que usas cualquier tipo de marca de tiempo, está marcándola en la zona, en el formato, y con otros detalles que esperas. Y sabes, los criterios que, por ejemplo, ¿está usando un servidor de tiempo, verdad? ¿O está usando el reloj de tiempo local o el reloj del servidor local de la database? ¿Verdad? ¿El servidor local está en tu zona horaria, o está en UTC, o incluso está configurado en UTC, pero en una ubicación diferente? Hay muchas variables diferentes alrededor de los tiempos y las marcas de tiempo que necesitas tener en cuenta, especialmente, aún más, si la marca de tiempo se está utilizando para una auditoría legal. A menudo en esa situación, querrías estandarizar en algo específico que esté bien documentado, como UTC, y luego hacer cualquier conversión a otras zonas horarias o lo que sea basado en el UTC para esa auditoría y la marca de tiempo. Saber lo que hace la función y cuán precisa es la marca de tiempo es crucial para poder entender exactamente en qué estás trabajando. Saber lo que hace la función y cuán precisa o posiblemente imprecisa puede ser una función al hacer una marca de tiempo es enormemente importante. Tenemos nodos de fuente, esquema, nota JOT. Vamos a ver eso. Voy a poner UUID allí. Voy a hacer rápidamente todos ellos. De nuevo, sello. Ahora lo genial, si usas la CLI de Hestera, todo esto mientras lo haces en la console se automatizaría y se mantendría en la migración. Así que cada vez que ejecutes tu DDL, ejecutes tu esquema de database, puedes moverte de un lado a otro entre las versiones que guardas. Como esta sería la versión dos en la que estoy trabajando ahora con estas funciones predeterminadas adicionales en su lugar. Así que con las migraciones y usando la CLI, puedes ir automáticamente de un lado a otro entre esas con un simple Hestera Migrate Apply. Y la console, puedes ejecutar desde tus migraciones para llevarlo a cabo y luego hacer estos cambios. Y escribe el SQL en tu carpeta de migraciones dentro de tu proyecto. Así que es muy fácil, como mencionó Melanie antes, ¿cómo te mantienes al día con estas cosas en tu proyecto? Es muy fácil entonces porque crea el SQL para ti para tener en tu Directorio de Migraciones que puedes poner en tu repositorio y en cualquier otro material que necesites para tu proyecto, ya sea tarjetas de Jira o algo más.

Bien, así que tenemos esos. Ahora entremos en el mundo de GraphQL. Con Asura, inspecciona contra la base de datos que en este caso es la base de datos que hemos creado recientemente contra nuestras tablas particulares que mira nuestras relaciones e infiere cosas e infiere lo que deberían ser entidades. En este caso, las entidades son generalmente la tabla. Así que de nuevo, como se mencionó anteriormente, es importante elegir el formato de letras. Ayuda a traer familiaridad a lo que es el concepto de la cosa que estás trayendo de vuelta que tu consulta en contra, etc para las personas que escriben código contra esta API en particular, ¿verdad? Así que elige tu formato de letras CamelCase o PascalCase en consecuencia.

Aquí, veamos, íbamos a hacer fuente. Hagamos una consulta básica. Elige ID, nombre, sello y URI. Por supuesto, no tenemos nada aquí. Ejecutamos eso, boom, nada, ¿verdad? Sin embargo, tenemos algo, hemos ejecutado una consulta. Si miras el historial, mi consulta ha sido ejecutada. Si cambias el nombre a otra consulta, por ejemplo, y ejecutas eso, boom, aparece en el historial. Puedes volver a estas varias consultas y mirarlas. Así de fácil, solo haciendo clic en las cosas.

El explorador, voy a cerrar eso por un segundo. Voy a cerrar el historial por un segundo. Ahora digamos que necesitas escribir algo de código que va a ejecutar esta declaración GraphQL. Haz clic en CodeExporter. Tienes opciones aquí, TypeScript, JavaScript. Como puedes ver a continuación, proporciona el código que necesitas para ejecutar eso, básicamente en formato de copiar y pegar. Puedes cambiar de fetch, o puedes usar React Apollo. Muestra la base de código pertinente para eso. Así que, una característica súper útil allí. Deshagámonos de CodeExporter por un segundo. A continuación, haz clic en Voyager. Transmitiendo al espacio. Bien, esto puede ser un poco abrumador al principio. Así que, vamos a acercar. Como puedes ver, este es un mapa de los metadatos que se crearon sobre la base de datos, que tiene todas las correlaciones, etc. Rutas de consulta para cada una de las tablas que creamos, acción, agregado de acción, conexión, formateador, notejot, esquema, fuente, etc. Y luego eso se mapea para mirar los nodos, los mínimos, máximos, mira los tipos de datos y otras cosas así. Tienes tu conexión, fuente, y la lista continúa. Así que una gran manera de averiguar qué está pasando en lo que respecta a la base de datos en el diseño de GraphQL encima del esquema de base de datos construido con DDL. OK. Muy, muy útil, lugar muy importante a medida que comienzas a construir modelos más complejos y necesitas solucionar problemas con lo que quieres hacer con tu API de GraphQL y determinar qué quieres hacer en cuanto al modelo, pero también tus entidades y cosas así. Luego hagamos un análisis rápido y veamos qué obtenemos. Ese es el análisis de consulta que mostré un poco antes en las diapositivas. Así que consulta bastante fácil porque solo se ejecuta contra la entidad única, y en este caso, una sola tabla. Así que hay algunas holguras anidadas, que es cómo se produce la generación predeterminada de estas cosas. A medida que tus consultas se vuelven más complejas, esto se vuelve más complejo. Y puedes entrar aquí y ver qué estás obteniendo y ejecutando en el lado del servidor. Así que vamos a entrar en eso un poco.

Primero, aclaremos eso. Regresemos a Explorer. Y aquí está, esta es una de las características que me encanta de Hasura y su integración con GraphiQL. Es como si fuéramos a la fuente. Y cambiemos esto a una mutación. Y verás todas las inserciones, actualizaciones, eliminaciones, etc. ahora. Vamos con la fuente, hagamos una inserción, y quiero, no voy a insertar el ID, así que lo quitaré. Quiero hacer el nombre y quiero hacer el URI. Eso es todo. Porque el ID y el sello de tiempo serán realizados por la database, ¿verdad? Así que deshagámonos de esto. Y luego control espacio, al igual que en GraphiQL normal, te dará el autocompletado para las cosas. Así que solo quiero devolver eso. Voy a pedir el ID y el sello. Vale. Eso me dará confirmación sobre varias cosas. Una, que el registro fue creado cuando pedí que se creara. Me dará el ID y el sello, así que sabré cuándo se hizo. Y también tendré el ID si quiero referirme a ese registro en particular con lo que estoy haciendo en mi code base. Así que una táctica de consulta bastante común que uso. Bien, entonces, primera fuente. ¿Cuál es una buena página web? ¿Alguien tiene una buena página web? Voy a ir a mi blog. Lo usaré como referencia. Así que composite code dot blog. Pongo eso allí. Y luego el nombre de eso es composite. Composite. Brash encode. Y voy a añadir eso. Así que aquí vamos. Tenemos el ID y el sello. Vuelve de eso. Estamos listos para ir. Vamos a otro sitio web. Vamos a YouTube. Al canal de Hasura HQ. Muchos buenos contenidos por ahí. Así que un gran saludo a nuestro contenido en YouTube. Así que voy a tomar eso y simplemente lo pondré aquí. Así que ahora tenemos algunos registros. Y boom. Nuevo ID, nuevo sello. Así que eso es genial. Así que ahora tomemos ese ID aquí, y añadamos un valor relacionado. Vamos a la fuente. Y luego queremos hacer formatter. Digamos que YouTube tiene una API. Así que estaríamos añadiendo algo al formatter. Esa es la actualización. Quiero la inserción. Tendremos el ID de conexión.

¿Qué dibujé? Estoy pensando que esto es malo. Aquí vamos. Necesitamos hacer la conexión primero, así que haremos el ID de la fuente. Y luego, sí, ahí vamos. Vaya. Hype eso. SKING. Vale, eso está bien. Luego haremos, pensé que había llamado, oh sí, acción. Veamos cómo podemos hacer esto. Así que formatter. Ves donde esto empieza a complicarse cuando estás haciendo multi-inserción.

Vale, en realidad me he confundido. Déjame mirar esto de nuevo. Vale, puse la fuente y quiero simplemente añadir, necesito añadir la conexión a la fuente primero. Entonces, ¿qué necesita la conexión? Necesita todas estas cosas. Así que necesita el ID de la acción, el ID de la fuente. Creo que lo dejé, asegurémonos de que lo dejamos nullable. Sí, así que puedes añadir uno u otro mientras se está haciendo. Para notar, eso es otra cosa. Si tienes elementos de clave externa que tienen elementos requeridos, el elemento de clave primaria, ese ID necesita estar disponible para ser insertado con este registro cuando este registro finalmente se junta con todos sus elementos requeridos. Y si eso lleva un minuto, es posible que no tengas ese identificador único si acabas de enviar el elemento de clave primaria al cliente, ¿verdad? Y luego por alguna razón no has obtenido el valor de auto incremento o algo así. Así que eso es importante tener en cuenta. Así que veamos aquí. Conexión. Necesitamos ir con el ID Standards. Volvamos y hagamos eso. Así que el ID se generará para nosotros, y luego queremos hacer el ID de la Fuente, eso es lo que queremos añadir. Y lo añadí. Cambia esto a mutar. Y mutación. Ahí vamos. Y voy a deshacerme de esto. Iremos a Insertar Conexión. Así que querremos... Así que tu ID se hará por nosotros. Queremos el ID de la Fuente. Eso es lo que copié. Vale, ahí vamos. Entonces no necesitaremos este sello. Y eso simplemente proporcionará la conexión. Debe tener una selección de subcampos. Así que veamos, Fuente. En realidad, hagamos esto. Mm. Siento que tal vez deberíamos crear los otros elementos primero y luego este. Así que por eso, voy a saltar eso, y vamos a mirar la ejecución de nuevo. Así que tenemos la fuente. Veamos esos. Ahí vamos.

Entonces tenemos dos. No hay detalles ahí. Uno es un blog. El otro es el otro. Entonces, si hacemos eso, pero luego decimos donde, vamos con el nombre igual a hasura.hq. Vaya. Se llama consulta de un solo registro. Así que podemos verlo directamente. Y luego voy a abrir el historial. Así que ahí está, junto con los demás. Voy a tomar un análisis de eso y veremos lo que tenemos.

Entonces aquí puedes ver que el where se factura como tal. Lo que voy a hacer es que voy a desplazarme hasta donde está, y voy a seguir adelante y usar el where se factura como tal. Entonces el nombre de la fuente pública es HHQ es igual al texto. Es un poco extraño, porque podrías no pensar en esto como el SQL que escribirías tú mismo si fueras a escribir esta consulta, pero te muestra cómo se hace esto y cómo se llenan estas cosas. Y puedes tomar la determinación. Y por supuesto, aquí están las tres cosas. De esta consulta, se ejecuta esa consulta. Luego se ejecuta esta consulta en ese conjunto de resultados para mostrar los conjuntos que se devuelven, es decir, las tuplas que se devuelven. Y mapea ID a ID, nombre a nombre, detalles a detalles para que cuando lo veas, vuelva justo así.

Pero a medida que esto se complica, vamos a mirar uno de estos locos. Digamos que tenemos conexión, y quieres mostrar varios cosas pertinentes. Quieres ver la acción, y luego el formateador, mapa del formateador, ID del sello. Luego quieres la fuente, nombre, ID, sello. Puedes ver cómo esto empieza a anidar. Tienes conexión, y luego acción dentro de eso. Dentro de la acción tienes conexiones, y luego fuente. Ahora veamos si esto se ejecuta. Lo hizo. Sin embargo, hablemos de esto por un segundo. Puedes ver que hay muchos más pasos para lo que acaba de ocurrir, aunque no hay data para ejecutar contra. Todavía tiene que pasar por estos pasos. Hay un escaneo de secuencia de bucle anidado, un escaneo de índice de bucle anidado otro agregado, bucle de nido, escaneo de secuencia de bucle de nido dentro de eso, otro escaneo de índice, etc. Entonces, si esto es por decir, un registro en esta unión, el siguiente entonces se ejecuta, se consulta, contra el conjunto de todo eso. Así que puedes tener un exponencial o incluso un producto cartesiano de la consulta. Técnicamente podrías matar tu servidor con ciertos tipos de consultas como esta. Y necesitas estar consciente de eso para que puedas tomar precauciones. Por ejemplo, esta conexión en acción. Probablemente no querrías llamar a eso tan profundo en él, lo más probable. Querrías mantenerlo al mínimo a un nivel más alto. Querrías hacerlo como máximo uno, tal vez dos niveles de profundidad. La buena regla a seguir, como con el design relacional, es que nunca realmente quieres ir demasiado lejos por el camino con demasiados uniones. A medida que se añaden las uniones, se ve un gran pico en la disminución del performance, debido a los escaneos correlativos que tienen que hacerse contra la database. Para minimizar eso, mantienes las cosas uno, un nivel de profundidad, dos niveles de profundidad. Y puedes pensar en esos como tus uniones, ¿verdad? A medida que te adentras en un objeto de entidad como ese, sin embargo, aumentas tus uniones. Así que cuando design tu esquema de database, piensa en las entidades de GraphQL y cómo serán consultadas. Así que una de las cosas que puedes hacer para arreglar las consultas o para cambiar las cosas para que puedan ser más rápidas o más fácilmente consultables, si sabes que ciertos conjuntos de data siempre son necesarios juntos, puedes crear una tabla desnormalizada. Y tal vez con code o algo más, tener eso llenado al mismo tiempo que llenas tus tablas de sistema de registro. Ahora, una forma de hacer eso es como si volviéramos a data, y digamos que queremos esa conexión con su data relacionada requerida.

Entonces tenemos ID de sello, pero tiene un ID de acción y un ID de origen. Por lo tanto, podríamos querer una tabla que tenga todas las columnas del ID de acción y el ID de origen combinados. Muy desnormalizado, muchos elementos redundantes de data dentro de eso. Entonces, como se señaló anteriormente sobre la cardinalidad, tu cardinalidad distinta disminuye, y tienes mucha redundancia dentro de una tabla. Pero tienes una sola tabla o una sola entidad en GraphQL para consultar. Entonces puedes consultar contra múltiples elementos diferentes dentro de esa entidad, o en el lenguaje SQL, múltiples columnas diferentes para consultar en esa entidad para poder obtener resultados más rápidos. Y también obtener resultados que solo están anidados un nivel de profundidad para minimizar la cantidad de uniones y anidamientos dentro de la consulta en sí que tiene que ejecutarse contra la database.

Entonces, con eso, ¿alguna pregunta sobre eso? Porque ahí es donde una gran parte del rendimiento y una gran parte del diseño necesitan entrar en juego es alrededor de la normalización o desnormalización de los datos para cambiar cómo preguntamos cosas con nuestras consultas y GraphQL de las entidades. ¿Qué partes de la entidad queremos en un momento particular? ¿Queremos más de lo que está disponible en una sola entidad? ¿Necesitamos expandir esa entidad para ser más inclusiva de otras cosas? Esas son las cosas que necesitamos tener en cuenta.

Entonces, preguntas, comentarios, etc. Mientras piensas en cualquier otra pregunta o comentario, voy a mostrar mi última diapositiva, porque eso es básicamente el material que tengo para esto. Para que sepas, la diapositiva tiene enlaces, haré disponibles estas diapositivas. Las publicaré en el discord en los próximos minutos. Así que si quieres los enlaces en las diapositivas, puedes obtener las diapositivas y tienen los enlaces a ellas. Todo son diapositivas de Google, así que nada, no se necesita ningún formato o aplicaciones locas para ello, y voy a añadir algunas cosas aquí. Por ejemplo, yo, puedes encontrarme en Twitter en Adren. Twitter, Twitch, Adrian. Twitter, Twitch y YouTube también. También transmito programas en Hasura HQ sobre este tema específico en relación con la herramienta Hasura. Hay mucho material por ahí sobre migraciones. Voy a hacer más. Y en un futuro muy cercano, en 2021, estaremos escribiendo aplicaciones con React, Vue.js, cosas así alrededor del servidor API de Hasura usando GraphQL. Hay muchos, muchos temas de GraphQL en profundidad allí. Así que asegúrate de seguirnos en Twitch, suscríbete en YouTube y síguenos en Twitter. Yo, personalmente, estoy disponible en Twitter en twitter.com slash Adrian. Y en Twitch en twitch.tv slash, vaya, thrashing code. Y en YouTube en lo mismo. También tenemos GraphQL Asia próximamente. Así que, si estás interesado, definitivamente échale un vistazo. Y para más formación sobre este tema específico, así como muchos otros alrededor de GraphQL, cómo hacer modelado de datos alrededor de GraphQL, echa un vistazo a siro.io slash eventos. Hay muchas cosas buenas allí. Y eso es prácticamente todo. Creo que podría tener, veamos aquí. Oh no. Definitivamente sígueme en Twitter y avísame si estás interesado en créditos. Porque creo que tengo algunas opciones de crédito bastante geniales que puedo darte. Pero sígueme y te las daré porque no tengo el código conmigo en este momento. ¿Cuáles son los casos de uso previstos para Hasura? ¿Es esto principalmente para aplicaciones CRUD empresariales o para aplicaciones web móviles orientadas al consumidor? Anibertec pregunta. Sí. ¿No es esa la mejor respuesta, sí? Por lo tanto, definitivamente puede ser utilizado muy, muy fácilmente para aplicaciones CRUD. Porque como viste, mientras trabajaba en ello, puedes entrar y todas las características CRUD están allí por defecto, de serie. Como todas estas cosas, nada de esto fue preparado al principio de la masterclass. Lo hice como lo haría en cualquier circunstancia la primera vez que lo hago, para todos ustedes. Una de las razones por las que hago eso es para asegurarme de que no hay pequeños contratiempos en el medio. Me gusta asegurarme de que cualquier material que presento es fluido de principio a fin, para que tu experiencia sea la misma experiencia que lo que te estoy mostrando. No quiero trucos allí. Entonces, lo viste allí mismo, simplemente, boom. Todas las capacidades CRUD están allí por defecto. Sin embargo, Hasura hace mucho más que simplemente darte eso. Por ejemplo, puedes mirar Acciones. Y puedes añadir acciones que hagan validación personalizada, autenticación personalizada, como si estás usando un OAuth con Auth0 o algo así. Te da esas capacidades para añadir eso y luego ejecutar GraphQL contra eso, o crear contra eso de esa manera. Los esquemas remotos te permiten conectar a un punto final que es GraphQL, y luego integrarlo e incluso dibujar relaciones entre este otro punto final de GraphQL técnicamente no relacionado y dibujarlo a tu punto final de GraphQL aquí en Hasura y dibujar correlaciones entre él, como las relaciones que vimos, que se impulsa a sí mismo contra la base de datos a la que está directamente apuntado. Con los esquemas remotos, sin embargo, puedes apuntar esto a esos lugares y básicamente traer todo tipo de otras APIs de GraphQL y centralizarlas para proporcionar un único punto de referencia para tus desarrolladores o escritores de informes o lo que sea para acceder y tener todas esas relaciones correlativas y todo lo que necesitan y deberían tener para hacer la vida más sencilla mientras hacen desarrollo desde este punto singular. Así que eso va mucho más allá de simplemente el crud, ¿verdad? En cuanto a las aplicaciones móviles orientadas al cliente, sí, definitivamente lo usaría para eso. Puedes configurar permisos basados en roles, autorización, todo tipo de cosas allí.

Básicamente lo que está disponible en Postgres se extiende más allá de eso y a medida que agregamos bases de datos como MySQL, SQL Server, que sucederá muy pronto, esos permisos también se mapearán en consecuencia para que puedas tener todas esas capacidades que necesitas, especialmente como en escenarios más complejos, extraños, enterprise para asegurarte de que tienes los permisos correctos y roles y otras cosas como esa para el software del cliente.

Otras cosas que tenemos, puedes básicamente scale esto horizontalmente, así que para sitios web de gran tamaño orientados al cliente o mobile apps que necesitarías algunas capacidades de muy alta escala para, tenemos opciones alrededor de eso también. Si fueras a usar algunas de las opciones de alta escala para Postgres, simplemente apuntas esto a esa opción de alta escala y boom, estás listo para ir. Como creo que Citus y algunos de los otros, o algunas de las grandes opciones de RDS dentro de Amazon incluso.

Quiero decir, supongo que los tipos de los campos JSON en Postgres a través de Hasura. Vale, te voy a hacer una pregunta porque no estoy seguro del contexto exacto. Entonces, ¿qué era? Teníamos acción, y esto es JSON, ¿verdad? También puedes hacer JSON-B, ¿verdad? Y creo que eso añade más contexto para algunos escenarios. Alrededor de la tipificación y tal. Pero si sólo haces JSON, creo que hay. No recuerdo exactamente qué hemos hecho en el pasado específicamente para eso. Para llevar los tipos JSON a través en ese objeto JSON. Estoy tratando de pensar cómo PostgreSQL incluso lo hace. Si lo hace. Sí, eso es un poco complicado. Porque de lo contrario quiero decir, como probablemente sabes, cuando tienes JSON, si sólo obtienes el JSON, y no hay algo para inferir los tipos dentro del JSON en sí, generalmente son sólo cadenas, ¿verdad? Si tuvieras un array, sería un array de cadenas, a menos que se designe. A menos que puedas encontrar alguna manera de que, e inferir que es un int o algo así. Así que creo que tendrías que hacer eso de la misma manera que lo inferirías si sólo obtuvieras JSON del que no sabías nada. Esa es una buena pregunta, sin embargo. Tendría que comprobar eso y ver específicamente cuál es el detalle alrededor de eso. Porque no estoy seguro en este momento. En algún lugar de ahí, hay algo, sin embargo. Porque sé que los tipos se mapean en consecuencia, así que lo que sea que esté en Postgres debería estar disponible de alguna manera, forma o manera. Si no está disponible para ti, infiere los tipos tal cual, y Postgres lo hace, entonces Haseera en algún momento podrá hacer eso si no lo hace ya.

Una cosa más, justo aquí al final, por supuesto que me acuerdo de esto justo al final. Creé una lista que quería repasar. Voy a pegarla justo aquí. PerthTips. Estos son algo arbitrarios, no específicamente relacionados con el esquema, sino en general. De alguna manera se relacionan con el esquema, pero de nuevo, son sólo en general. Veamos aquí, pegar sin formato. ¿Puedo hacer eso? Sí, ahí. Hay sólo unos pocos que he estado recogiendo las últimas semanas. Que están más relacionados con cosas que noto que específicamente ayudan al lado de las consultas de GraphQL y tal, desde la perspectiva de la database.

Uno, minimizar las uniones, lo mencioné. El uso de exists en lugar de in para comprobar la existencia de data. Me he encontrado con ese escenario varias veces. Eso es prácticamente sinónimo contra cualquier cosa que vayas a ejecutar ANSI SQL contra. Así que SQL server, Postgres, etc., eso ayuda. Siento que es un poco tonto mencionarlo pero usa el tipo de data apropiado para una cosa, si es un tipo de data particular. Sí, los conseguiré allí. Esa es una buena llamada, probablemente. O en hypertech. Voy a volver, eso es raro. También, mencioné que puedes crear índices en columnas en la database. Sí, puedes. Sin embargo, eso no significa que obtengas un impulso de performance si vas a crear un índice para cada columna. Dependiendo de cómo la database haga índices, que generalmente es similar entre las bases de datos relacionales, quieres elegir una o dos o tal vez tres, a lo sumo, columnas contra las que vas a hacer consultas dentro de la cláusula WHERE de obviamente tu GraphQL o tu SQL, a medida que se mapea a través. Quieres que esa cláusula WHERE se ejecute contra columnas de índice, idealmente. Pero si estás haciendo cláusulas WHERE contra un montón de columnas diferentes, entonces es un poco difícil de elegir. Quieres elegir las columnas que tendrán la mayor cardinalidad distinta.

Eso es una cosa, si hay mucha redundancia, los índices pueden ser problemáticos. Así que realmente tienes que hacer pruebas y errores a través de algo de eso y familiarizarte más con cómo la database optimiza y mejora la ruta de ejecución y los escaneos de las consultas. Y también mencioné la desnormalización de los data, que es tomar esa clave primaria y extranjera estándar y simplemente agrupar un montón de columnas en una única tabla, eso puede ayudar. Pero por supuesto, pierdes tu cardinalidad distinta, y luego tienes que sopesar qué columnas indexar y cuántas cosas deberías tener juntas o no deberías tener juntas debido a la redundancia dentro de la tabla.

Esto es algo, sin embargo, si tienes un servidor que utiliza Apache Cassandra y ejecutas un GraphQL encima de eso, Apache Cassandra funciona de manera muy diferente en cómo hacer esto. Tienes una estructura de tabla, pero es de columnas y almacenada, y tus cláusulas where sólo pueden hacerse contra una o dos columnas, generalmente hablando, a la vez. Pero puedes tener literalmente petabytes de data en una tabla y obtener consultas oportunas contra eso debido al scaling horizontal de Apache Cassandra, por ejemplo. Pero de nuevo, como decía, eso es muy diferente, una database muy diferente al modelo relacional, pero te da esa capacidad de informes que no es ni siquiera comparable porque las lecturas son muy rápidas.

Veamos aquí, oh sí, esquemas, en algunas de las bases de datos, parece que el esquema no es, hay un poco de redundancia. Así que hay esquema de modelo de database, y luego está la característica de esquema. En Postgres, puedes nombrar un esquema y luego poner tablas dentro del esquema. Hay el esquema de design, donde todas las tablas están relacionadas entre sí, pero luego está el esquema, casi como si fuera un espacio de nombres en el que puedes organizar tablas. Así que luego tienes mi esquema.nombre de la tabla cada vez que escribes una consulta. Poner cosas en esquemas ayuda a organizar, pero también puede ayudarte a optimizar necesidades específicas de performance o algo así, y a desglosar cosas por dominio empresarial u otras necesidades. SQL Server tiene opciones como esa, al igual que Oracle, etc. No siempre se llama esquema, pero es como un elemento de espacio de nombres dentro de la database para poder desglosar las tablas en agrupaciones. No cambia realmente la tabla en sí de ninguna manera, sólo que, la agrupa donde la desglosa en una estructura organizativa de dominio.

Muy bien, entonces sí. ¿Alguna otra pregunta? Voy a estar aquí durante los próximos cinco minutos, al menos. Voy a compartir estas diapositivas rápidamente, y las publicaré en el Discord ahora mismo. Así que si tienes más preguntas, no dudes en hacerlas. Responderé todo lo que pueda. Si no, te ayudaré a encontrar una respuesta a eso. Mientras tanto, si tienes alguna pregunta o quieres que las responda, mientras tanto, voy a compartir estas rápidamente y te las daré. Así que gracias por asistir, espero que esto haya sido útil, y de nuevo, ya sabes, sígueme, sigue el Twitch de Hasura, etc., lee el blog, échale un vistazo, hay mucho más por ahí que estamos produciendo y produciremos, y mucho más específicamente en torno a conectar el esquema de la database y el modelado del design para hacerlo bien con GraphQL en mente. Para hacer el desarrollo más rápido, más fácil, más robusto y capaz a medida que lo haces. Así que de nuevo, gracias, voy a dejar de compartir mi pantalla, te daré esos enlaces y estaré en el chat. Así que gracias de nuevo a todos, saludos.