Databas-planering i specifikt fall

Jag hade nog inte modellerat det i en relationsdatabas utan i XML.

Känns mest logiskt att ha en annan tabell för sektionerna. Där du kör ett query för din sökning och hämtar ut de ur tabellen du skrev ovan som har den sektionen?

Relationsdatabaser är inte allt längre och XML kan användas för betydligt mycket mer än att utbyta information. Anledningen till att jag föreslog XML var att jag uppfattade problemet som hierarkiskt och för det lämpar sig XML ypperligt (men nu kanske just det här problemet inte är det, jag hade svårt att förstå trådskaparens beskrivning).
I vissa fall kan man även ha hybrid-databaser, dvs både relationer och XML. Alla de stora DBMS har idag stöd för XML och det finns rena XML-databaser som eXist. Frågor på XML-data kan ställas med bl. a XQuery.

I mina ögon ser det ut som en enkel en-till-många-relation (eller ev. många-till-många) vilket, som tidigare påpekat, går utmärkt att hantera i en relationsdatabas med hjälp av en extra tabell.

(Om du inte förstår frågan... är det verkligen lämpligt att komma med ett så självsäkert svar?)

Det var när jag läste igenom det igen, inledningsvis uppfattade jag problemet som hierarkiskt. Trådskaparen kan säkert få till en väl fungerande relationsmodell och det är det de flesta brukar vara bekanta med. Men jag vill ändå slå ett slag för XML-modellering, det är riktigt trevligt och kanske har jag inspirerat nån till att kika lite på det för att bredda sin repertoar.

Info:
Id   Text
-------------
2    Apa
4    Tok

Sektioner:
InfoId   Sektion
---------------------
2         G
2         B
4         A

Jo, det kan ju vara smart att köra så. Då kan du ju köra en join sen när du vill hämta ut. Nog bättre än att köra kommaseparerat.