{"id":21059,"date":"2020-05-12T07:44:03","date_gmt":"2020-05-12T05:44:03","guid":{"rendered":"https:\/\/www.teldat.com\/sin-categorizar\/21059\/bases-datos-relacionales-ahorro-costes-ii\/"},"modified":"2026-03-25T14:05:06","modified_gmt":"2026-03-25T13:05:06","slug":"bases-datos-relacionales-ahorro-costes-ii","status":"publish","type":"post","link":"https:\/\/www.teldat.com\/es\/blog\/bases-datos-relacionales-ahorro-costes-ii\/","title":{"rendered":"Bases de datos relacionales y ahorro en costes II"},"content":{"rendered":"<p><img decoding=\"async\" class=\"alignleft wp-image-5451 size-medium\" src=\"https:\/\/www.teldat.com\/wp-content\/uploads\/2022\/06\/fernando_tomas_mayo_2020_pt2-300x179.png\" alt=\"Query optimization\" width=\"300\" height=\"179\" title=\"\">En nuestro <a href=\"https:\/\/www.teldat.com\/es\/blog\/bases-de-datos-relacionales-y-ahorro-de-costes\/\" target=\"_blank\" rel=\"noopener noreferrer\">anterior art\u00edculo<\/a> hablamos sobre las grandes <strong>ventajas de aplicar buenas pr\u00e1cticas<\/strong> <strong>de programaci\u00f3n<\/strong> contra SQL Server. Queremos seguir profundizando en ello, centr\u00e1ndonos esta vez en la<em><strong> optimizaci\u00f3n de consultas.<\/strong><\/em><\/p>\n<p><!--more--><\/p>\n<p>El <strong>SQL<\/strong> es un lenguaje declarativo:<strong> cada consulta declara qu\u00e9 queremos que haga el motor de base de datos (BD)<\/strong>, pero no dice c\u00f3mo. Sin embargo, resulta que ese \u201c<strong>c\u00f3mo<\/strong>\u201d (el plan), es lo que afecta a la eficiencia de las consultas, por lo que tambi\u00e9n es bastante importante.<\/p>\n<h2>\u00bfQu\u00e9 es la optimizaci\u00f3n de consultas?<\/h2>\n<p><strong>La optimizaci\u00f3n de consultas<\/strong> es un tema denso que podr\u00eda volverse pesado f\u00e1cilmente. La mejor manera de abordar un problema de rendimiento es encontrar <strong>\u00e1reas espec\u00edficas donde poner el foco.<\/strong> Buscar cosas concretas que probablemente sean causa de una <strong>alta latencia.<\/strong> En estos escenarios, <strong>encontrar c\u00f3digo sospechoso<\/strong> de consumir muchos recursos puede acotar r\u00e1pidamente la b\u00fasqueda y permitirnos<strong> resolver un problema<\/strong> en lugar de vernos obligados a investigar cada l\u00ednea de c\u00f3digo.<\/p>\n<p>La clave es ir identificando patrones de dise\u00f1o comunes que sean indicativos de un <strong>c\u00f3digo Transact-SQL de bajo rendimiento.<\/strong> El desarrollo del reconocimiento de estos patrones, de <strong>detectar errores<\/strong>, puede permitirnos enfocarnos inmediatamente en lo que es m\u00e1s probable que sea el problema.<\/p>\n<p><strong>La optimizaci\u00f3n de consultas<\/strong> a veces requiere recursos adicionales, como puede ser agregar un nuevo \u00edndice. Pero cuando podemos mejorar el rendimiento \u00fanicamente reescribiendo una consulta, reducimos el consumo de recursos sin ning\u00fan coste, aparte de nuestro tiempo. Como resultado<strong>, la optimizaci\u00f3n de consultas puede ser una fuente directa de ahorro de costos<\/strong>. Y m\u00e1s a\u00fan si conseguimos, mediante el uso de<strong> buenas pr\u00e1cticas<\/strong>, crear desde el inicio las consultas de la forma m\u00e1s eficiente posible.<\/p>\n<p>A la hora de <strong>probar consultas y medir mejoras de rendimiento,<\/strong> un error com\u00fan es ejecutarlas en un ambiente de desarrollo cuando el sistema no est\u00e1 ejecutando diferentes consultas de otros usuarios y donde suele haber muy pocos registros. Todo se ejecuta r\u00e1pidamente porque no hay carga en el<strong> servidor de bases de datos de desarrollo.<\/strong> Pero despu\u00e9s, no suele reservarse tiempo suficiente para las pruebas en otros ambientes. Los <strong>entornos de calidad y <em>testing<\/em><\/strong> acaban siendo meros protocolos de transici\u00f3n hacia una subida a producci\u00f3n, en el mejor de los casos. Al final, una vez en explotaci\u00f3n el nuevo c\u00f3digo, si algo no va bien se excusa con la t\u00edpica frase:<em> \u201cNo s\u00e9 c\u00f3mo puede ir tan lento, a m\u00ed antes me funcionaba r\u00e1pido y bien\u201d.<\/em><\/p>\n<p>Cuando una consulta de las anteriores se promueve a un entorno de producci\u00f3n y se ejecuta en un entorno ocupado,<strong> la consulta puede funcionar mal y socavar el rendimiento de la aplicaci\u00f3n.<\/strong> Si en el anterior art\u00edculo ve\u00edamos la importancia de dominar nuestro modelo de BD como principal habilidad, aqu\u00ed tenemos la segunda (y obligatoria) buena pr\u00e1ctica: <strong><em>Siempre hay que vigilar y probar el rendimiento, siempre, incluso si la consulta parece que no va a necesitar emplear muchos recursos del Servidor de base de datos.<\/em><\/strong><\/p>\n<p>Por eso, cuando desarrollamos,<strong> antes de integrar nuestras consultas en el c\u00f3digo de la aplicaci\u00f3n,<\/strong> es muy recomendable utilizar los<strong> Entornos de Desarrollo Integrados (IDE\u2019s) para BBDD relacionales.<\/strong> Por ejemplo, <em>Microsoft SQL Server Management Studio que funciona bien para usuarios de Windows, o Azure Data Studio para Windows, MacOS y Linux.<\/em><\/p>\n<p>En <strong>Teldat<\/strong> seguimos mejorando cada d\u00eda al aplicar las <strong>buenas pr\u00e1cticas para nuestros desarrollos contra BBDD SQL Server en la nube.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>En nuestro anterior art\u00edculo hablamos sobre las grandes ventajas de aplicar buenas pr\u00e1cticas de programaci\u00f3n contra SQL Server. Queremos seguir profundizando en ello, centr\u00e1ndonos esta vez en la optimizaci\u00f3n de consultas.<\/p>\n","protected":false},"author":212,"featured_media":53465,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1156],"tags":[1087],"class_list":["post-21059","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-servicios-en-la-nube","tag-tecnologia-de-comunicaciones"],"acf":[],"wpml_current_locale":"es_ES","wpml_translations":[{"locale":"en_US","id":19916,"slug":"query-optimization-best-practice-monitor-and-test-performance","post_title":"Monitor the performance of queries against databases to eliminate unnecessary costs","href":"https:\/\/www.teldat.com\/query-optimization-best-practice-monitor-and-test-performance\/"}],"_links":{"self":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21059","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/users\/212"}],"replies":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/comments?post=21059"}],"version-history":[{"count":1,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21059\/revisions"}],"predecessor-version":[{"id":76964,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21059\/revisions\/76964"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media\/53465"}],"wp:attachment":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media?parent=21059"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/categories?post=21059"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/tags?post=21059"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}