{"id":21057,"date":"2020-05-05T11:30:23","date_gmt":"2020-05-05T09:30:23","guid":{"rendered":"https:\/\/www.teldat.com\/sin-categorizar\/21057\/bases-de-datos-relacionales-y-ahorro-de-costes\/"},"modified":"2023-11-22T10:30:48","modified_gmt":"2023-11-22T09:30:48","slug":"bases-de-datos-relacionales-y-ahorro-de-costes","status":"publish","type":"post","link":"https:\/\/www.teldat.com\/es\/blog\/bases-de-datos-relacionales-y-ahorro-de-costes\/","title":{"rendered":"Bases de datos relacionales y ahorro de costes"},"content":{"rendered":"

\"database\"<\/a> Siempre es buen momento para planificar mejoras. Siempre es bueno revisar c\u00f3mo podemos abaratar nuestros costes de desarrollo en la nube<\/strong>. Los tiempos de respuesta de procesos contra bases de datos<\/strong> (BBDD) de Microsoft SQL Server<\/strong> en Azure<\/strong>, a medida que va creciendo el volumen de nuestros datos se deteriora irremediablemente. Por tanto, debemos anticiparnos mejorando nuestra infraestructura<\/strong> y nuestra manera de actuar con ellas. Todo siempre es susceptible de mejorar sin necesidad de ir contratando mayores y m\u00e1s caros niveles de servicio cuando, a lo mejor, todav\u00eda no es necesario.<\/p>\n

Buenas pr\u00e1cticas en programaci\u00f3n contra bases de datos relacionales y ahorro en costes<\/h2>\n

Refactorizando cierto c\u00f3digo muy concreto, ya en producci\u00f3n, y comenzando a aplicar Buenas Pr\u00e1cticas a la hora de desarrollar contra SQL Server,<\/strong> buscamos mejorar nuestra capacidad de gesti\u00f3n para aumentar el rendimiento actual.<\/strong> Tambi\u00e9n es necesario prevenir cuellos de botella y anticiparnos a problemas que puedan llevarnos posteriormente a grandes costes de desarrollo y recursos.<\/strong> Aplicando Buenas Pr\u00e1cticas tambi\u00e9n podremos disminuir los tiempos de desarrollo de los programadores.<\/strong> El c\u00f3digo, llegar\u00e1 a ser m\u00e1s eficiente<\/strong> <\/em>y entre los distintos programadores se podr\u00e1 reutilizar, comprender y mejorar, ya que ciertas decisiones se podr\u00e1n implementar de forma normalizada y facilitar\u00e1n la labor de equipo<\/strong>. La tarea de un desarrollador que necesite mantener el c\u00f3digo creado por otra persona ser\u00e1 m\u00e1s sencilla. El rendimiento de un sistema de base de datos depende de m\u00faltiples factores,<\/strong> y es dif\u00edcil garantizar que las mejoras reales en el rendimiento coincidir\u00e1n con las predicciones. La optimizaci\u00f3n es, principalmente, un trabajo artesanal que debe abarcar todo el sistema, pero las mejoras m\u00e1s radicales se suelen encontrar solucionando y refactorizando c\u00f3digo poco eficiente contra la BD.<\/strong> No es f\u00e1cil para nadie construir<\/strong> inicialmente un esquema de BD<\/strong> y un c\u00f3digo a prueba de futuro. Cuando comenzamos nuestro negocio, los requisitos son muy diferentes a cuando llevamos muchos a\u00f1os explot\u00e1ndolo. El \u00e9xito de la empresa tambi\u00e9n trae expansi\u00f3n en diferentes geograf\u00edas y un crecimiento del volumen de datos<\/strong>. Esto implica que se puedan volver permanentes algunas de las soluciones que se necesitan crear de forma transitoria y urgente, as\u00ed como mucho \u201cc\u00f3digo personalizado\u201d<\/strong> para la ocasi\u00f3n. Hay numerosas razones para una codificaci\u00f3n deficiente y la mayor\u00eda de las veces se debe a que el desarrollador que est\u00e1 escribiendo el c\u00f3digo no est\u00e1 100 % familiarizado con el esquema de BD o con las nuevas caracter\u00edsticas de Transact-SQL.<\/strong> En cualquier caso, conocer bien el modelo de datos solamente puede traernos enormes bondades y ventajas. As\u00ed pues, dominar nuestro modelo de BD debe ser nuestra primera y obligatoria buena pr\u00e1ctica.<\/strong> Hay muchas m\u00e1s malas pr\u00e1cticas de dise\u00f1o de esquemas de BD,<\/strong> sin embargo, casi siempre las encontramos exclusivamente despu\u00e9s de que nuestro negocio haya tenido \u00e9xito. Y entonces, despu\u00e9s de cierto tiempo, ya es dif\u00edcil cambiar dicho esquema. Por tanto, no se deben tomar nunca decisiones sobre el modelo de datos a la ligera. Al recopilar informaci\u00f3n sobre una aplicaci\u00f3n y c\u00f3mo se utiliza, podemos tomar decisiones de arquitectura inteligente<\/strong> que har\u00e1n que nuestra base de datos<\/strong> sea m\u00e1s escalable y funcione mejor<\/strong> con el tiempo. El resultado ser\u00e1 un mayor rendimiento<\/strong> y una menor p\u00e9rdida de tiempo resolviendo problemas a posteriori. En art\u00edculos posteriores, continuaremos hablando de las grandes ventajas de aplicar las Buenas Pr\u00e1cticas que estamos implantando ya en TELDAT<\/strong> para nuestros desarrollos contra BBDD SQL Server en la nube.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

Siempre es buen momento para planificar mejoras. Siempre es bueno revisar c\u00f3mo podemos abaratar nuestros costes de desarrollo en la nube. Los tiempos de respuesta de procesos contra bases de datos (BBDD) de Microsoft SQL Server en Azure, a medida que va creciendo el volumen de nuestros datos se deteriora irremediablemente.<\/p>\n","protected":false},"author":212,"featured_media":19914,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"off","_et_pb_old_content":"\"database\"<\/a> Siempre es buen momento para planificar mejoras. Siempre es bueno revisar c\u00f3mo podemos abaratar nuestros costes de desarrollo en la nube<\/strong>. Los tiempos de respuesta de procesos contra bases de datos<\/strong> (BBDD) de Microsoft SQL Server<\/strong> en Azure<\/strong>, a medida que va creciendo el volumen de nuestros datos se deteriora irremediablemente. Por tanto, debemos anticiparnos mejorando nuestra infraestructura<\/strong> y nuestra manera de actuar con ellas. Todo siempre es susceptible de mejorar sin necesidad de ir contratando mayores y m\u00e1s caros niveles de servicio cuando, a lo mejor, todav\u00eda no es necesario.\r\n

Buenas pr\u00e1cticas en programaci\u00f3n contra bases de datos relacionales y ahorro en costes<\/h2>\r\nRefactorizando cierto c\u00f3digo muy concreto, ya en producci\u00f3n, y comenzando a aplicar Buenas Pr\u00e1cticas a la hora de desarrollar contra SQL Server,<\/strong> buscamos mejorar nuestra capacidad de gesti\u00f3n para aumentar el rendimiento actual.<\/strong> Tambi\u00e9n es necesario prevenir cuellos de botella y anticiparnos a problemas que puedan llevarnos posteriormente a grandes costes de desarrollo y recursos.<\/strong> Aplicando Buenas Pr\u00e1cticas tambi\u00e9n podremos disminuir los tiempos de desarrollo de los programadores.<\/strong> El c\u00f3digo, llegar\u00e1 a ser m\u00e1s eficiente<\/strong> <\/em>y entre los distintos programadores se podr\u00e1 reutilizar, comprender y mejorar, ya que ciertas decisiones se podr\u00e1n implementar de forma normalizada y facilitar\u00e1n la labor de equipo<\/strong>. La tarea de un desarrollador que necesite mantener el c\u00f3digo creado por otra persona ser\u00e1 m\u00e1s sencilla. El rendimiento de un sistema de base de datos depende de m\u00faltiples factores,<\/strong> y es dif\u00edcil garantizar que las mejoras reales en el rendimiento coincidir\u00e1n con las predicciones. La optimizaci\u00f3n es, principalmente, un trabajo artesanal que debe abarcar todo el sistema, pero las mejoras m\u00e1s radicales se suelen encontrar solucionando y refactorizando c\u00f3digo poco eficiente contra la BD.<\/strong> No es f\u00e1cil para nadie construir<\/strong> inicialmente un esquema de BD<\/strong> y un c\u00f3digo a prueba de futuro. Cuando comenzamos nuestro negocio, los requisitos son muy diferentes a cuando llevamos muchos a\u00f1os explot\u00e1ndolo. El \u00e9xito de la empresa tambi\u00e9n trae expansi\u00f3n en diferentes geograf\u00edas y un crecimiento del volumen de datos<\/strong>. Esto implica que se puedan volver permanentes algunas de las soluciones que se necesitan crear de forma transitoria y urgente, as\u00ed como mucho \u201cc\u00f3digo personalizado\u201d<\/strong> para la ocasi\u00f3n. Hay numerosas razones para una codificaci\u00f3n deficiente y la mayor\u00eda de las veces se debe a que el desarrollador que est\u00e1 escribiendo el c\u00f3digo no est\u00e1 100 % familiarizado con el esquema de BD o con las nuevas caracter\u00edsticas de Transact-SQL.<\/strong> En cualquier caso, conocer bien el modelo de datos solamente puede traernos enormes bondades y ventajas. As\u00ed pues, dominar nuestro modelo de BD debe ser nuestra primera y obligatoria buena pr\u00e1ctica.<\/strong> Hay muchas m\u00e1s malas pr\u00e1cticas de dise\u00f1o de esquemas de BD,<\/strong> sin embargo, casi siempre las encontramos exclusivamente despu\u00e9s de que nuestro negocio haya tenido \u00e9xito. Y entonces, despu\u00e9s de cierto tiempo, ya es dif\u00edcil cambiar dicho esquema. Por tanto, no se deben tomar nunca decisiones sobre el modelo de datos a la ligera. Al recopilar informaci\u00f3n sobre una aplicaci\u00f3n y c\u00f3mo se utiliza, podemos tomar decisiones de arquitectura inteligente<\/strong> que har\u00e1n que nuestra base de datos<\/strong> sea m\u00e1s escalable y funcione mejor<\/strong> con el tiempo. El resultado ser\u00e1 un mayor rendimiento<\/strong> y una menor p\u00e9rdida de tiempo resolviendo problemas a posteriori. En art\u00edculos posteriores, continuaremos hablando de las grandes ventajas de aplicar las Buenas Pr\u00e1cticas que estamos implantando ya en TELDAT<\/strong> para nuestros desarrollos contra BBDD SQL Server en la nube.<\/strong>","_et_gb_content_width":"","footnotes":""},"categories":[1156],"tags":[1087],"class_list":["post-21057","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":19911,"slug":"databases-cost-savings-good-practices","post_title":"Best programming practices for relational databases and cost savings","href":"https:\/\/www.teldat.com\/databases-cost-savings-good-practices\/"}],"_links":{"self":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21057","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=21057"}],"version-history":[{"count":0,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/21057\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media\/19914"}],"wp:attachment":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media?parent=21057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/categories?post=21057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/tags?post=21057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}