Jag vet att detta inte är en specifik SQL-fråga, men i rubriken " Brainstorming - bollplank, en idé jag har...??" gav jag en antydan om att det är ett ospecificerat problem av mer generell karraktär.
Ibland går gränssnitt och en vanlig SQL fråga hand i hand. Dom kompletterar varandra.
Jag förstår din idé. Jag använder samma upplägg i andra sammanhang och jag tycker upplägget är extremt omständigt, rörigt och bökigt att ha att göra med. Men det är helt självförvållat. Det är givetvis en fråga om val av gränssnitt. Ett klumpigt gränssnitt blir givetvis jobbigt att arbeta med.
***
När jag tänker, vilket faktiskt kan hända, tror jag att min datumvariant passar bättre i just detta fallet. I mitt exempel rör det sig om en hel stad med till viss del ospecificerade evenemang. Dvs. man vet inte vem avsändaren är. (Arrangören)
Till exempel, den 5 maj 2007 är det "Mulledagen", i parken. Mulle fyller 50 år i år och det firas med balonger och varm korv. Jag är osäker på vem arrangören är och i detta sammanhanget är det inte så viktigt.
Hade det där emot varit tal om ett företag, en sponsor, för varje evenemang tror jag att din lösning skulle vara att föredra.
Med din variant får man skriva in "Mulleträff i parken" först, sen "Mulleträff i parken 2007" och ett specifikt datum. Man måste alltså skriva in samma evenemang två gånger utan att veta om det kommer åter nästa år.
Med min variant skriver man in "Mulleträff i parken" den 5 maj. Kanske fanns det Mulleträff även förra året och då kommer det upp på sidan och man kopplar (markerar) den händelsen till detta årets evenemang.
Det är en viss skillnad i struktur (databasdesign) på evenemang för Rockparty och ospecificerade evenemang som sker i en turiststad modell mindre.
***
Du skriver: "om du knyter A till B, B till C, är då A knutet till C?"
- Nej. Det finns ingen poäng eller behov av den typen av kopplingar. Den typen av kopplingar är helt överflödig och enbart extra arbete utan relevant eller användbart resultat.
