lagring av flere kategorier til en singel enhet (generalisering)

[Yawa]

Jeg sitter å funderer på en effektiv løsning på lagring av flere kategorier til en singel virksomhet.

Det som er, er at jeg har 2 tabeller (en med hovedkategorier og en med underkategorier). I disse to tabellene har naturligvis hver kategori fått et navn, en beskrivelse samt en ID (primary key).

Da dette er satt opp slik ønsker jeg kun å lagre kategori_id'ene til virksomhets-tabellen og enten JOINe dem sammen med virksomhet_id eller kjøre egne queryer for å hente ut selve kategorinavnet.

 

 

Grunnen til at jeg funderer så mye på dette er pga. at jeg føler det er unødvendig å ha en egen tabell satt opp slik:

 

hovedkategori_id | underkategori_id | virksomhet_id

 

hvor det blir en kategori pr. rad.

Blir så unødvendig "mange" rader hvis 1000 virksomheter har 5 kategorier.

 

Så det jeg tenkte var å skrive alle kategori_id'ene til et eller to egne felter i selve virksomhets-tabellen separert med "," (komma) for så å kjøre en slik liten sak for å plassere dem fint i en liste eller noe:

<?php
$cat = array();
$cat[] = explode(',',$get['kategori']);
foreach $cat AS $value { ... }  //  eller noe lignende som fungerer
?>

 

Men i forbindelse med selve søket/avgrensing av resultater, basert på kategori, hvor jeg brukte en slik SQL-spørring fikk jeg et problem:

<?php
$sql = mysql_query('SELECT * FROM virksomheter WHERE kategori LIKE %'.$_POST['kategori_id'].'%');
?>

Det som er, er at kategoriene 9, 19, 29 ... osv/ol. Alle innholder tallet 9. Det som naturligvis skjer da, er at en virksomhet vil vises i for mange/feil resultat-visninger.

Alternativ kan jeg skrive alle kategoriene navnene til dette feltet, men det syns jeg også ikke er så greit.

 

Så det jeg lurer på er hvordan dette kan løses - Mange gjør jo slikt overalt, så er sikkert en "standard" på det.

Regner med at nettsteder som mittOppdrag, og andre anbuds-tjenester ikke har listet opp en rad pr. kommune en bedrift skal vises i...

Har søkt litt, men finner ikke noe sånn akkurat rundt struktur/oppsett...

 

hadde vert konge om noen kommer med noen tips der...

[quantum]

Slik du har modellert det er det ikke noen sammenheng mellom hoved og underkategori, hvis jeg forstår deg rett. Du har altså både hovedkat_id og underkat_id i en egen tabell, og denne knyttes igjen til virksomhet, via virksomhet_id.

 

Det gir muligheten til å knytte virksomheten til hovedkategorien 'fisk' og underkategorien 'spurv'. Men du ønsker kanskje å avgrense dette slik at underkategorien må henge sammen med hovedkategorien?

 

Du kan flytte hovedkat_id ut fra tabellen med kategori-tilknytninger og inn i tabellen underkategori. Da kan du knytte virksomheten til en underkategori, og denne er fra før av knyttet til en hovedkategori. Du kan også vurdere om du vil ha alle kategoriene i én tabell og bare legge til et felt for "overkategori", så har du ingen begrensning på kategorinivåene.

 

Men når du har slike mange-til-mange-relasjoner blir det nødvendigvis mange rader i knyttetabellene. Hvis du har lyst til å putte kategori-id'ene inn i ett felt som en kommaseparert liste som du skriver, så går det an, men da er du på et vis på vei vekk fra å bruke relasjonsdatabase, og du kan likegodt stappe alt i en flat fil. Så jeg anbefaler deg å tenke slik du har gjort til nå.

 

Er ikke helt sikker på at jeg har forstått datamodellen din, men ihvertfall høres det litt galt ut at du kan knytte underkategoriene til ulike hovedkategorier avhengig av hvilken virksomhet det er snakk om.

