reversed LIKE?? (postgresql

[Flippuh]

Hallo,

Ik moet een path uit de database halen en heb iets in de trend van een omgekeerde LIKE statement nodig
ea:

SELECT * FROM table WHERE `/mijn/path` LIKE row_name '%'

Iemand sugesties??

 

[Glest]

Ik kan me niet voorstellen waar dit voor nodig is, maaargoed:

SELECT * FROM table WHERE `/mijn/path` LIKE CONCAT(row_name,'%')

Werkt in MySQL iig.

 

[Flippuh]

MMM ja goeie, daar had ik nog niet eens aan gedacht.
Enig idee of indexes dan nog gebruikt kunnen worden?

Ik heb deze query nodig om modules te koppenen aan een urlpath.
Stel:

/forum => bevat een forum module
/shop => bevat een webshop module

De url /forum/post/add moet gelinked worden naar de applicatie forum.
de url /shop/items/stofzuigers/models/X33 moet gelinked worden naar de shop module.

Bedankt voor je hulp, moet nog een manier vinden om de meest perfecte match te vinden (ea: /forum/extra/shop moet linken naar shop en niet naar forum) maar dat moet wel gaan lukken hoop ik.

 

[Frats]

Klinkt als meerdere velden in een kolom stoppen, kun je niet beter een tabel maken met 'directory' en daar een parent_id aanhangen voor de bovenliggende map? Beetje zoals je explorer dat ook doet?

Lijkt me een stuk sneller met zoeken en minder dubbele informatie ook.

 

[Flippuh]

Ja daar heb ik ook al aan zitten denken helemaal uit-normaliseren,
Hier komen echter een paar probemen bij kijken:

1. Ik weet niet hoeveel levels/directories het opgevraagde path bevat en zou dus een loop functie moeten schrijven/gebruiken (moet kunnen in postgresql) om een passend aantal JOINS te generen op basis van het parent_id.

2. Ik moet het betreffende path koppellen aan een vhost_id gezien deze database door diverse virtualhosts gebruikt wordt. Dit kan met een genormaliseerde table enkel door de query die het path zoekt met gebruik van een subquery te joinen op een vhost_lookup table aan de hand van het teruggegeven path (wat dus dubble data vereist)

De vraag is wat sneller is???????

 

[dicabrio]

je hoeft helemaal geen loopfunctie te schrijven voor postgres. je kunt gewoon alles ophalen. dit zit een array.. en met behulp van php of andere script taal kan je de gelaagdheid erin brengen.

Ik heb dit wel eens gedaan met een menu structuur. alle items ophalen en aan de hand van hun parent_id in php de gelaagdheid erin gebracht.

Het mooie hiervan is dat het razendsnel is. Je gebruikt 1 query zonder weinig of geen joins. PHP heeft daarna nog wat werk, maar dat is te verwaarlozen

 

[Flippuh]

hoi dicabrio,

Bedankt voor je antwoord en kan me voorstellen dat het met een simpele menu structuur een makkelijke oplossing is. Toch lijkt het me voor deze situatie een verre van perfecte oplossing. Ik moet een entry vinden uit zeg 100 entries voor de/een betreffende vhost.
Zou ik het in php afhandelen zitten hier een paar nadelen aan:

1. Ik moet alle matches fetchen van de database das dus 100 ipv. 1, met een remote database is dat een merkbaar verschil.
2. Ik moet in een loop alle entries checken met een preg_match(), das ook niet echt wenselijk.
3. Na een match gevonden te hebben moet ik opnieuw naar de database connecten om het betreffende profiel te fetchen, iets dat waarneer ik een perfecte match vindt,.. ik met een join op kan lossen.
4. Mocht ik tzt een andere script/programmeer taal gaan gebruiken (C/C++) moet ik die functie opnieuw schrijven.

Naar mijn idee is het slimmer om de oplossing van Glest gebruiken zelfs als deze geen indexes gebruikt op het betreffende path veld.

 

[dicabrio]

Ik vraag me af hoe je db structuur eruit ziet. Ik heb namelijk het vemoede dat het simpel op te lossen is. Zou je een diagrammetje kunnen posten van hoe het er uitziet? Misschien dat we je hier iets kan bijschaven.

 

[Flippuh]

huidige (relevante) Db structuur ziet er alsvolgt uit,

vhost_lookup
vhost_id,
vhost_name,
vhost_docroot,
vhost_status

url_lookup
url_id,
vhost_id,
url_path

application_lookup
app_lookup_id,
app_id,
url_id

applications
app_id,
app_status,
app_name,
app_created,
app_modified,
app_administrator

application_profiles
app_profile_id,
app_id,
app_attr_id,
app_attr_value

application_attributes
app_attr_id,
app_attr_name,
app_attr_type,
app_attr_default,
app_attr_option_values,
app_attr_required

Kan op dit moment niet bij de database zelf, maar uit m'n hoofd is het als bovenstaand.
Zit nog in de uitzoek/test fase dus verbeteringen zijn van harte welkom.

Voorbeeld query (niet getest,... uit losse hand)

  SELECT * FROM vhost_lookup 
    JOIN url_lookup USING(vhost_id)
    JOIN application_lookup USING(url_id)
    JOIN applications USING(app_id)
    JOIN application_profiles USING(app_id)
    JOIN application_attributes USING(attr_id)
    WHERE vhost_docroot='/some/path' 
    AND vhost_status=true
    AND `/mijn/path` LIKE CONCAT(url_path,'%')
    AND app_status=true

[edit] vhost_id in de url_lookup toegevoegd en een test query toegevoegd[/edit]