sql >> Databasteknik >  >> RDS >> Mysql

Ska jag normalisera min DB eller inte?

Ett filosofiskt svar:Suboptimala (relationella) databaser är fulla av infoga, uppdatera och ta bort anomalier. Dessa leder alla till inkonsekventa data, vilket resulterar i dålig datakvalitet. Om du inte kan lita på riktigheten i dina uppgifter, vad hjälper det då? Fråga dig själv detta:Vill du ha rätt svar långsammare eller vill du ha fel svar snabbare?

Som en praktisk fråga:gör det rätt innan du får det snabbt. Vi människor är väldigt dåliga på att förutse var flaskhalsar kommer att uppstå. Gör databasen bra, mät prestandan under en anständig tidsperiod och bestäm sedan om du behöver göra den snabbare. Innan du avnormaliserar och offrar noggrannheten prova andra tekniker:kan du få en snabbare server, anslutning, db-drivrutin, etc? Kan lagrade procedurer påskynda saker och ting? Hur är indexen och deras fyllnadsfaktorer? Om dessa och andra prestanda- och stämningstekniker inte gör susen, överväg först då denormalisering. Mät sedan prestandan för att verifiera att du fick den hastighetsökning som du "betalade för". Se till att du utför optimering, inte pessimisering.

[redigera]

A:Visst.

  1. Gör en säkerhetskopia.
  2. Gör en ny säkerhetskopia till en annan enhet.
  3. Skapa nya tabeller med kommandon "välj till ny tabell från gammal tabell...". Du måste göra några kopplingar för att kombinera tidigare distinkta tabeller.
  4. Släpp de gamla tabellerna.
  5. Byt namn på de nya tabellerna.

MEN ... överväg ett mer robust tillvägagångssätt:

Skapa några vyer på dina helt normaliserade tabeller just nu. Dessa vyer (virtuella tabeller, "fönster" på data... fråga mig om du vill veta mer om detta ämne) skulle ha samma definierande fråga som steg tre ovan. När du skriver din applikation eller DB-lagerlogik, använd vyerna (åtminstone för läsåtkomst; uppdateringsbara vyer är... ja, intressant). Om du sedan avnormaliserar senare, skapa en ny tabell enligt ovan, släpp vyn, byt namn på den nya bastabellen oavsett vad vyn var. Din applikation/DB-lager kommer inte att känna skillnaden.

Det finns faktiskt mer i detta i praktiken, men det här borde få dig igång.



  1. Varför använda främmande nycklar utan åtgärd vid radering eller uppdatering

  2. Felsökning av långvariga frågor i MS SQL Server

  3. Tabelltyp i Oracle PL SQL Exempel

  4. Hur tar jag bort emoji-tecken från en sträng?