[quantum]

... forslag til tabeller ...

Endret 26. september 2010 av quantum

[Yawa]

ikke så flink til å forklare - men forsøker en gang til her...

Dette er tabell-strukturen:

 

virksomheter

> virksomhet_id

> hovedkategori_ider

> underkategori_ider

 

hovedkategorier

> hHategori_id

> hKategori_navn

> hKategori_beskrivelse

 

underkategorier

> uKategori_id

> uKategori_navn

> uKategori_beskrivelse

> rel_hKategori_id

 

Det som er "målet" er å lagre flere kategori_id'er til til et felt, separert med "," (komma).

I resultatvisningen er det mulig å filtrere resultatene basert på kategori - sant. Og noen virksomheter skal vises under flere kategorier.

Problemstillingen blir følgende:

kategori 41, 42, 43 inneholder tallene 4, 1, 2, 3 - Så ved å kjøre en LIKE-statement i sql-queryen resulterer at en virksomhet vises i kategoriene; 1, 2, 3, 4, 41, 42, 42 noe som naturligvis er feil...

 

Alternativ blir det å lage en helt egen tabell slik:

virksomheter_kategorier

> hKategori_id

> uKategori_id

> virksomhet_id

 

Løsningen er da å lagre en rad pr. kategori og JOINe sammen med virksomheter-tabellen.

Det kan jo resultere i ett enormt antall rader (ikke at det har så mye å si da det kun er ID'er, men må da være en smart løsning på dette? hehee)

Flatfiler nevner du - Kan jeg begrense en resultatvisning basert på flatfil?

[quantum]

 

Det som er "målet" er å lagre flere kategori_id'er til til et felt, separert med "," (komma).

I resultatvisningen er det mulig å filtrere resultatene basert på kategori - sant. Og noen virksomheter skal vises under flere kategorier.

Problemstillingen blir følgende:

kategori 41, 42, 43 inneholder tallene 4, 1, 2, 3 - Så ved å kjøre en LIKE-statement i sql-queryen resulterer at en virksomhet vises i kategoriene; 1, 2, 3, 4, 41, 42, 42 noe som naturligvis er feil...

 

Så hvorfor ikke bruke relasjonsdatabasen til det den er god til istedenfor å køle på det viset der?

 

Edit: Ja du kan begrense hva du vil vise fra en flat-fil, det er bare å programmere som du vil ha det selv ... meningsløst, dog ...

 

Det du trenger å gjøre er å sette deg ned og tenke gjennom om du vil bruke en relasjonsdatabase i det heletatt. Og hvis du kommer til at du ønsker å gjøre det, så bruk den slik den er ment å brukes. Hvis du vil ha mange-til-mange-relasjon mellom virksomhet og kategori, så får du nødvendigvis noen rader i knyttetabellen. Sånn er'e bare, og den store fordelen er at det er enkelt å joine og filtrere, fremfor å knote med flatfiler og/eller rare komma-lister.

 

Forøvrig er jeg fortsatt usikker på om du skal ha hovedkategori_id i virksomheter_kategorier tabellen OG i underkategorier-tabellen, du får jo da mulighet til å lagre konstellasjoner som ikke henger helt på greip. Ta og google "normalisere relasjonsdatabase" så finner du litt nyttig info om dette.

Endret 26. september 2010 av quantum

[Yawa]

takker for stikkordet... skal sjekke opp rundt emnet og se hvordan jeg kan få gjort detta på en smart måte...

[quantum]

takker for stikkordet... skal sjekke opp rundt emnet og se hvordan jeg kan få gjort detta på en smart måte...

google-frasen jeg foreslo finner faktisk denne tråden som det mest relevante treffet ... så du må gjerne variere den littegranne :-P mener også å huske at den engleske wikipedia-artikkelen om emnet er ganske utfyllende.