<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Snowflake on The Lars Breddemann Blog</title><link>https://0608fde9.lbreddemann-blog.pages.dev/tag/snowflake/</link><description>Recent content in Snowflake on The Lars Breddemann Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 04 May 2023 08:52:07 +0000</lastBuildDate><atom:link href="https://0608fde9.lbreddemann-blog.pages.dev/tag/snowflake/feed.xml" rel="self" type="application/rss+xml"/><item><title>SAP Factory Calendar in Snowflake</title><link>https://0608fde9.lbreddemann-blog.pages.dev/sap-factory-calendar-in-snowflake/</link><pubDate>Thu, 04 May 2023 08:52:07 +0000</pubDate><guid isPermaLink="false">https://www.lbreddemann.org/?p=2165</guid><description>&lt;p&gt;Analysing the data in SAP systems can be done in many ways. While SAP would like all customers to use the tools from their portfolio, many customers prefer to use other platforms. Snowflake is arguably one of the most popular choices for that.
If getting the SAP tables into a different data platform would be all that is needed to start writing SQL queries and getting answers, I suspect a lot more SAP customers would move their analytics stack. Alas, it is not that easy at all.
SAP&amp;rsquo;s database design is peculiar and littered with design choices from decades long past, when saving a few bytes in storage could greatly improve the system&amp;rsquo;s performance or reduce it&amp;rsquo;s resource consumption.&lt;/p&gt;</description></item></channel></rss>