binärwerte vergleichen

sobi555

Benutzer
Beiträge
6
Hallo zusamen,

mich beschäftigt folgendes Problem:
Ich habe 3 Checkboxen, welche ein Filter für die MySQL abfrage darstellen. Wie überprüfe ich in MySQL ob der Datensatz die Anforderungen erfüllt?

Als Beispiel:
Checkbox 1 & 3 sind aktiv => 101 (binär) => 5 (dezimal)
Datensatz 1: 4 (dezimal) => 100 (binär) => ungültig
Datensatz 2: 7 (dezimal) => 111 (binär) => gültig

Liebe Grüße,


Simon
 
Werbung:
Hallo zusamen,

mich beschäftigt folgendes Problem:
Ich habe 3 Checkboxen, welche ein Filter für die MySQL abfrage darstellen. Wie überprüfe ich in MySQL ob der Datensatz die Anforderungen erfüllt?

Als Beispiel:
Checkbox 1 & 3 sind aktiv => 101 (binär) => 5 (dezimal)
Datensatz 1: 4 (dezimal) => 100 (binär) => ungültig
Datensatz 2: 7 (dezimal) => 111 (binär) => gültig

Liebe Grüße,


Simon

Ich weiß nicht, ob MySQL dafür passende Operatoren hat. In PG vielleicht so:

Code:
test=*# select B'100' | B'101' = B'111';
 ?column?
----------
 f
(1 row)

Time: 0,156 ms
test=*# select B'111' | B'101' = B'111';
 ?column?
----------
 t

Also das, was Du hast, bitweise ODER mit dem Filter, und prüfen, ob alle Bits gesetzt sind. Aber ich fürchte schon wieder, daß MySQL auch das nicht kann.
 
Guten morgen akretschmer,

danke für deine Antwort, auch wenn mir der Inhalt nicht wirklich gefällt... ^^ ;) Mir wäre es lieber du hättest gesagt: "so geht es!" :D
PG sagt mir gar nichts, ich arbeite mit PHP :)
Bei der Abfrage kann ich einbauen: "WHERE bin_datenbank>=bin_checkboxen" - soviel ist klar, dass der Wert in der DB mindestens so groß sein muss, wie der Wert der Checkboxen.

Nun, mal weiter suchen ob es einen anderen Weg gibt als: "alle Datensätze auslesen und dann mit PHP das überprüfen" - Ich freu mich weiter über spannende Gedankenanstöße! :)

LG
 
Guten morgen akretschmer,

danke für deine Antwort, auch wenn mir der Inhalt nicht wirklich gefällt... ^^ ;) Mir wäre es lieber du hättest gesagt: "so geht es!" :D
PG sagt mir gar nichts, ich arbeite mit PHP :)

PG steht für PostgreSQL. Das ist, im Gegensatz zu MySQL, eine funktionierende Datenbank ;-)

Bei der Abfrage kann ich einbauen: "WHERE bin_datenbank>=bin_checkboxen" - soviel ist klar, dass der Wert in der DB mindestens so groß sein muss, wie der Wert der Checkboxen.

'Mindestens' so groß ist, denke ich mal, nicht richtig.

Wenn Du 2 oder mehr Informationen ein einem Feld speicherst, und das tust Du, machst Du schon was falsch, weil das ist nicht normalisiert. Dazu kommt, daß Deine 'Datenbank' offenbar dazu keine passenden Funktionen hat. Wie gesagt, in PG hat man dazu neben passenden Datentypen (Bitfelder) auch passende Funktionen. In PG gibt es auch weitere Datentypen, die komplexer aufgebaut sind, z.B. RANGE-Typen - und auch passende Funktionen, und man kann selber eigene komplexe Datentypen und Funktionen definieren. Mit MySQL lebst aber quasi noch im Mittelalter der DB-Welt, da geht das alles nicht.
 
ja, der Wert liegt als integer vor.
Gut, ich bin nicht soooo fit in MySQL. Wie wandel ich das denn um??

SELECT CAST( attribute AS BINARY( 5 ) )


Das bringt noch nicht den gewünschten wert... :(
 
SELECT CONV( 5, 10, 2)

wohoooo... so weit war ich noch nicht! :) Gut, und wie vergleiche ich jetzt die Kette Bitweise?!?! - der Bit der Checkbox muss immer größer sein als der Bit des Datensatzes. Wenn der Datensatzbit größer ist, dann ist das ja egal!
 
täuscht das, oder könnte so die Lösung aussehen:

SELECT CONV( 21, 10, 2 ) AS att, CONV( 16, 10, 2 ) AS cbx
FROM gasthaus
HAVING att >= cbx
LIMIT 0 , 30
 
Wenn das mit dem conv() so läuft würde ich eher sagen:
Code:
SELECT    *
FROM    gasthaus
WHERE    CONV( 21, 10, 2 ) > CONV( 16, 10, 2 )
LIMIT    0 , 30
 
täuscht das, oder könnte so die Lösung aussehen:

SELECT CONV( 21, 10, 2 ) AS att, CONV( 16, 10, 2 ) AS cbx
FROM gasthaus
HAVING att >= cbx
LIMIT 0 , 30

Ob das läuft oder nicht - ich würde davon abraten. Das wird, bei einer größeren Tabelle, voll die Performance-Bremse. MySQL kann keine funktionalen Indexe, das zwingt also immer zu einem vollen Tablescan und für jeden Datensatz ist diese Konvertierung zu machen und das ganze zu prüfen.

Normalisiere das, und Deine Abfragen werden a) einfacher und b) schneller. Oder nutze c) halt PG, was passende Datentypen, Funktionen und Indexe hat.
Oder d) normalisiere UND nutze PostgreSQL ;-)
 
akretschmer, PostgreSQL ist leider raus! ;-) Hab ich nicht, kenn ich nicht... aber da du dich dort scheinbar sehr gut auskennst, kannst du mir bestimmt sagen, ob ich PG auch mit TYPO3 nutzen kann!??

Gut, zur geschwindigkeit:
es ist doch deutlich schneller, wenn ich "WHERE spalte1 = 1" abfrage, als WHERE spalte1 = 1 AND spalte2 = 1 AND spalte3 = 1 AND spalte4 = 1 AND spalte5 = 1 AND spalte6 = 1

Zumindest hatte ich im MyPHPAdmin hier riesengroße Unterschiede:
Erste Abfrage: 0.0005 Sekunden
Zweite Abfrage: 0.1211 Sekunden
Oder wie sehen das andere!?? - Es ist doch besser, weniger Bedinungen zu stellen...

Ob ein binärwert in einem anderen binärwert enthalten ist nutze ich nun folgendes:
SELECT CONV( lastversion, 10, 2 ) - CONV( 18, 10, 2 ) AS cbx
FROM cache_extensions
HAVING cbx NOT LIKE '%9%'
LIMIT 0 , 30


Erklärung:
basiswert in der DB: 21 => 10101
suchwert in der CBX: 18 => 10010
=> das heißt, der datensatz darf nicht ausgegeben werden! 10101-10010 = 91
=> sobald eine neun drin ist, wurde von einer null eine eins abgezogen => ungültig
Wert 17: 10001 würde als resulat 100 liefern => gültig
 
Werbung:
akretschmer, PostgreSQL ist leider raus! ;-) Hab ich nicht, kenn ich nicht... aber da du dich dort scheinbar sehr gut auskennst, kannst du mir bestimmt sagen, ob ich PG auch mit TYPO3 nutzen kann!??

Laut Google scheint es zu gehen.

Gut, zur geschwindigkeit:
es ist doch deutlich schneller, wenn ich "WHERE spalte1 = 1" abfrage, als WHERE spalte1 = 1 AND spalte2 = 1 AND spalte3 = 1 AND spalte4 = 1 AND spalte5 = 1 AND spalte6 = 1

Depends. Hier sollte man das Explain befragen. Wie immer.

Ob ein binärwert in einem anderen binärwert enthalten ist nutze ich nun folgendes:
SELECT CONV( lastversion, 10, 2 ) - CONV( 18, 10, 2 ) AS cbx
FROM cache_extensions
HAVING cbx NOT LIKE '%9%'
LIMIT 0 , 30

Das Having irritiert mich hier, Having verwendet man nur bei Aggregation/Gruppierung. Vermutlich ein weiterer Bug von MySQL. Du machst das vermutlich, um auf den Alias zugreifen zu können, was mit Where nicht ginge. Syntaktisch ist es aber ein klarer Verstoß gegen SQL-Syntax. Egal, ein Explain würde Dir hier zeigen, daß Indexe da nicht möglich sind. Bei einer Tabelle mit 2 Einträgen mag das egal sein, wenn es mal 200 Millionen sind nicht mehr.
 
Zurück
Oben