{"id":83649,"date":"2020-06-02T07:42:21","date_gmt":"2020-06-02T05:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/database-as-sode-experience"},"modified":"2020-06-02T07:42:21","modified_gmt":"2020-06-02T05:42:21","slug":"database-as-sode-experience","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/database-as-sode-experience","title":{"rendered":"Experiencia de \u00abDatabase as Code\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Experiencia<\/p>\n

<\/p>\n

SQL, \u00bfqu\u00e9 puede ser m\u00e1s sencillo? Todos nosotros podemos escribir una consulta simple: escribimos select<\/em><\/strong>, enumeramos las columnas necesarias, luego from<\/em><\/strong>, el nombre de la tabla, un poco de condiciones en donde<\/em><\/strong> y voil\u00e0, tenemos datos \u00fatiles en nuestras manos, casi independientemente de qu\u00e9 sistema de gesti\u00f3n de bases de datos est\u00e9 en funcionamiento (o puede que no sea una base de datos en absoluto<\/a><\/noindex>). Como resultado, se puede considerar el trabajo con pr\u00e1cticamente cualquier fuente de datos (relacional y no tan relacional) desde la perspectiva del c\u00f3digo normal (con todas las implicaciones: control de versiones, revisi\u00f3n de c\u00f3digo, an\u00e1lisis est\u00e1tico, pruebas autom\u00e1ticas y todo eso). Y esto se aplica no solo a los propios datos, esquemas y migraciones, sino a toda la actividad del almacenamiento. En este art\u00edculo, hablaremos sobre las tareas cotidianas y los problemas al trabajar con diversas bases de datos bajo la perspectiva de "la base de datos como c\u00f3digo".<\/p>\n

<\/p>\n

Y comenzaremos justo con ORM<\/a><\/noindex>. Las primeras batallas del tipo "SQL vs ORM" se observaron ya en la antigua Rus<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Mapeo objeto-relacional<\/h5>\n

<\/p>\n

Los defensores de ORM valoran tradicionalmente la velocidad y la simplicidad en el desarrollo, la independencia del sistema de gesti\u00f3n de bases de datos y la limpieza del c\u00f3digo. Para muchos de nosotros, el c\u00f3digo que trabaja con la base de datos (y a menudo la propia base de datos)<\/p>\n

<\/p>\n

generalmente se ve algo as\u00ed\u2026<\/b><\/p>\n

@Entity\n@Table(name = "stock", catalog = "maindb", uniqueConstraints = {\n        @UniqueConstraint(columnNames = "STOCK_NAME"),\n        @UniqueConstraint(columnNames = "STOCK_CODE") })\npublic class Stock implements java.io.Serializable {\n\n    @Id\n    @GeneratedValue(strategy = IDENTITY)\n    @Column(name = "STOCK_ID", unique = true, nullable = false)\n    public Integer getStockId() {\n        return this.stockId;\n    }\n  ...<\/code><\/pre>\n
<\/p>\n
El modelo est\u00e1 adornado con inteligentes anotaciones, y en alg\u00fan lugar detr\u00e1s de escena, el valiente ORM genera y ejecuta toneladas de c\u00f3digo SQL. Cabe mencionar que los desarrolladores est\u00e1n tratando por todos los medios de aislarse de su base de datos con kil\u00f3metros de abstracciones, lo que indica una cierta "odio SQL"<\/a><\/noindex>.<\/p>\n
<\/p>\n
Al otro lado de las barricadas, los defensores del puro "handmade"-SQL destacan la posibilidad de exprimir al m\u00e1ximo su SGBD sin capas adicionales ni abstracciones. Como resultado, surgen proyectos "centrados en los datos", donde la base de datos es manejada por personas especialmente capacitadas (los mismos "database guys", tambi\u00e9n conocidos como "db admins", "data managers", etc.), y a los desarrolladores solo les queda "tirar" de vistas y procedimientos almacenados existentes, sin adentrarse en los detalles.<\/p>\n
<\/p>\n
\u00bfY si tomamos lo mejor de ambos mundos? Como se hace en la maravillosa herramienta con un nombre alentador Yesql<\/a><\/noindex>. Citar\u00e9 un par de l\u00edneas de la concepci\u00f3n general en mi libre traducci\u00f3n, y se puede conocer m\u00e1s a fondo. aqu\u00ed<\/a><\/noindex>.<\/p>\n
<\/p>\n
Clojure es un gran lenguaje para crear DSLs, pero SQL ya es en s\u00ed un gran DSL, y no necesitamos otro. Las expresiones S son geniales, pero aqu\u00ed no aportan nada nuevo. Al final, tenemos par\u00e9ntesis por el simple hecho de tener par\u00e9ntesis. \u00bfNo est\u00e1n de acuerdo? Entonces esperen el momento en que la abstracci\u00f3n sobre la base de datos empiece a fallar, y comenzar\u00e1n la lucha con la funci\u00f3n. (raw-sql)<\/em><\/p>\n
\u00bfY qu\u00e9 hacer? Dejemos el SQL como SQL normal: un archivo por cada consulta:<\/p><\/blockquote>\n
<\/p>\n
-- name: users-by-country\nselect *\n  from users\n where country_code = :country_code<\/code><\/pre>\n
<\/p>\n
\u2026 y luego lee este archivo, convirti\u00e9ndolo en una funci\u00f3n normal de Clojure:<\/p><\/blockquote>\n
<\/p>\n
(defqueries "some\/where\/users_by_country.sql"\n   {:connection db-spec})\n\n;;; Se ha creado una funci\u00f3n con el nombre `users-by-country`.\n;;; Usemosla:\n(users-by-country {:country_code "GB"})\n;=> ({:name "Kris" :country_code "GB" ...} ...)<\/code><\/pre>\n
<\/p>\n
Siguiendo el principio de "SQL por un lado, Clojure por el otro", obtienes:<\/p>\n