<?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 Too many Flags in QlikView</title>
    <link>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199782#M58568</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I'm confused by the idea of "too many flags in the Fact table". What do you mean by too many? There's no practical limit to the number of fields on a table in QlikView, right? If every flag is useful to you, then in what sense do you have too many? Are you assuming that you're wasting memory on duplicate information? QlikView's compression will tend to keep that from being a problem. Is it something else?&lt;/P&gt;&lt;P&gt;Anyway, as Oleg says, you can simply test it. Then you'll know &lt;EM&gt;for certain&lt;/EM&gt; for your own data and charts, where the rest of us can only theorize. I'm &lt;EM&gt;guessing&lt;/EM&gt; that you'll be best off leaving your flags where they are, but it's no more than an educated guess. When you have an actual problem it is definitely worth testing alternatives. Experts can be wrong, and rules of thumb can lead you astray in specific cases.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 09 Apr 2010 22:58:48 GMT</pubDate>
    <dc:creator>johnw</dc:creator>
    <dc:date>2010-04-09T22:58:48Z</dc:date>
    <item>
      <title>Too many Flags</title>
      <link>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199778#M58564</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I have an application, which has too many flags in the Fact table.&lt;/P&gt;&lt;P&gt;All these flags can be moved to a different dimension table , which contains lot less number of rows than Fact table.&lt;/P&gt;&lt;P&gt;Will my performance change , when comparing the results between "Flags in Fact table" &amp;amp; "Flags in Dimension".?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 25 Sep 2009 21:23:25 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199778#M58564</guid>
      <dc:creator />
      <dc:date>2009-09-25T21:23:25Z</dc:date>
    </item>
    <item>
      <title>Too many Flags</title>
      <link>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199779#M58565</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The best performance is when the flags are in the same logical table with measures. That means it may go down if you move flags out of the Fact table. How much, and if it is of any significance in your case, I can't tell.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 26 Sep 2009 06:26:17 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199779#M58565</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2009-09-26T06:26:17Z</dc:date>
    </item>
    <item>
      <title>Too many Flags</title>
      <link>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199780#M58566</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The flags should be kept in dimension if possible, which enables the engine to work with smaller amount of data rather than scanning through each row in fact table.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Apr 2010 18:49:37 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199780#M58566</guid>
      <dc:creator />
      <dc:date>2010-04-09T18:49:37Z</dc:date>
    </item>
    <item>
      <title>Too many Flags</title>
      <link>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199781#M58567</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I hope the last observation is based on QlikView experience, because everything I know about QlikView tells me the opposite.&lt;/P&gt;&lt;P&gt;The specific answer can be different in different situations, but ... IN MOST CASES, keeping the flags in the Fact table should generally improve performance - I totally agree with Michael.&lt;/P&gt;&lt;P&gt;The only way to know in the particular case is to try it out and post the benchmark results here.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Apr 2010 21:26:04 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199781#M58567</guid>
      <dc:creator>Oleg_Troyansky</dc:creator>
      <dc:date>2010-04-09T21:26:04Z</dc:date>
    </item>
    <item>
      <title>Too many Flags</title>
      <link>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199782#M58568</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I'm confused by the idea of "too many flags in the Fact table". What do you mean by too many? There's no practical limit to the number of fields on a table in QlikView, right? If every flag is useful to you, then in what sense do you have too many? Are you assuming that you're wasting memory on duplicate information? QlikView's compression will tend to keep that from being a problem. Is it something else?&lt;/P&gt;&lt;P&gt;Anyway, as Oleg says, you can simply test it. Then you'll know &lt;EM&gt;for certain&lt;/EM&gt; for your own data and charts, where the rest of us can only theorize. I'm &lt;EM&gt;guessing&lt;/EM&gt; that you'll be best off leaving your flags where they are, but it's no more than an educated guess. When you have an actual problem it is definitely worth testing alternatives. Experts can be wrong, and rules of thumb can lead you astray in specific cases.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Apr 2010 22:58:48 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Too-many-Flags/m-p/199782#M58568</guid>
      <dc:creator>johnw</dc:creator>
      <dc:date>2010-04-09T22:58:48Z</dc:date>
    </item>
  </channel>
</rss>

