[MySQL] Onderdeel van een string selecteren

[Verwijderd]

Beste,

Ik wist niet precies hoe ik dit probleem moest omschrijven, dus excuses voor de onduidelijke topic.

Ik heb een tabel met categoriën als volgt ingedeeld:

WERKPLAATS-INRICHTINGEN->WERKBANKEN->WERKBANKEN
GEREEDSCHAPPEN->SLAG EN STOOT->SLAGCIJFERS
MAGAZIJN INRICHTINGEN->MACHINEKASTEN

En daar nog een hele boel van.

Ik wil een query uitvoeren, die de eerst categorie (dus het eerste, voorste deel van de ->) selecteerd, maar dan 1x. Iets met DISTINCT denk ik, maar hoe selecteer ik het eerste deel (voor de eerste ->) in een query?

Ik hoop dat het duidelijk is. Mochten er nog vragen zijn, hoor ik ze graag.

[StephanVierkant]

Het is me niet echt duidelijk wat je nu wilt, en je categorieën zijn ook lekker onduidelijk neergezet. Als je gebruik maakt van de opsommingstekens, wordt het al een stukje duidelijk voor ons.

[Sjoerd]

Je wilt dus alles voor -> ophalen?

[P.O. Box]

Verwijderd schreef op maandag 07 januari 2008 @ 13:14:
Ik wist niet precies hoe ik dit probleem moest omschrijven, dus excuses voor de onduidelijke topic.

excuses aanvaard, maar probeer toch maar wat duidelijker te zijn, want hier snapt geen hond iets van...

kopieer bijv. eens wat tabelstructuren en tabeldata om te beginnen... en neem de tijd voor je OP ipv je bij voorbaat in te dekken voor een onduidelijk topic

[Creepy]

Hoe heb je je categorieren opgeslagen? Letterlijk "GEREEDSCHAPPEN->SLAG EN STOOT->SLAGCIJFERS" als platte tekst? Of heb je nog een andere tabel indeling die je nu achterwege laat?

Als je dat letterlijk als platte tekst hebt opgeslagen dan lijkt het me verstandig dat eens anders op te gaan slaan. Als je gaat zoeken hoe normaliseren werkt zul je zien dat er betere oplossing zijn als de boel zo als pllatte tekst op te slaan waardoor het maken van een query om deze zaken op te halen ook een stuk eenvoudiger zullen zijn.

[ Voor 10% gewijzigd door Creepy op 07-01-2008 13:20 ]

[Verwijderd]

Select [Col1] Distinct From [dbo].[Table]

je zou natuurlijk ook gebruik kunnen maken van een andere structuur.

ID SubID naam
1 0 WERKPLAATS-INRICHTINGEN
2 1 Werkbanken
3 2 Werkbanken
4 2 Andere werkbank
5 0 Gereedschappen

WERKPLAATS-INRICHTINGEN->WERKBANKEN->WERKBANKEN
WERKPLAATS-INRICHTINGEN->WERKBANKEN->Andere werkbanken
enz...

Je kan nu de hoofd catagoriën selecteren door middel van alle namen waar subId = 0
Select Naam From Table Where SubID = 0

zou mooier zijn.. maar goed ieder zijn ding ( geen redundantie op deze manier )

[ Voor 59% gewijzigd door Verwijderd op 07-01-2008 13:29 . Reden: Nog extra toevoeging ]

[Verwijderd]

Sjoerd schreef op maandag 07 januari 2008 @ 13:19:
Je wilt dus alles voor -> ophalen?

Juist. Alles voor de eerste ->

Creepy schreef op maandag 07 januari 2008 @ 13:20:
Hoe heb je je categorieren opgeslagen? Letterlijk "GEREEDSCHAPPEN->SLAG EN STOOT->SLAGCIJFERS" als platte tekst? Of heb je nog een andere tabel indeling die je nu achterwege laat?

Ik heb het letterlijk zo opgeslagen inderdaad.

Verwijderd schreef op maandag 07 januari 2008 @ 13:24:
Select [Col1] Distinct From [dbo].[Table]

je zou natuurlijk ook gebruik kunnen maken van een andere structuur.

