<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>SQL Server on DataFrame</title>
    <link>https://dataframe.hr/categories/sql-server/</link>
    <description>Recent content in SQL Server on DataFrame</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 03 Apr 2023 00:00:00 +0200</lastBuildDate>
    <atom:link href="https://dataframe.hr/categories/sql-server/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Should you index every foreign key column?</title>
      <link>https://dataframe.hr/sql-server/should-you-index-every-foreign-key-column/</link>
      <pubDate>Mon, 03 Apr 2023 00:00:00 +0200</pubDate>
      <guid>https://dataframe.hr/sql-server/should-you-index-every-foreign-key-column/</guid>
      <description>Yes, you should index every foreign key column, unless you have a very good reason not to.&#xA;To understand why, let’s take a look at the execution plans of following scenarios:&#xA;deleting records using FK column as the filter: deleting from primary key table: In both scenarios, the worse performing plan (by far) is the one without an available index.&#xA;Furthermore, notice that in the second scenario SQL Server doesn’t give an index recommendation.</description>
    </item>
    <item>
      <title>How to optimize DWH column updates</title>
      <link>https://dataframe.hr/sql-server/how-to-optimize-dwh-column-updates/</link>
      <pubDate>Wed, 08 Feb 2023 00:00:00 +0200</pubDate>
      <guid>https://dataframe.hr/sql-server/how-to-optimize-dwh-column-updates/</guid>
      <description>Column updates might not be an issue while the warehouse is new, but as rows accumulate the performance might start to drop drastically and refactoring will be a challenge. It’s best to plan ahead and design your warehouse properly, so let’s cover how to optimize DWH column updates.&#xA;SCD1 scenario First, consider a simple DWH SCD1 update statement (assuming only 9 non-nullable, non-FK columns):&#xA;UPDATE tar SET Column1 = src.Column1 , Column2 = src.</description>
    </item>
    <item>
      <title>Slow queries in the application</title>
      <link>https://dataframe.hr/sql-server/slow-queries-in-the-application/</link>
      <pubDate>Thu, 22 Dec 2022 00:00:00 +0200</pubDate>
      <guid>https://dataframe.hr/sql-server/slow-queries-in-the-application/</guid>
      <description>Ever wondered why you encounter slow queries in the application, but they work fine from SSMS?&#xA;I’m sure everyone encounters this issue sooner or later and it has many variations, so I’ll focus on the one I encounter most often.&#xA;Common scenario You produce a great stored procedure, test it meticulously, it passes QA, ends up on production, and everyone is happy. Then couple of months later the client reports a timeout.</description>
    </item>
    <item>
      <title>Always log database errors</title>
      <link>https://dataframe.hr/sql-server/always-log-database-errors/</link>
      <pubDate>Fri, 11 Nov 2022 00:00:00 +0200</pubDate>
      <guid>https://dataframe.hr/sql-server/always-log-database-errors/</guid>
      <description>Should you always log database errors? Even if you think it’s redundant because the applications are already logging everything, having a trustworthy database error table is crucial for efficient troubleshooting sessions.&#xA;It requires some planning ahead, or rework if you already have an operational database, but in the long run it saves everyone’s time and money. Keep in mind I’m not saying that you should handle the errors (as I believe applications are better suited for this), but always log them.</description>
    </item>
  </channel>
</rss>
