sql >> Databasteknik >  >> RDS >> Mysql

Utforska datamodellering (hur man hoppar ihop en vettig databas)

Förvånad verkar de flesta svar ha missat frågan, men jag ska ge det här ett försök;

Detta kallas för datamodellering (hur man traskar ihop ett gäng tabeller i en databas för att uttrycka vad man vill på bästa möjliga sätt), och inte känner sig dum för att fråga; det finns människor där ute som ägnar alla sina vakna timmar åt att justera och designa datamodeller. De är oerhört viktiga för välbefinnandet i alla system, och de är i själva verket mycket viktigare som de flesta ger dem kredit för.

Det låter som att du är på rätt väg. Det är alltid ett bra tips att definiera dina entiteter och skapa en tabell per varje, så i det här fallet har du användare och spellistor och låtar (till exempel). Definiera dina tabeller så här; ANVÄNDARE, LÅT, SPELLISTA.

Nästa sak är att definiera namnen på fält och tabeller (och kanske är de förenklade namnen som föreslagits ovan, ja, förenklade). Vissa introducerar falska namnrymder (dvs. MYAPP_USER istället för bara USER), särskilt om de vet att datamodellen kommer att utökas och expandera i samma databas i framtiden (eller, vissa för att de vet att detta är oundvikligt), medan andra bara kommer att gå igenom vad de än behöver.

Den stora frågan kommer alltid att handla om normalisering och olika problem kring det, balanserar prestanda mot tillämplighet, och det finns massor av böcker skrivna om detta ämne, så jag kan inte ge dig något vettigt svar, men kärnan i det för mig är;

Vid vilken tidpunkt kommer ett datafält i en tabell att vara värdigt sin egen tabell? Ett exempel är att du mycket väl skulle kunna skapa din applikation med bara en tabell, eller två, eller 6 beroende på hur du vill dela upp din data. Det är här jag tror att din fråga verkligen kommer in.

Jag skulle säga att du har ganska rätt i dina antaganden, det du bör tänka på är konsekventa namnkonventioner (och det finns massor av åsikter om hur man namnger identifierare). För din ansökan (med tabellerna ovan) skulle jag göra;

USER { id, username, password, name, coffee_preference } 
SONG { id, artist, album, title, genre } 
PLAYLIST { id, userid } 
PLAYLIST_ITEM { id, songid, playlistid, songorder }

Nu kan du använda SQL du får alla spellistor för en användare;

   SELECT * FROM PLAYLIST WHERE userid=$userid

Eller få alla låtar i en spellista;

   SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder

Och så vidare. Återigen har böcker skrivits om detta ämne. Det handlar om att tänka klart och semantiskt samtidigt som man skriver ner en teknisk lösning på det. Och vissa människor har bara detta som en karriär (som DBA's). Det kommer att finnas många åsikter, speciellt om det jag har skrivit här. Lycka till.



  1. Rekonstruera Standby DB

  2. 2 sätt att ta bort dubbletter av rader i MariaDB (ignorerar primärnyckel)

  3. Hur anger du ett annat portnummer i SQL Management Studio?

  4. När ska SQL_NO_CACHE användas