[MySQL] tekst tussen "[" "]" uit records filteren

[Mschamp]

Dag mede-tweakers,

Ik heb een tabel met een kolom waarin tekst ingegeven wordt (zie onderstaande voorbeelden).

Nu zou ik graag een query opstellen waarin in de tekst tussen de [ ] als resultaat krijg.
Tussen de haken zouden trefwoorden komen, die ik dan in een dropdownbox wil plaatsen om zo te kunnen selecteren als zoekfunctie.

Voorbeeld records:
[Minimale lengte] 700 of zaagt in tafel
[Minimale lengte] 700 of zaagt in tafel
O:1,0=>1,3 M:0,6=>0,9 B:0,9=>1,2 B2:1,2=>1,5
Was inderdaad niet diep genoeg
[Veiligheid] om niet in de tafel te frezen liet 0,6 mm teveel staan.
Afstand [scharnier]=>buitenrand [kassement]
Computer gestart zonder [UPS] [moet vervangen worden]

Graag zou ik als resultaat hebben:
Minimale lengte
veiligheid
kassement
UPS
moet vervangen worden

In deze voorbeelden zijn er maximaal 2 trefwoorden per record, maar ik zou het graag zonder limiet hebben, dus de query zou ook moeten werken bij 3,4,5,... trefwoorden per record.
Alvast bedankt

[Verwijderd]

Ik denk dat je aan je datamodel en applicatie moet gaan sleutelen, want dit is geen werk dat een database voor je moet doen. Je moet ofwel je data gaan indexeren en mappen naar zoekwoorden, of je moet je datamodel aanpassen zodat het meer geschikt is om in te zoeken.

[NMe]

Langs deze weg ga je inderdaad nul komma nul performance voor elkaar krijgen. Afhankelijk van je DBMS kán het vast allemaal wel, bijvoorbeeld met regular expressions maar die zijn in gevallen als deze zowel foutgevoelig als traag. Je bent hier tekst met doorzoekbare tags aan het verwarren en dat levert alleen maar problemen op.

Wat je wil hebben: deze tabel min of meer houden zoals hij is maar dan zonder die woorden tussen brackets, en een nieuwe tabel voor de tags waar je op wil kunnen zoeken. De twee tabellen koppel je vervolgens met een koppeltabel. Schoolvoorbeeldje van normalisatie.

[Mschamp]

OK,
Bedankt alvast voor de tips.
Dus best een gescheiden tabel voor de trefwoorden, en de gewone tekst.
Ik dacht op deze manier het aantal tabellen te beperken, maar dus toch beter opsplitsen.

[Fish]

database in database = nooit handig

dud idd goed aan je model werken

[ Voor 33% gewijzigd door Fish op 16-07-2014 22:02 ]

[laurens0619]

fish schreef op woensdag 16 juli 2014 @ 22:01:
database in database = nooit handig

dud idd goed aan je model werken

Oneens, overnormaliseren kost weer performance. In sommige situaties is het prina een xml structuur in een veld op te slaan. Vuistregel is: moet ik er op kunnen zoeken of uit subset data selecteren

[NMe]

Mschamp schreef op woensdag 16 juli 2014 @ 21:58:
Ik dacht op deze manier het aantal tabellen te beperken, maar dus toch beter opsplitsen.

Het aantal tabellen beperken mag nooit een argument zijn voor welke beslissing dan ook. Meerdere tabellen zijn voor je database geen enkel probleem. Tabellen joinen met de juiste indexen ingesteld stelt ook niks voor. Het is juist dit soort "optimalisatieslagen" dat uiteindelijk een aanslag oplevert op je performance.

laurens0619 schreef op woensdag 16 juli 2014 @ 23:23:
[...]

Oneens, overnormaliseren kost weer performance. In sommige situaties is het prina een xml structuur in een veld op te slaan. Vuistregel is: moet ik er op kunnen zoeken of uit subset data selecteren

Of je aan het overnormaliseren bent merk je vaak pas achteraf en zelfs dan klinkt het me héél vreemd in de oren om data in XML-formaat in de database op te slaan tenzij je er verder geen enkele bewerking meer op hoeft te doen... Wat normaliseren betreft zijn er na de derde normaalvorm nog een paar vormen die speciaal bedoeld zijn om waar nodig weer een stukje te denormaliseren om performanceredenen. Premature optimization is een van de grootste kwaden in onze branche.

[BoringDay]

xml in database opslaan is niet zo vreemd, bijvoorbeeld aan een template waar je al een object voor hebt die het kan inlezen en wegschrijven. Dan is het onzinnig daarvoor apart tabellen voor te maken.

[NMe]

BoringDay schreef op donderdag 17 juli 2014 @ 07:16:
xml in database opslaan is niet zo vreemd, bijvoorbeeld aan een template waar je al een object voor hebt die het kan inlezen en wegschrijven. Dan is het onzinnig daarvoor apart tabellen voor te maken.

Nogmaals: dat is alleen handig en gangbaar wanneer je geen selectie uit de informatie hoeft te maken in je query, dus als je de XML direct in die vorm nodig hebt. Als vergelijkbaar voorbeeld: op GoT worden je berichten opgeslagen in de vorm waarin je ze zelf getikt hebt (RML) en in de geparsete vorm (HTML) voor snelle weergave. Hoe de zoekfunctie precies in elkaar zit weet ik niet, maar die zal ongetwijfeld alle posts indexeren zodat je kan queryen op een andere tabel met sleutelwoorden. De tekst zelf wordt dus nooit in de query geparset of doorzocht.

[CyberJack]

NMe schreef op donderdag 17 juli 2014 @ 11:31:
[...]

Nogmaals: dat is alleen handig en gangbaar wanneer je geen selectie uit de informatie hoeft te maken in je query, dus als je de XML direct in die vorm nodig hebt.

Voor MySQL (en daar ging het in dit topic over) klopt dit, maar PostgreSQL heeft bijvoorbeeld wel de mogelijkheden om data uit een xml of json objecten te gebruiken in een query. Je kan ook alleen bepaalde delen uit een xml opvragen (en dus niet het gehele document terug krijgen).

http://www.postgresql.org/docs/9.1/static/functions-xml.html
http://www.postgresql.org/docs/9.4/static/datatype-json.html

Voor deze vraag blijft het scheiden van tekst en tags natuurlijk het beste, maar er zullen zeker toepassingen zijn waar je alleen bepaalde data uit een xml of json object wilt gebruiken zonder dit in je code te hoeven doen. (of er op wilt zoeken)

[NMe]

Voor zover ik kan vinden hebben ook die last van het feit dat je indexen niet (volledig) gebruikt kunnen worden waardoor het een potentiële bottleneck kan zijn of een potentiële bottleneck in een puur relationele situatie erger kan maken.