ID SubID naam
1 0 WERKPLAATS-INRICHTINGEN
2 1 Werkbanken
3 2 Werkbanken
4 2 Andere werkbank
5 0 Gereedschappen

Dit ga ik misschien later doen, het is van belang dat de categoriën op dit moment nog zo moeten blijven staan. En dat distinct werkt hier niet, omdat er geen één gelijk is (in de database). Maar er zijn wel dezelfde tekst voor de eerste ->. Die wil ik selecteren.

[ Voor 91% gewijzigd door Verwijderd op 07-01-2008 13:31 ]

[Verwijderd]

Dan zou ik zeker mijn versie van de tabel nemen zie eerdere post!

[MueR]

Zoals door diverse mensen aangegeven, is het beter je datastructuur goed op te bouwen.

Maar als je het perse zo wil doen:

SQL:

SELECT LEFT(Categorie, LOCATE('->', Categorie)-1) AS CategorieNaam

Efficient is het niet, bad practice wel.

[Verwijderd]

MueR schreef op maandag 07 januari 2008 @ 13:39:
Zoals door diverse mensen aangegeven, is het beter je datastructuur goed op te bouwen.

Maar als je het perse zo wil doen:

SQL:

SELECT LEFT(Categorie, LOCATE('->', Categorie)-1) AS CategorieNaam

Efficient is het niet, bad practice wel.

Ik weet het MueR, maar het probleem is dat ik het voor nu nog even zo moeten laten (helaas!). Selecteerd dit alles voor de eerste ->? Hoe krijg ik er 1 van elk in een rijtje? Nu krijg ik namelijk een hele lijst met allemaal dezelfde categoriën. Toch?

[momania]

"select distinct" er van maken

[MueR]

GROUP BY? DISTINCT?

Hoeveel ken je van MySQL? Deze methode was namelijk 3 seconden zoekwerk in de documentatie..

En waarom moet je het zo laten? Je weet toch dat je nu allemaal dubbel werk aan het doen bent? Nu alles bouwen, later alles herbouwen. Kan je het beter nu herbouwen.

[ Voor 42% gewijzigd door MueR op 07-01-2008 13:45 ]

[curry684]

Verwijderd schreef op maandag 07 januari 2008 @ 13:28:
Dit ga ik misschien later doen, het is van belang dat de categoriën op dit moment nog zo moeten blijven staan.

Onzin, dat er iemand ooit een volstrekt idioot van de pot gerukt datamodel heeft bedacht is nog geen excuus om meer problemen te veroorzaken door dat te negeren. Als je manager dat wel vindt moet je 'm uitkafferen dat ie naar technici moet luisteren, daar heeft ie ze voor.

[Verwijderd]

curry684 schreef op maandag 07 januari 2008 @ 13:47:
[...]

Onzin, dat er iemand ooit een volstrekt idioot van de pot gerukt datamodel heeft bedacht is nog geen excuus om meer problemen te veroorzaken door dat te negeren. Als je manager dat wel vindt moet je 'm uitkafferen dat ie naar technici moet luisteren, daar heeft ie ze voor.

I know De werknemers zijn momenteel bezig met alles in de goede categorie te plaatsen. Dit proces kan ik niet verstoren. Ik kan hier ook niets aan doen. Als dat af is, kan ik het pas wijzigen. (De vraag is hoe, maar dat komt wel).

[curry684]

Dus feitelijk ben je dingen aan het ontwikkelen die over een X aantal weken weer rechtstreeks de vuilnisbak in kunnen terwijl je nu ook in een paar uurtjes een conversiescript zou kunnen draaien om die categorieen hierarchisch op te slaan en de code erop aan te passen.

Goed bezig

[Verwijderd]

curry684 schreef op maandag 07 januari 2008 @ 14:01:
Dus feitelijk ben je dingen aan het ontwikkelen die over een X aantal weken weer rechtstreeks de vuilnisbak in kunnen terwijl je nu ook in een paar uurtjes een conversiescript zou kunnen draaien om die categorieen hierarchisch op te slaan en de code erop aan te passen.

Goed bezig

