Platzhalter in der Datenbank

[resoucer]

Hallo,

mal eine Frage bzgl. Der DB.

Ich habe in einer DB z.B. folgenden Spalteninhalt

vox219-4304(5,6)-134

wenn ich jetzt eine DB abfrage mache die wie folgt endet

... like '%43045%'
soll er mit den o.g. Treffer ausgeben
genauso wie wenn ich
... like '%43046%'
angebe.

Evtl. muss ich den Spalteninhalt auch ändern, aber ich bin mir nicht sicher wie ich das am Besten lösen kann.

Es kann dann z.b. auch in der DB stehen

vox219-430(50,51,52)-134
dann soll er per
... like '%43050%'
... like '%43051%'
... like '%43052%'

auch den einen Treffer finden.

 

[Skelos]

es dürfen auch mehr als 2x% eingefügt werden

=> WHERE spalte LIKE '%430%51%'

 

[ice-breaker]

Wie wäre es die Daten gleich richtig zu speichern, so dass man diesen Firlefranz nicht braucht?

 

[resoucer]

Wie wäre es die Daten gleich richtig zu speichern, so dass man diesen Firlefranz nicht braucht?

ja also das mit dem Like ist etwas kompliziert da man nicht genau weiß wann man einen split machen muss.

Nach 3 zeichen oder nach 2 zeichen?

Beispiel
43099
43100

---

Das mit den richtig speichern währe super aber wie genau? Meinste einfach alle Artikelnummern dort komplett rein schreiben?

 

[Skelos]

ja, entweder man speichert die Daten strukturiert ab (dabei dürfen auch mehrere Datensätze für ein Produkt etc. anfallen => 3. Normalform macht eh kaum jemand => Datenredundanzen sind ok) oder man macht einen eindeutigen Seperator, so dass man auch nach LIKE '%430%,31,%' suchen kann <= ist die unsaubere Noob-Lösung !

 

[Sebbo]

Es kann dann z.b. auch in der DB stehen

vox219-430(50,51,52)-134
dann soll er per
... like '%43050%'
... like '%43051%'
... like '%43052%'

auch den einen Treffer finden.

dann brauchst du mehrere Likes, alle oder verknüpft:
like '%430(51)%'
like '%430(51,%'
like '%430(%,51,%'
like '%430(%,51)%'

Warum? Weil es ja auch sein könnte, dass es den folgenden Eintrag gibt (zumindest nehme ich das mal an):
vox219-430(50,151,52)-134
und das darf natürlich nicht matchen.

Da es sich hier um mehrere Einträge handelt, solltest du eine extra Tabelle dafür machen, in die du dann alle Einträge richtig ausschreibst. Dann ist das like ganz einfach und du hast halt einen zusätzlichen Join.

 

[tobomator]

like ist doch nur ein Werkzeug um einen "Teilstring" Match zu erbringen.

Name = [ Meier, Meinhard, Meinhold, Mars, Martens, ... ]

like Mei findet eben alle die mit Mei beginnen
like Mei%d sollte entsprechend aggieren
etc

Wer in einer DB keine Redundanz mag, sollte nicht anfangen die Daten zu verknappen und sie so abzuspeichern, weil die Logik auf soetwas nicht vorbereitet wurde. MySQL kann aktuell sowas nicht.
Vll die neuen Modelle wie das Machwerk von den Apache Leuten.
Allerdings haben Datenbanken immer ein Normalform Gedanken, zwecks Minimierung der Redundanz.
Ansonsten reicht jede Textdatei aus und ein Script drüber laufen lassen mit entsprechendem Parser ansatz eines Regulären Ausdrucks.
Dazu würde sich ein Linux Derivat mit fgrep, egrep und dergleichen am einfachsten eignen ohne auch nur eine Datenbank zu benötigen.

Aber für jeden Anlass gibts ja was, doch hier wohl nicht

 

[Skelos]

Ansonsten mag resourcer nochmal genauer sagen worum es bei den Daten geht etc. - dann kann man einen besseren Vorschlag machen!

 

[transversalis]

resoucer versucht wohl so ein umgekehrtes REGEXP.

Normalerweise hat man ja ein
... WHERE spalteninhalt REGEXP ausdruck ...
und resoucer versucht ein
... WHERE ausdruck REGEXP spalteninhalt ...

 

[ice-breaker]

Ressourcer hat erstmal gegen die 1. NF verstoßen und mehrere Daten in einen Wert einer Spalte gespeichert. Um es auch schön kompliziert zu machen haben die Daten dann auch noch eine Präfixkodierung, welche ihm jetzt das Genick bricht, da er die Daten nimmer so einfach auslesen kann.

 

[transversalis]

Ressourcer hat erstmal gegen die 1. NF verstoßen

Das kann man so gar nicht sagen, ohne das Datenmodell zu kennen. Beinhaltet die Spalte per Definition z.B. ein "matching pattern", so handelt es sich tatsächlich um einen atomic value ( der pattern ist dann atomic, nicht der Wertebereich, den er repräsentiert ).
Grundsätzlich kann man sogar sagen, dass alles, was in einer relationalen Tabelle gespeichert wird, immer die 1NF erfüllt, weil es technisch gar nicht möglich ist, Wiederholgruppen abzuspeichern. Gegen die 1NF kann daher nur "auf dem Papier" verstossen werden.

 

[Sebbo]

Das kann man so gar nicht sagen, ohne das Datenmodell zu kennen. Beinhaltet die Spalte per Definition z.B. ein "matching pattern", so handelt es sich tatsächlich um einen atomic value ( der pattern ist dann atomic, nicht der Wertebereich, den er repräsentiert ).

Aber die Speicherung der Daten sollte (unabhängig von irgendwelchen Normalformen) so passieren, dass sie zur Anwendung passt. Und das scheint hier nicht der Fall zu sein. Ansonsten gäbs das Problem ja gar nicht.

 

[transversalis]

Das ist richtig, Sebbo.
Und damit sind wir wieder bei der Ausgangsfrage von resoucer angekommen, der ja selbst schon die Art der Speicherung in Frage gestellt hat.

Evtl. muss ich den Spalteninhalt auch ändern, aber ich bin mir nicht sicher wie ich das am Besten lösen kann.