WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Banal (?) databasfråga (https://www.wn.se/forum/showthread.php?t=1044645)

clirre 2010-11-03 22:07

Banal (?) databasfråga
 
Hej,

Ett problem som jag löst på olika icke-eleganta sätt är detta, och något som jag gissar finns en betydligt smartare lösning på:

Jag har två tabeller - Företag och Företagstyp

Företag
FöretagsID
FöretagsNamn
FöretagsTyp

FöretagsTyp
FöretagsTypID
FöretagsTypNamn

Här vill jag koppla företagstypen hos tabellen Företag med en - eller flera! - företagstyper.

Säg att företagstyper är Gruvbolag, Skogsbolag, Stenbolag och AB Alltmöjligt är både ett Gruvbolag och Skogsbolag.

Vad är då den mest eleganta lösningen för att koppla dessa med hjälp av php och mysql?

Jag är även tacksam för sökord jag ska titta på, länkar till tutorials. Har hållt på mycket med php och mysql, men gör alltid på samma (dåliga) sätt och det är dags att uppgradera kunskaperna lite.

Lindahl 2010-11-03 22:34

Skapa en tredje tabell, och lägg in alla relationer i den. En kolumn för FöretagsID, och en kolumn för FöretagsTypID. Ett företag med två typer får då två rader i relationstabellen.

Om du vill ha söktips, googla på "Many-to-Many Relationship"

uffe_nordholm 2010-11-03 22:40

Som jag ser det finns det två alternativ.

Det första alternativet är att lägga till en INT-kolumn till tabellen som innehåller alla företag. Denna INT använder du som en binär flagga: bestäm dig för vilken bit som betyder vad och sedan använder du bitoperationer för att sätta/nollställa bitarna. Det är någorlunda enkelt att hantera, men kräver en del kunskap för att få till (tex Booles algebra och liknande). En stor nackdel är att om du börjar med en väldigt lång lista med företag kommer kanske antalet bitar (och därmed antalet företagstyper) inte att räcka till.

Det andra alternativet tycker jag är snyggare, men det belastar databasen lite mer: skapa en tabell för företagen, men den skall bara innehålla typ företagets namn, adress, kontaktuppgifter och ett unikt ID-nummer.
Detta ID-nummer använder du för att komma åt företagstypen i en andra tabell, där varje enskilt företag kan ha hur många poster som helst (en post för varje typ de skall ha). Fördelarna är att du kan ha hur många typer som helst och varje enskilt företag kan ha hur många typer som helst. Nackdelen är dock att det kräver lite mer jonglerande med tabellerna i databasen och deras innehåll.

William 2010-11-03 22:41

Om jag vore du, så skulle jag köra på detta.

Citat:

"skapa en tabell för företagen, men den skall bara innehålla typ företagets namn, adress, kontaktuppgifter och ett unikt ID-nummer.
Detta ID-nummer använder du för att komma åt företagstypen i en andra tabell, där varje enskilt företag kan ha hur många poster som helst (en post för varje typ de skall ha). Fördelarna är att du kan ha hur många typer som helst och varje enskilt företag kan ha hur många typer som helst. Nackdelen är dock att det kräver lite mer jonglerande med tabellerna i databasen och deras innehåll."

Lindahl 2010-11-03 22:48

Citat:

Ursprungligen postat av uffe_nordholm (Inlägg 20376534)
Det första alternativet är att lägga till en INT-kolumn till tabellen som innehåller alla företag /.../

Kan vara en intressant lösning om man har ett bestämt antal egenskaper som aldrig kommer kunna bli fler eller färre. Möjliggör mycket snabb sökning på exempelvis "andra företag som har exakt samma kategorisering", dock värdelöst om du vill lägga till nya kategorier.

Vilken algoritm och databasstruktur du ska använda hänger mycket på hur du vill kunna behandla och söka i datan.

William 2010-11-03 22:53

Citat:

Ursprungligen postat av Lindahl (Inlägg 20376536)
Kan vara en intressant lösning om man har ett bestämt antal egenskaper som aldrig kommer kunna bli fler eller färre. Möjliggör mycket snabb sökning på exempelvis "andra företag som har exakt samma kategorisering", dock värdelöst om du vill lägga till nya kategorier.

Vilken algoritm och databasstruktur du ska använda hänger mycket på hur du vill kunna behandla och söka i datan.

Det håller jag faktiskt med dig om.

clirre 2010-11-03 23:04

Tack för bra tips, det var faktiskt den lösningen jag tänkte köra på (separat tabell som knyter ihop de andra två tabellerna) från början. Trodde dock det fanns andra sätt som nån form av standardfunktion i Mysql eller jag vet inte.

Tack för hjälpen allesammans!

uffe_nordholm 2010-11-04 20:38

Ett tillägg till mitt förra inlägg: det går åt tre tabeller för den lite flexiblare lösningen (alternativ två): en tabell med info om företagen (namn, adress, telefonnummer osv), en tabell med info om företagstyperna (vad de olika typerna skall kallas: skogsbolag, stenbolag, grönsaksbolag...) och en tabell med kopplingar mellan dessa två andra tabeller.

tartareandesire 2010-11-04 22:27

Citat:

Ursprungligen postat av clirre (Inlägg 20376541)
Tack för bra tips, det var faktiskt den lösningen jag tänkte köra på (separat tabell som knyter ihop de andra två tabellerna) från början. Trodde dock det fanns andra sätt som nån form av standardfunktion i Mysql eller jag vet inte.

Tack för hjälpen allesammans!

Vilket var det dåliga sättet du alltid gör på då? :) Det här är en av de mest grundläggande strukturerna i relationsdatabaser så det kan vara värt att lägga på minnet.

studiox 2010-11-04 23:55

Om du har många företag (flera hundra tusen) och många kategorier (flera tusen) och datat dynamiskt förändras (växer/minskar) kan ju NoSQL vara ett alternativ (dokumentdatabas) - relationsdatabaser är ju enbart bra på.. relationer :)


Alla tider är GMT +2. Klockan är nu 13:47.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson