Bitweise Prüfung eines Int

[Jelly]

Ich habe ein kleines Problem mit einer bitweisen Prüfung unter T-SQL.

Ich habe eine Nachschlagtabelle, bei der die Spalte x (vom Typ BigInt), die nur Werte annehmen darf, die in der bitweisen Darstellung nur ein Bit einnehmen, also Werte, die darstellbar sind als 2^n. Auf dieser Seite habe ich dazu auch den entsprechenden mathematischen Ausdruck gefunden:

Code:

(x & (x-1)) = 0

Das wollte ich als Constraint in meiner Tabellendefinition so angeben, was T-SQL auch erstmal so nimmt. Wenn ich mir nach dem Speichern der Tabelle jedoch den Constraint nochmal anschaue, wird daraus

Code:

(x & x - 1 = 0)

was aber falsch ist. Es werden mir die Klammern gelöscht.

Wie kann ich diese Prüfung denn nun vielleicht anders durchführen ?

[marabu]

Hallo Tom,

im vorliegenden Fall speichert man eher den Exponenten zur Basis 2 als das Ergebnis. Vielleicht kannst du das ja noch ändern.

Freundliche Grüße

[Jelly]

Hm, das ist vielleicht auch eine Idee. Aber ums mir mal bestätigen zu lassen, as für meinen Fall das einfachste ist.

Diese Tabelle dient sozusagen als Nachschlagtabelle. In der referierten Tabelle soll eine Art Multichoice möglich sein. Ich wollte vermeiden, direkt für jede Option ein eigenes Feld in der Tabelle anzulegen, sondern will mit Bitoperationen mir meine Multichoice Wahl darstellen. Dadurch bleibe ich, denke ich, flexibler wenn Optionen hinzukommen. Da es definitiv nie mehr als 64 werden, würde eine solche Darstellung also passen.

Ich habe also die Möglichkeit, nur den Exponenten zu speichern (1,2,3,...,64) oder direkt die entsprechende numerische Darstellung (1,2,4,8,16,...2^64).

In der Referenztabelle ist klar, was ich zu speichern habe (5 entspräche Bit 0 und Bit 2 gesetzt).

In welcher Darstellung bleib ich denn nachher am flexibelsten, will ich die 5 wieder aufsplitten und z.B. in einer CheckedListBox darstellen?

[marabu]

Angenommen ich habe folgende Tabellen:

Code:

ANSWERS (ID, TXT, QST_ID, SEQ)
QUESTIONS (ID, TXT, ANS_CODE)

In SEQ trage ich für jede QST_ID fortlaufende Nummern (0..63) ein - die Exponenten. Eine lückenlose Vergabe ist vernünftig, aber nicht notwendig.

Willst du später prüfen, ob eine gültige Antwort markiert wurde, dann helfen dir POWER(2, SEQ) und ein bitweises AND mit ANS_CODE.

Wozu ein CHECK?

Du hast nicht wirklich 64 Choices per Question?

[Jelly]

Zitat:

Zitat von marabu

Du hast nicht wirklich 64 Choices per Question?

Nein. Es wird viele Fragen geben, und ich werde für jede einzelne Frage so eine Nachschlagtabelle zimmern müssen. Mehr als 6-8 Records wird es wohl kaum geben.

Zitat:

Zitat von marabu

Wozu ein CHECK?

Ich muss ja, wenn ich die ausgewählten Antworten laden will, irgendwie leicht rausfinden, ob eine Antwort gecheckt ist oder nicht. Am liebsten mit einem SQL Befehl...

Ich habe mittlerweilen deine Idee umgesetzt, also dass ich nur den Exponenten wähle, und das klappt hervorragend... Und mit folgendem Select kriege ich dann auch gleich in einem Ruck alle Antworten zurück, die für eine Frage möglich sind, unter Angabe ob die Antwort gecheckt ist oder nicht. Damit wird eine Darstellung z.B. in einer CheckedListBox zum Kinderspiel (ich habe mich dabei an deine Tabellenstruktur gehalten wie du sie im Beispiel angegeben hast):

SQL-Code:

select q.Id, a.Txt
  ip.InfosPersonellesId, me.Description
from 
  Questions q
right outer join 
  Answers a on (Power(2, a.SEQ) & q.ANS_CODE) = Power(2, a.SEQ) and q.Id = @Id
order by
  a.Txt

Dies liefert mir für die Frage @Id alle Antwortmöglichkeiten. Ist die Antwort gecheckt, so ist die q.Id Spalte nicht null. Ist sie nicht gecheckt, dann NULL.

Vielleicht hilft der Join ja mal einem hier bei einem analogem Problem.

Danke Achim..

EDIT: Fehler im Select behoben...