Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

Databasdesign

1
Skriv svar
Permalänk
Glömsk
●

Databasdesign

Låt säga att man vill skapa en databas över musikalbum. Databasen ska innehålla artist och namn på albumet. Inte så svårt:

[ id | artist | album ]

Nu kan dock ett album bestå av flera artister. Detta skulle man kunna göra såhär:

[ id | album ]
[ id | artist ]
[ album_id | artist_id ]

Där första tabellen innehåller namnet på albumet, andra tabellen innehåller namn på artisten och tredje tabellen innehåller vilka artister som arbetat på vilka album.

Nu undrar jag om man kan göra detta på två tabeller eller färre utan att skapa fält som kommer att vara tomma eller ha applikationsspecifik data.

Cheers.

Visa signatur

...man is not free unless government is limited. There's a clear cause and effect here that is as neat and predictable as a law of physics: As government expands, liberty contracts.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det antar jag väl att man kan, men det blir nog svårt såvida man inte frångår normalformerna.

edit: är dock inte helt säker på vad du menar.

Visa signatur

The power of GNU compiles you!
"Often statistics are used as a drunken man uses lampposts -- for support rather than illumination."

Redigera
Citera flera Citera
Permalänk
Medlem
●

Re: Databasdesign

Citat:

Ursprungligen inskrivet av Psionicist
Nu undrar jag om man kan göra detta på två tabeller eller färre utan att skapa fält som kommer att vara tomma eller ha applikationsspecifik data.

Varför vill du göra det med mindre än tre tabeller? Blir nog svårt att få databasen normaliserad med mindre än tre tabeller.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Ett tips är att du namnger id:t i artisttabellen till artist_id och inte bara id och v.v. i albumtabellen.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av denka
Ett tips är att du namnger id:t i artisttabellen till artist_id och inte bara id och v.v. i albumtabellen.

Varför det? (Ska uppfattas nyfiket, inte illasinnat.)

Att bara ha id funkar väl bra, då man vid eventuella joins kan göra artists.id.

Senast redigerat
Visa signatur

Personlig webbplats Talman2Batmanizer Slänko Remindera
Greasemonkey-script Artwork of Johanna Öst

Redigera
Citera flera Citera
Permalänk
Glömsk
●

Re: Re: Databasdesign

Citat:

Ursprungligen inskrivet av phnom
Varför vill du göra det med mindre än tre tabeller? Blir nog svårt att få databasen normaliserad med mindre än tre tabeller.

Det vore intressant rent tekniskt, jag ser inga skäl till att en databas inte skulle kunna vara dynamiskt n-dimensionell genom att abstrahera bort tabeller som bara är intressant för en annan tabell, kanske genom att kunna skapa fält som är pekare till andra tabeller.

Vi kan ta det andra exemplet i första inlägget. Den här strukturen är vad jag vet det bästa sättet att designa databasen, men det är inte det teoretiskt enda exemplet. Med den här strukturen är det enkelt att skapa en lista över album (som innehåller information om namn och artist(er)), och det är även enkelt att skapa en lista över artister (som innehåller album artisten deltagit på).

Låt säga att vi enbart är intresserade av att albumen ska kunna associeras med artister, inte tvärt om. Detta skulle vi kunna modellera såhär i "tre" dimensioner, där *artister är en pekare till en tabell med artist_id.

+-----------------------+
|        album          |
+----+-----------+------+
| id | *artister | namn |
+----+~~~~~~~~~~~+------+

     /\/\/\/\/\/\/

     +~~~~~~~~~~~+
     | artister  |
     +-----------+
     | id1       |
     | id2       |
     | idn       |
     +-----------+

Detta ger samma resultat som vår tvådimensionella struktur med tre tabeller, fast här använder vi bara två "publika" tabeller istället. Den matematiska modellen av en databas är mängder. En mängd kan bestå av flera mängder. En metod att representera detta är mha pekare.

Nackdelen med detta är att det krävs en O(1)-operation extra vid uppdatering av "subtabellen" då man måste ta reda på vart tabellen ligger. Detta är ganska ofarligt.

Av era inlägg drar jag slutsatsen att det här inte går, och det finns säkert goda anledningar till detta (en databas är exempelvis mer elegant om den enbart kan vara 2-dimensionell). Som programmerare vore det dock väldigt ballt att kunna spara data i databaser som man sparar data internt i program.

Visa signatur

...man is not free unless government is limited. There's a clear cause and effect here that is as neat and predictable as a law of physics: As government expands, liberty contracts.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Det kanske är detta denka menade iofs:

