<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Query in Water Cooler</title>
    <link>https://community.qlik.com/t5/Water-Cooler/Query/m-p/1739624#M11699</link>
    <description>&lt;P&gt;&lt;SPAN class="fontstyle0"&gt;A company generates 1 GB of ticketing data daily. The data is stored in multiple tables Business&lt;BR /&gt;users need to see trends of tickets processed for the past two years. Users very rarely access the&lt;BR /&gt;transaction-level data for a specific date. Only the past two years of data must be loaded which is 720&lt;BR /&gt;GB of data Which method should a data architect use to meet these requirements?&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;A. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only aggregated data for two years and use ODAG for transaction data&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;B. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only two years of data in an aggregated app and create a separate transaction app for&lt;BR /&gt;occasional use&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;C. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only two years of data and use best practices in scripting and visualization to calculate and&lt;BR /&gt;display aggregated data&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;D. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only aggregated data for two years and use Direct Discovery for transaction data&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Sat, 29 Aug 2020 10:34:45 GMT</pubDate>
    <dc:creator>amitavasen</dc:creator>
    <dc:date>2020-08-29T10:34:45Z</dc:date>
    <item>
      <title>Query</title>
      <link>https://community.qlik.com/t5/Water-Cooler/Query/m-p/1739624#M11699</link>
      <description>&lt;P&gt;&lt;SPAN class="fontstyle0"&gt;A company generates 1 GB of ticketing data daily. The data is stored in multiple tables Business&lt;BR /&gt;users need to see trends of tickets processed for the past two years. Users very rarely access the&lt;BR /&gt;transaction-level data for a specific date. Only the past two years of data must be loaded which is 720&lt;BR /&gt;GB of data Which method should a data architect use to meet these requirements?&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;A. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only aggregated data for two years and use ODAG for transaction data&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;B. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only two years of data in an aggregated app and create a separate transaction app for&lt;BR /&gt;occasional use&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;C. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only two years of data and use best practices in scripting and visualization to calculate and&lt;BR /&gt;display aggregated data&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class="fontstyle2"&gt;D. &lt;/SPAN&gt;&lt;SPAN class="fontstyle0"&gt;Load only aggregated data for two years and use Direct Discovery for transaction data&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Sat, 29 Aug 2020 10:34:45 GMT</pubDate>
      <guid>https://community.qlik.com/t5/Water-Cooler/Query/m-p/1739624#M11699</guid>
      <dc:creator>amitavasen</dc:creator>
      <dc:date>2020-08-29T10:34:45Z</dc:date>
    </item>
    <item>
      <title>Re: Query</title>
      <link>https://community.qlik.com/t5/Water-Cooler/Query/m-p/1739799#M11702</link>
      <description>&lt;P&gt;The rawdata-size from the database isn't equally with the data-size in Qlik. At first not all fields and records from the database are necessary and sensible in Qlik.&lt;/P&gt;&lt;P&gt;Quite often there are a lot of outdated fields, various record-id's from the tables and so on which are seldom needed (sometimes during the development to make some data-checks but not within the final dashboards). Further Qlik used a special storing-method by storing only distinct values within the symbol-tables and related bit-stuffed pointer within the data-tables. Depending on your data and requirements your rawdata of approximately 720 GB might end in 20 - 30 GB in Qlik which may depending on your environment workable as a single application.&lt;/P&gt;&lt;P&gt;If it's useful to aggregate the data depends on your biggest bottleneck in your environment and on the aggregation-rate of your records - means depending on the level of needed details 100 records may become 1 record and an aggregation will have some impact on the UI performance or it may remain about 50 records and it might not much noticable within the UI.&lt;/P&gt;&lt;P&gt;Therefore your question couldn't be answered in general else you need to do a careful testing in regard to the requirements and to the performance/possibilities of your environment to determine which approach is the most suitable for your case. Personally I would tend with C then B then A ...&lt;/P&gt;&lt;P&gt;- Marcus&lt;/P&gt;</description>
      <pubDate>Mon, 31 Aug 2020 09:43:46 GMT</pubDate>
      <guid>https://community.qlik.com/t5/Water-Cooler/Query/m-p/1739799#M11702</guid>
      <dc:creator>marcus_sommer</dc:creator>
      <dc:date>2020-08-31T09:43:46Z</dc:date>
    </item>
  </channel>
</rss>

