Jag känner mig osäker. Denna SQL fungera, men frågan är, är den effektiv. Jag hade skrivit frågan så här istället, ingen optimering men jag tycker den beskriver vad du gör betydligt bättre. Tack Christoffer. Tabeller med repeterande kolumner bryter mot första normalformen och är alltså helt onormaliserad (om man kan säga så :) Oj, nu måste vi nog prata teknik här. CREATE TABLE t_Forfattare (for_id int, forfattarnamn varchar(100)) Ok, så lägt är jag med, men du svarade aldrig, om det är mer än en författare, hur ställer det sig? säg att du har en sång (1,sången) med 2 författare (1, mig) & (2, dig) Jag är nog antagligen ovanligt trögtänkt, men jag har svårt att få ihop det. För varje författare man fyllt i skapar man denna författare i författartabellen (om den inte redan finns), och sedan kopplar man den till sången genom att lägga in en rad i kopplingstabellen med sångens resp författarens id. För att testa, så har jag gjort följande:Går det att skriva denna SQL effektivare?
Vore tacksam om någon ville försöka granska den:
<code>
SQL = "SELECT t_SongTitlar.ArrNo, t_SongTitlar.songtitel, t_Forfattare.Namn " & _
" FROM t_Forfattare RIGHT JOIN t_SongTitlar ON t_Forfattare.For_Id = t_SongTitlar.Forfattare " & _
" or t_Forfattare.For_Id = t_SongTitlar.Forfattare2 or t_Forfattare.For_Id = t_SongTitlar.Forfattare3 " & _
" Where t_Forfattare.Namn = '" & List2.Text & "'"
</code>
Vad jag funderar på är att ibland så är t_SongTitlar.Forfattare2 och t_SongTitlar.Forfattare3 "Null".
Tack på förhand.Sv: Går det att skriva denna SQL effektivare?
<code>
SELECT t_SongTitlar.ArrNo, t_SongTitlar.songtitel, t_Forfattare.Namn
FROM t_SongTitlar s
LEFT OUTER JOIN t_Forfattare f
ON s.Forfattare = f.For_Id
OR s.Forfattare2 = f.For_Id
OR s.Forfattare3 = f.For_Id
</code>
Däremot så tycker jag du har normaliserat dåligt, att ha tre författarfält är inte särskilt korrekt. Där hade du kanske kunnat hitta en optimering.Sv: Går det att skriva denna SQL effektivare?
Jag har grunnat mycket på det, men inte kommit fram till en bättre lösning.
Orsak:
Det här gäller min egen musik. Ibland så har jag skrivit texten själv, ibland har vi varit två, någon gång så har vi varit tre.
Jag vill ha information om allt i detta fallet.
Jag kände att jag inte kunde normalisera bättre, eller?Sv: Går det att skriva denna SQL effektivare?
Jag hade lagt författare i en egen tabell (som du gjort), med ett många-till-många-förhållande till sångtitlarna istället för att ha tre kolumner för författare i sångtitlarna.Sv: Går det att skriva denna SQL effektivare?
Som jag har lärt mig(!), så kan man enbart göra en relation många till många, genom att använda sig ave en tmp-tabell(t ex).
Om jag nu enbart skall ha ett fält i t_songtitlar, som jag kallar för författare, hur gör jag då rent praktiskt när jag i vissa fall enbart har en författare, medans i andra fall ha två eller tre författare.
Jag har grunnat, men inte blivit klok på det.
Sen, vad vinner jag praktiskt? Jag menar förutom att man gör på "rätt" sätt?
Du skall ha tack för att du tar dig tid, det uppskattar jag verkeligen.Sv: Går det att skriva denna SQL effektivare?
CREATE TABLE t_Sangtitlar (sang_id int, sangnamn varchar(100))
CREATE TABLE t_SangForfattare (sang_id int, for_id int)
PKs och FKs är väl ganska självklara antar jag. Nu har du ett många-till-många-förhållande mellan författare och sångtitlar, och du är så normaliserad man kan bli. Vad du vinnar på det är förstås datakorrekthet (bra på att uppfinna ord idag.. :) , men även prestanda eftersom du t ex inte behöver ha en massa tomma kolumner etc. Relationsmodellen är inte skapad på ett visst sätt för att nån tyckte det vore kul att ha den så, det är förstås det bästa sättet att göra det på.Sv: Går det att skriva denna SQL effektivare?
Sv: Går det att skriva denna SQL effektivare?
song - tabellen innehåller:
(1, "sången")
forf - tabellen innehåller:
(1, "mig")
(2, "dig")
Du får du i songforf tabellen följande innehåll:
(songid, forfid) //fältnamnen
(1, 1)
(1, 2)
SELECT song.name, forf.name FROM ((song LEFT JOIN songforf ON song.id = songforf.songid) LEFT JOIN forf ON songforf.forfid = forf.id)
Lite osäker på om det är bästa sättet att joina men det bör fungera
Du kan på det här sättet ha hur många författare som helst till varje sång, samtidigt som varje författare kan skriva så många sånger som helst.
/Per-ErikSv: Går det att skriva denna SQL effektivare?
Säg så här, i formuläret där finns förutam andra textrutor, tr textrutor, en med författare ,en författare2 och en författare3.
Hur skall jag kunna spara, uppdatera eller visa informationen?
Jag är väldigt tacksam för visat intresse, men jag får inte ihop det.Sv: Går det att skriva denna SQL effektivare?
Sv: Går det att skriva denna SQL effektivare?
t_songtitlar består bl a av
ArrNo text(för att få med nollorna) nyckel
Songtitle
osv
t_SongForfattare
ArrNo främmande nyckel till t_songtitlar
Forfattare tal (jag var tvungen att använda mig av uppslagstabell här), blir då främmande nyckel till t_forfattare.for_id
t_forfattare
for_id
Namn
osv
Det här har jag fått fram via Access, och det fungerar kanonbra.
Är det så här ni menar??
Nu skall jag försöka att få in det i SQL-servern, och jag räknar med en del bekymmer, men går det i Access så...
Jag kan ialla fall se hur mycket mera smidigt det blev :-)
Så här har jag försökt, men här har jag problem.
Om jag för in ett ArrNo i t_songforfattare(jag försökte med 002 och for_id =1) så tog han fram att alla låtarna var av samma författare.
Någonstans så är det fel.
<code>
SELECT t_songtitlar.songtitel, t_forfattare.namn FROM ((t_songtitlar LEFT JOIN t_songforfattare ON t_songtitlar.ArrNo = t_songtitlar.ArrNo) LEFT JOIN t_Forfattare ON t_songforfattare.for_id = t_forfattare.for_id)
</code>
Vore tacksam för hjälp här.
Löste det själv:
<code>
SELECT t_songtitlar.ArrNo,t_songtitlar.songtitel, t_forfattare.namn FROM ((t_songtitlar LEFT JOIN t_songforfattare ON t_songtitlar.ArrNo = t_songforfattare.ArrNo) LEFT JOIN t_Forfattare ON t_songforfattare.for_id = t_forfattare.for_id)ORDER BY t_songtitlar.ArrNo
</code>
Nu blir ju problem helt annat, när detta nu skall in i VB, men jag återkommer vid problem.