https://www.insidesql.org/blogs/cmu/?disp=comments de-DE http://backend.userland.com/rss 60 Fri, 04 May 2012 12:40:34 +0000 cmu c2014@https://www.insidesql.org/blogs/ Vielen Dank für den Hinweis. Ich war auf umgekehrtem Wege zu dem Thema gekommen, da ich die Abonnements vom SSRS auswerten wollte. Es gibt immer wieder Hersteller, die auf solchem Wege ihre Informationen codieren, bzw. verschleiern. Microsoft gehört bei den Reporting Services leider auch in diese Kategorie. https://www.insidesql.org/blogs/cmu/sql_server/bitmaskierung#c2014 Fri, 04 May 2012 12:31:44 +0000 Holger Schmeling c2013@https://www.insidesql.org/blogs/ Clever. Eine Warnung vermisse ich aber leider und ergänze sie deshalb. So verlockend das nämlich auf den ersten Blick erscheinen mag, handelt es sich doch letztlich um eine Verletzung der ersten Normalform, die ja besagt, dass jedes Attribut atomar sein soll. In der Regel ist es keine gute Idee, diese Richtlinie zu verletzen. Wenn man so etwas macht, dann ist die Verwendung von Funktionen zur Zerlegung der Information in die atomaren Bestandteile ein natürlicher Ansatz, der ebenfalls nicht ganz frei von Problemen ist. Bevor man sich versieht, stehen diese Funktionsaufrufe dann in Prädikaten. Der Optimierer hat dann keinerlei Möglichkeit, eine vernünftige Kardinalitätschätzung durchzuführen und der Ausführungsplan ist in der Regel suboptimal. Eine Index auf so einer Bit-codierten Spalte ist ebenfalls wenig sinnvoll. Die Verwendung von benutzerdefinierten Funktionen in der SELECT-Liste ist ein weiterer Performance-Killer. Also bitte mit Vorsicht verwenden. https://www.insidesql.org/blogs/cmu/sql_server/bitmaskierung#c2013