Ze zijn hier nog niet zo ver gevorderd, helaas . Ze hebben alle categoriën uitgeprint (en dus daarbij de bijbehorende ID's). Ik kan het ID van een categorie dus nu niet zomaar veranderen en alles omgooien.

[Verwijderd]

Dan moet je gewoon zeggen dat het niet anders kan... als ze het toch allemaal niet begrijpen

[P.O. Box]

volgens mij kun je de id's van de categorieen prima hetzelfde laten... maak de items aan het eind van iedere tree gelijk aan die id's en je bent al een heel eind... de categorienamen en subcategorien kun je dan andere id's geven...

[curry684]

Exact @ Edwardvb.

[Janoz]

Verwijderd schreef op maandag 07 januari 2008 @ 14:08:
[...]

Ze zijn hier nog niet zo ver gevorderd, helaas . Ze hebben alle categoriën uitgeprint (en dus daarbij de bijbehorende ID's). Ik kan het ID van een categorie dus nu niet zomaar veranderen en alles omgooien.

En dat is een probleem omdat?

Dat het ID van een categorie vast staat doet toch helemaal niks af aan de manier waarop het opgeslagen wordt? Je kunt gewoon in je conversie script meenemen dat je hetzelfde ID houdt in de nieuwe structuur.

Pas het nu maar gewoon aan. Zorg gewoon dat de interface naar buiten vergelijkbaar blijft. Je applicatie zit nu in de problemen en dergelijke workarounds zorgen er gewoon voor dat het verder in de stront weg gaat zakken.

[Verwijderd]

Krijg je dan niet ontzettend veel queries? Of zie het het verkeerd? Ik neem een voorbeeld:

GEREEDSCHAPPEN->SLEUTELS->DOPSLEUTELS->1" AANDR.->STANDAARD->VERLENGSTUKKEN

Dit is de volledige categorie.

Verlengstukken is de laatste trap. Als je de volledige categorie wilt hebben, moet je van:

- Query wat voor verlengstukken staat ...
- Query wat voor standaard staat ...
- Query wat voor 1" aandr. staat ...
- Query wat voor dopsleutels staat ...
- Query wat voor sleutels staat ...

Of zie ik dit verkeerd?

[curry684]

Je zoekt de steekwoorden 'hierarchische structuur' en 'cache'.

[Verwijderd]

I know. Ik heb eigenlijk geen idee hoe ik dit het snelste kan doen, zonder teveel queries. Elke categorie staat appart in de database. Hoe kan ik dit dan het snelst uit de database halen als ik een lijst wil maken? En waarom het steekwoord 'cache'?

[ Voor 1% gewijzigd door Verwijderd op 07-01-2008 16:29 . Reden: Spelfoutjes ]

[curry684]

In short:
• Check of er een cachefile bestaat en deze minder dan een minuut geleden gemodified is, zo ja unserialize deze, zo nee doe de volgende 4 stappen
• SELECT <all fields> FROM Category
• Bouw in PHP een hierarchische array van categories
• Bouw tegelijk een associative array met id->category mappings
• Serialize deze naar disk
• Doe alles lightning fast op deze structuur ipv met queries

En heya je hebt 1 query per minuut in plaats van 20 per pageview.

[NMe]

Ik zal hem maar weer aanhalen: Storing Hierarchical Data in a Database


En dan pas ik maar meteen even je topictitel aan. "Query vraag" gaat eigenlijk best wel voor iedereen op die een probleem heeft met SQL.

[ Voor 49% gewijzigd door NMe op 07-01-2008 17:29 ]

[curry684]

Die link is leuk maar in de meeste gevallen vet overkill natuurlijk. Voor een tabelletje met 100 categorieeen is het veel sneller en compacter om gewoon Id en ParentId te doen en daar in PHP een native boompje van te bouwen.

[Verwijderd]

Ik ga zo de link bekijken. Het gaat nu momenteel om 667 categoriën, en worden er rap meer. Ik ga op onderzoek uit!

[curry684]

Ook voor een semistatische tabel met 1000 entries is het imho nog overkill. Dat soort opslagmethodes zijn met name interessant als je grote hoeveelheden dynamische hierarchische data in een database zet, zoals documentstructuren met folders of metadata.