Du kan ju slänga ihop artists/albums-tabellerna till en som kan heta artist_and_albums eller atoms eller vad man nu vill, och ha typ

id - isArtist - name
1 - 1 - Darin
2 - 0 - Darins Greatest Hits

På så vis kan man väl trots att man har färre tabeller uttrycka det mesta. För man kan väl joina en tabell med sig själv?

Men det känns lite väl uppenbart, så jag antar att jag missförstått dina förbehåll. Applikationsspecifik data?

Visa signatur

Personlig webbplats Talman2Batmanizer Slänko Remindera
Greasemonkey-script Artwork of Johanna Öst

Redigera
Citera flera Citera
Permalänk
Glömsk
●

Malesca: Det där var en intressant metod, mycket mindre overhead än med tre tabeller. Dessvärre fragmenteras tabellen på fel vis, det finns inget som stoppar oss att skapa en generell tabell som innehåller ett visst antal fält och slänga dit ett "typ"-fält där vi egentligen borde skapa separata tabeller istället. Om vi har fem tabeller som alla består av en int (id) och en varchar, så skulle vi kunna göra detta till en tabell genom att lägga till ett typ-fält (int kanske) som får vara 1..5. Detta går men är inte snyggt.

Rent "semantiskt" är det ju namnet på albumet och namnet på artisten som är intressant, inte hur dessa är relaterade till varandra, i alla fall för vårt icke-generella fall där bara den ena tabellen behöver information ur den andra tabellen.

Visa signatur

...man is not free unless government is limited. There's a clear cause and effect here that is as neat and predictable as a law of physics: As government expands, liberty contracts.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Tuple calculus, den matematiska modellen bakom relationsdatabaser är av diverse pragmatiska skäl inte implementerad fullt ut i moderna databaser.

11 sidor kunskap:

Relational Model of Data for Large Shared Data Banks
http://www.zafar.se/bkz/dev/papers/codd-1970.pdf

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av Malesca
Varför det? (Ska uppfattas nyfiket, inte illasinnat.)

Att bara ha id funkar väl bra, då man vid eventuella joins kan göra artists.id.

Om du skriver "rätt" namn på id:t så slipper du ange vilken tabell du tar id:t ifrån vid t.ex joins.

Dessutom behöver man aldrig fundera på vilket id man håller på med.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av denka
Om du skriver "rätt" namn på id:t så slipper du ange vilken tabell du tar id:t ifrån vid t.ex joins.

Dessutom behöver man aldrig fundera på vilket id man håller på med.

Det där är ingen programmeringsteknisk fråga utan en programmeringsfilosofisk fråga och diskussioner rörande den brukar vara av typen "ska man prefixa alla fält-namn i tabellerna med tabellens namn: tabell1_id eller inte?" och brukar livligt diskuteras tills någon säger att nu får det räcka för det finns två olika skolor. Det är precis samma diskussion som "ska man prefixa variabelnamnen med variabelns datatyp: intCount, charText[] eller inte?".

Visa signatur

RTFM - vacker sak att säga till folk som ställer dumma frågor

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av jcarlsson
Det där är ingen programmeringsteknisk fråga utan en programmeringsfilosofisk fråga och diskussioner rörande den brukar vara av typen "ska man prefixa alla fält-namn i tabellerna med tabellens namn: tabell1_id eller inte?" och brukar livligt diskuteras tills någon säger att nu får det räcka för det finns två olika skolor. Det är precis samma diskussion som "ska man prefixa variabelnamnen med variabelns datatyp: intCount, charText[] eller inte?".

Exakt, det var det jag sa. Vad babblar du om egentligen?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av denka
Exakt, det var det jag sa. Vad babblar du om egentligen?

Det är en fråga som programmeraren själv tar ställning till, ska han döpa id-fältet i artist-tabellen till artist_id måste han döpa om alla andra fält i den kolumnen till artist_... för att följa den tankegång som du föreslår. Om psionicist inte vill det så behöver han inte, det är det som är det finna med många sätt att lösa samma sak på.

Min lösning på "problemet" som tråden är till för hade varit ett av följande:

artist: id, namn
album: id, namn
artist2album: artist_id, album_id

eller

objects (artister och album): id, namn, type (1 = artist, 2 = album)
artist2album: artist_id, album_id

sen kan man slänga in:
track: num, album_id, name (num + album_id används för att identifiera ett specifikt spår för track är spårnummer på skivan)

Jobbar med en sida som använder en tabell som heter Objects för att spara det mesta på sidan, den har ett Type-fält som säger om det är en recension, artikel, intervju, ... fast för kopplingen till artist används en annan tabell som heter ObjectTypes som innehåller artister, klubbar, festivaler och liknande, så det blir mer som den första lösningen jag föreslog med en liten inblandning av nummer 2 för att kunna ha olika typer av saker i samma tabell.

