![]() |
Hej!
Jag bygger just nu ett register med poster som ska vara indelade i kategorier. Var post ska vara kunna tillhöra en eller flera kategorier. De olika kategorierna ska kunna ändras, läggas till eller tas bort, och ligga i en egen tabell. Jag funderar därför hur man snyggast gör dessa realationer! Detta är ett sätt, men jag gillar inte det riktigt: Kod:
kategori-tabell: Kod:
SELECT * FROM register-tabell WHERE kat LIKE '%".$katid.",%' ORDER BY ... Kod:
DELETE FROM kategori-tabell WHERE id=".$katid." LIMIT 1; Kod:
UPDATE register-tabell SET kat = CONCAT(kat, '".$katid.",') WHERE id = ... Har någon förslag på ett bättre sätt? / Lasse |
Du bör ha en post->kategori-tabell som ser ut nåt i stil med
post_id kategori_id Det gör att du slipper spara relationerna som strängar. |
jag har i helgen satt upp ett system för en webbutik
där har jag - produkter - här lagrar jag alla produkterna - utan någon info [id] [produktnummer] [produktnamn] [kategori] - produktattribut - här lagrar jag en lista på alla olika attribut.. storlek, pris, längd, mängd, vikt, tillverkare - whatever [id] [namn] - attribut - här lagras sen en hel jättelista med produkter (från -produkter-) och attribut (-produktattribut) och sen vilket värde dom har [id] [produktID] [attributID] [värde] nu kan jag alltså väldigt lätt skapa nya attribut för mina produkter utan att designa om databasen |
Tack för två snabba bra svar!
Citat:
|
Kod:
kategori-tabell: |
Jag kör på:
Kod:
kategori-koppling-tabell: alla registerposter och vilka kategorier de har? Måste man köra en sub-fråga till varje register post? Typ enligt denna principskissen: Kod:
SELECT * FROM register-tabell; Alltså inte: Kod:
SELECT * FROM register-tabell LEFT JOIN kategori-koppling-tabell ON register-tabell.id = kategori-koppling-tabell.register-id |
Nej. Du bör nog läsa på lite om SQL, bara ett tips. ;)
Om jag fattat vad du är ute efter rätt bör det bli så här: Kod:
SELECT kategori, register FROM kategori-tabell, register-tabell, kategori-koppling-register-tabell WHERE kategori_id = kategori.id AND register_id = register.id |
Citat:
(Principskissen var principskiss för skripet jag kör (PHP i mitt fall) med frågor till SQL och inte ren SQL om det misstolkades... :unsure: ) Citat:
(Det är inte heller kategori-namn-hämtning som behövs, utan kategori.id räcker!) Det jag vill göra är att lista alla registerposter, och där även skriva ut vilka kategorier de tillhör. Både min princip-skiss med att köra en extra SQL-fråga för var post och att köra med "LEFT JOIN" funkar! Det blir bara så mycket frågor fram och tillbaks med första lösningen. Andra lösningen skickar var registerpost lika många ggr som antalet kategorier den är med i. (Dock minst en!) Naturligvis onödig data, samt det måste detekteras i skriptet hur många rader som var post har! Det jag vill ha är en JOIN-funktion som bygger på med fler kolumner om det finns flera kategorier, istället för med nya rader! Jag är dock tveksam om det finns en sån funktion! (Jag kör MySQL) |
om tanken är att varje registerrad ska kunna förekomma en gång i en kategori så är id kolumnen i "kategori-koppling-tabell" överflödig, såvida inte just den relationen ska användas på något annat ställe (vilket inte är troligt i det här fallet). Sätt en unik begränsning på de två kvarvarande istället.
Ett tips. |
Citat:
|
Citat:
Tack för tipset! Körde precis: Kod:
SQL: Citat:
|
Där ser man vad slow writing kan leda till... Jajja... Vidare.
Jag ser det svårt att lösa det med en generell SQL. Som jag förstår det så vill du på en och samma rad få ut olika många kategorier beroende på hur många kategorier en registerrad har. Problemet med det tänket är att varje rad måste innehålla exakt lika många kolumner. Och det skulle inte bli fallet om en rad har en kategori, en annan tre. Det går att lösa, som du är inne på, med en left join. Men då måste du veta innan hur många kategorier det kan finnas för en registerrad innan du ställer frågan. Enklast gör du det genom att begränsa antalet kategorier en registerrad kan ha, genom att göra en kolumn per kategori. Säg att vi begränsar det till tre. Då skulle registertabellen (rt i sqlen) se ut som följer: [id] [namn] [cat1id] [cat2id] [cat3id] Kategoritabellen (ct i sqlen): [catid] [namn] SQLen skulle se ut som följer: Kod:
SELECT Det skulle vara möjligt att göra den mer dynamisk. Men jag tror att klockan är för mycket för att jag ska kunna förklara det rätt. Principen är en blandning av den jag förklarat här, och den som diskuterats innan. EDIT: Jag är tydligen för långsam idag. Detta är ett svar på Tvartoms meddelande kl 2309 (servern verkar ha sommartid fortfarande) *vad övrigt är* Nokias "Get togeather do whatever" reklam har ett otroligt skönt soundtrack! |
Citat:
|
Citat:
|
Tack heyday... Ditt svar gjorde att jag kom på följande lösning:
Kod:
SQL: Kod:
<?PHP Kod:
SQL: Kod:
SQL: |
Citat:
|
Känns som om du kanske bör kolla över behovet istället och fundera på varför du måste ha x antal kolumner istället för x antal rader i recordset'et. Vill du slippa räkna kategorierna så kan du slänga in en count i sql'en för antal kategorierna per register om det underlättar? (svårt att ge tips om man inte vet i vilket sammanhang det ska användas)
Då får du som svar typ: Kod:
Id Register * Kategori * *Antal |
Citat:
A PRIMARY KEY is a unique KEY where all key columns must be defined as NOT NULL. If they are not explicitly declared as NOT NULL, MySQL will declare them so implicitly (and silently). A table can have only one PRIMARY KEY. If you don't have a PRIMARY KEY and an application asks for the PRIMARY KEY in your tables, MySQL returns the first UNIQUE index that has no NULL columns as the PRIMARY KEY.[/quote] Vad nog detta jag tänkte på, men minne är inte vad det borde. :) |
Robert: Att lista antal är en annan bra idé, som kan användas!
Just nu tänkte jag lista upp register i en <table> och visa tillhörande kategorier: (Att ha flera kolumner passar utmärkt här... Typ: Kod:
<table> Jag tackar så hemskt mycket för alla svar! |
Alla tider är GMT +2. Klockan är nu 19:25. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson