performance

[chrissi11]

ahaa..ok.das wusst ich ned..dann schau ich da gleich mal nach..danke

[wahsaga]

wie bekomme ich denn raus wieviel speicher diese option in anspruch nimmt.

In dem du im Handbuch nachliest - das hat schliesslich ein extra Kapitel über den Speicherplatzbedarf der einzelnen Datentypen.

[chrissi11]

hää? sry..jetzt versteh ich garnix mehr..
also nochmal von vorn..ich kann mich nur schrittweise in die materie einarbeiten.

mir ging es ja letztendlich um den speicherplatz.
wenn ich die datensätze zum auslesen der fragen in eine eigene tabelle lege, scheint mir das so am sinnvollsten.

meine letzte frage war, wie ich die felder für die tabelle belege wenn ich hier nur mit nullen und eines arbeite.
nun hab ich da beim anlegen der tabelle gesehn das es dort die option binary gibt.
wie bekomme ich denn raus wieviel speicher diese option in anspruch nimmt. ich will ja im enteffekt nur 1 bit pro frage speichern?!

[Quetschi]

Achso - hab dein Post falsch interpretiert.
Maske: .... ist die Ausgangsposition und dann zeigst den Weg zur Speicherung im VarChar.

EDIT:
Und ja - der normale Weg erscheint mir hier auch am sinnvollsten - das hatte ich auch schon weiter vorne erwähnt.

[AmicaNoctis]

Aber wie willst du Vorschlag 1 und 2 hinbekommen?

Was meinst du mit Vorschlag X?

Mein Vorschlag war übrigens die N:M-Relation und ich würde es immer noch damit machen. Kann aber sein, dass ich in diesem Thread trotz mehrmaligen Lesens irgendetwas falsch verstanden hab.

[Quetschi]

Maske: 0110010100101010 ...
Hex: 652a ...
Text: e* ...

Vorschlag 3 ist ok - aber umständlich.

Aber wie willst du Vorschlag 1 und 2 hinbekommen?

[AmicaNoctis]

Wie setzt du mit mit einem z.B. VarChar(255) eine Maske mit 2040-Bit Breite um?

Maske: 0110010100101010 ...
Hex: 652a ...
Text: e* ...

Wobei man dann eher varbinary nehmen sollte.

[Quetschi]

Ja, glaub das war damals schon max. 256 Byte (255 Zeichen + 1Byte für Längenangabe) - was ich mich grad frage: Wie setzt du mit mit einem z.B. VarChar(255) eine Maske mit 2040-Bit Breite um?

Mittlerweile bin ich mir grad mal wieder bei gar nix mehr sicher - war auch bis eben davon überzeugt SET könnte 255 Werte kombinieren, aber das ist ja natürlich Quatsch - das Feld fasst ja max 8 Byte.

Vielleicht sollte ich doch lieber einfach nur den Rasen mähen

EDIT:
Post inhaltlich editiert.

Vielleicht kannst du die Diskussion auch aus dem Thread ausgliedern um den TO nicht zu verunsichern.

[onemorenerd]

Uh, MySQL 3.23 ist wirklich schon sehr lange her. Aber war varchar nicht damals schon 255 Byte breit? Das sind auch schon 2040 Bit … mehr Möglichkeiten, etwas zum ersten Mal zu machen, sollten in einer App nicht drin sein.
Übrigens ist SET limitiert auf 64 Werte, kommt also überhaupt nicht in Frage, egal wie schön man damit suchen könnte.

[Quetschi]

Aus irgendeinem Grund hab ich noch immer die max-Werte von mysql3.23 im Kopf

Bei FIND_IN_SET ging es mir nur darum, dass man bequem damit suchen kann - natürlich kann man ja auch den kompletten Inhalt einfach auslesen

[onemorenerd]

@Quetschi: Varchar fasst 524280 Bits. Wenn das nicht reicht, ist die Applikation zu kompliziert.
FIND_IN_SET ist eine SQL-Funktion. Du willst also jeden Wert einzeln aus der DB fischen? Warum dann eigentlich eine SET-Spalte und keine eigene Tabelle?
Für FIND_IN_SET musst du zwar keine Position eines Bits wissen, aber sehr wohl den Wert, den du eigentlich suchst. Das meinte ich mit "nimmt sich nichts".

[Quetschi]

@onemorenerd

obwohl ich eine Schwäche für derartige Vorgehensweisen(*) habe muss ich sagen, dass im hier gezeigten Fall ganz klar die Vorteile der klassischen "Lehre" überwiegen. Weiß man heute wirklich ob es bei 100 Tipps bleibt? Was ist wenn die Anzahl der Tipps irgendwann die Möglichkeiten von VarChar übersteigt? Zusätzliches VarChar? Dann muss wieder der Code angepasst werden. Einfach sauber normalisieren und muss keine Gedanken mehr daran verschwenden was in 5 Jahren ist.

*)
Die logischste Umsetzung dieser Vorgehensweise stellt in meinen Augen ein SET-Feld dar, da ich damit auch mal bequem mit FIND_IN_SET abfragen kann und mich nicht um Sachen wie z.B. korrekte Position des gesuchten Bits kümmern muss, 255 Kombinationsmöglichkeiten hat man damit ebenso, ich kann die Bits sozusagen "frei benennen" und weniger Speicher braucht es auch (max. 8 Byte vs. max. 256 Byte bei VarChar).
In meinen Augen spricht da nichts dafür sich mit VarChar das Leben schwer zu machen.

[onemorenerd]

Welche Fragen? Welches Feld? Beschreibe deine Gedanken halbwegs nachvollziehbar!

[chrissi11]

naja, es geht ja auch um die fragen..so wie du beschrieben hast mit dem tabellenaufbau hatte ich es auch vor, davon mal abgesehn.
mir gehts ja nur um die 1 und die nullen.so ganze fragen werden da nicht reinkommen. das handle ich dann mit smarty aus.
gut, ich werde es mal so probieren und berichten wie groß die tabelle nach einem monat ist. probieren geht über studieren.

danke euch fürs mitdenken

achso..das feld werd ich mit binäry belegen? oder werden da bytes statt bits gespeichert?

[AmicaNoctis]

Warum denn nicht mit varchar?

In diesem Fall ja, aber ich dachte, es geht um die Tipps. Dahingehend ist mir die ganze Anfrage nicht vollends klar geworden.