Har själv funderat på att göra ett liknande system fast då mer som:
object: id, type (1 = skiva, 2 = bok, 3 = vhs, 4 = dvd, eller nåt), name, information
creator (skapare av objekt): id, type (1 = artist, 2 = författare, 3 = regisör, 4 = producent, ...), name
creator2object: creator_id, object_id

Detta ger en möjlighet att ange både regisör och producent för en film, fast man kanske ska flytta över type från creator till creator2object så att en person kan ha regiserat en film och producerat en annan utan att behöva stå med två gånger. Men men, mitt system finns inte ens på papper ännu, finns bara i huvudet och lär nog stanna där ett tag till.

Visa signatur

RTFM - vacker sak att säga till folk som ställer dumma frågor

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av jcarlsson
Det är en fråga som programmeraren själv tar ställning till, ska han döpa id-fältet i artist-tabellen till artist_id måste han döpa om alla andra fält i den kolumnen till artist_... för att följa den tankegång som du föreslår. Om psionicist inte vill det så behöver han inte, det är det som är det finna med många sätt att lösa samma sak på.

Har jag sagt att han måste följa mitt TIPS!?

Själv prackar du på honom en lösning. Måste han följa den?

Tagga ner ett par kilon.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av denka
Har jag sagt att han måste följa mitt TIPS!?

Själv prackar du på honom en lösning. Måste han följa den?

Tagga ner ett par kilon.

"Min lösning på "problemet" som tråden är till för hade varit ett av följande" - jag säger att MIN lösning skulle vara någon av följande, jag ger två förslag på lösningar som jag skulle använda, säger aldrig att han måste använda dom. Sen nämner jag en annan liknande lösning som jag använder för ett projekt och en lösning för ett projekt som jag själv funderar på som är en "mer utbyggd" version av det projekt som tråden behandlar. Jag prackar aldrig på någon något, däremot prackar du på genom att nämna ordet "rätt" (det kvittar att det är inom citationstecken, det har ändå en laddning av kraft som säger att det är den enda lösningen).

Visa signatur

RTFM - vacker sak att säga till folk som ställer dumma frågor

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av jcarlsson
"Min lösning på "problemet" som tråden är till för hade varit ett av följande" - jag säger att MIN lösning skulle vara någon av följande, jag ger två förslag på lösningar som jag skulle använda, säger aldrig att han måste använda dom. Sen nämner jag en annan liknande lösning som jag använder för ett projekt och en lösning för ett projekt som jag själv funderar på som är en "mer utbyggd" version av det projekt som tråden behandlar. Jag prackar aldrig på någon något, däremot prackar du på genom att nämna ordet "rätt" (det kvittar att det är inom citationstecken, det har ändå en laddning av kraft som säger att det är den enda lösningen).

Undrar om du behöver gå en kurs i läsförståelse.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av jcarlsson
Har själv funderat på att göra ett liknande system fast då mer som:
object: id, type (1 = skiva, 2 = bok, 3 = vhs, 4 = dvd, eller nåt), name, information
creator (skapare av objekt): id, type (1 = artist, 2 = författare, 3 = regisör, 4 = producent, ...),

Apropå det här fallet och mitt (liknande) förslag ovan så kan ju nämnas (om någon missat det) att MySQL har typen enum, så man slipper hantera siffror. Exempel:

id = int(5)
name = varchar(50)
type = enum('cd', 'artist')

Visa signatur

Personlig webbplats Talman2Batmanizer Slänko Remindera
Greasemonkey-script Artwork of Johanna Öst

Redigera
Citera flera Citera
Permalänk
Medlem
●
Citat:

Ursprungligen inskrivet av Malesca
Apropå det här fallet och mitt (liknande) förslag ovan så kan ju nämnas (om någon missat det) att MySQL har typen enum, så man slipper hantera siffror. Exempel:

id = int(5)
name = varchar(50)
type = enum('cd', 'artist')

Det är en oerhört fin lösning, men då binder man ju sig redan i designen av databasen till att köra en databashanterare som har stöd för enum, om man vet att man kommer köra hela alltet som en mysql-databas så är det ju en sak som går, men om man funderar på att köra med flera olika databaser så blir det inte lika lätt. Någon som vet vilka databashanterare förutom mysql som stöder enum? PostgreSQL? Oracle?

Visa signatur

RTFM - vacker sak att säga till folk som ställer dumma frågor

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara