Kom ihåg mig?
Home Menu

Menu


Optimera MySQL

 
Ämnesverktyg Visningsalternativ
Oläst 2011-03-14, 11:28 #1
Adestro Adestro är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Apr 2007
Inlägg: 1 036
Adestro Adestro är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Apr 2007
Inlägg: 1 036
Citat:
Ursprungligen postat av ConnyWesth Visa inlägg
Att optimera prestanda är inget självändamål.

När man bygger en databasstruktur i en relationsdatabas så är det viktigaste att man får en inbyggd kvalitetskontroll på informationen man lagrar.

Då är naturliga primärnycklar en naturlig del av det arbetet. Främmande nycklar som då länkar till primärnycklar är en annan del. Atomära egenskaper ytterligare en. Att följa normalformernas definitioner ytterligare en.

Att använda syntetsiska primärnycklar ska manundvika och endast använda i de fall när det inte finns en naturlig primärnyckel eller där en naturlig primärnyckel kommer att bestå av orimligt många kolumner (typ; >7 kolumner).

Den "prestandavinst" man vinner på att använda syntetiska PK är oftast så marginell att den inte är värd att beakta, i de flesta fall. Man förlorar så otroligt mycket mer vad gäller den inbyggda kvalitetskontrollen av information när man gör det.

Använder man naturliga PK så kan man som människa utföra okulärbesiktning av data på ett enklare sätt än med syntetiska PK. Du kan m a o direkt se om set står NOK i en kolumn där du för väntar dig att det ska stå SEK, men om det står 4 i stället för 7 så finns det inget naturligt sätt för en människa att avgöra om informationen är korrekt eller inte. Man måste ha mycket mer komplexa sätt att kontrollera om informationen är korrekt och det innebär att det är lättare att man får strukturella fel i sin databas och sina applikationer.
Databasen administreras ju förhoppningsvis inte i en texterminal.

Vilken databasdesign som passar bäst beror ju på hur databasen ska användas. Men använder man ett RDBMS är man antagligen intresserad av att efterleva ACID. Annars ska man nog titta på andra databassystem med andra sätt att lagra data.

Du säger: "När man bygger en databasstruktur i en relationsdatabas så är det viktigaste att man får en inbyggd kvalitetskontroll på informationen man lagrar.". Det är ju just det man åsidosätter genom att göra som du föreslår? Genom att acceptera redundans ber man om dataanomalier i databasen. För att inte tala om prestandakostnaden att i beräkningar jämföra VARCHAR med VARCHAR jämfört med INT med INT...

Senast redigerad av Adestro den 2011-03-14 klockan 18:39
Adestro är inte uppkopplad   Svara med citatSvara med citat
Oläst 2011-03-14, 11:46 #2
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Citat:
Ursprungligen postat av Adestro Visa inlägg
Datan administreras ju förhoppningsvis inte i en texterminal.

Vilken databasdesign som passar bäst beror ju på hur databasen ska användas. Men använder man ett RDBMS är man antagligen intresserad av att efterleva ACID. Annars ska man nog titta på andra databassystem med andra sätt att lagra data.

Du säger: "När man bygger en databasstruktur i en relationsdatabas så är det viktigaste att man får en inbyggd kvalitetskontroll på informationen man lagrar.". Det är ju just det man åsidosätter genom att göra som du föreslår? Genom att acceptera redundans ber man om dataanomalier i databasen. För att inte tala om prestandakostnaden att i beräkningar jämföra VARCHAR med VARCHAR jämfört med INT med INT...
Det märks att du inte vet hur relationsdatabaser fungerar. Man garanteras att inga anomalier inträffar när man använder naturliga PK, det har du inte när du använder syntetiska PK. Redundans blir det inte om man använder naturliga PK. Själva nyckeln i sig kan aldrig dubbellagras.

Det där med texterminal förstod jag inte? Jag använder grafiska verktyg att analysera data med.

Senast redigerad av Conny Westh den 2011-03-14 klockan 12:10
Conny Westh är inte uppkopplad   Svara med citatSvara med citat
Oläst 2011-03-14, 13:19 #3
tartareandesire tartareandesire är inte uppkopplad
Supermoderator
 
Reg.datum: Jan 2004
Inlägg: 11 585
tartareandesire tartareandesire är inte uppkopplad
Supermoderator
 
Reg.datum: Jan 2004
Inlägg: 11 585
Citat:
Ursprungligen postat av ConnyWesth Visa inlägg
Det märks att du inte vet hur relationsdatabaser fungerar. Man garanteras att inga anomalier inträffar när man använder naturliga PK, det har du inte när du använder syntetiska PK. Redundans blir det inte om man använder naturliga PK. Själva nyckeln i sig kan aldrig dubbellagras.

Det där med texterminal förstod jag inte? Jag använder grafiska verktyg att analysera data med.
Det där är en mycket gammalmodig och stelbent inställning som inte har i modern webbutveckling att göra. Ja, att undvika redundans är självklart bra MEN att stirra sig blind på att använda naturliga PK är helt fel väg att gå idag (därmed inte sagt att naturliga PK i sig är dåligt). Att spara resurser och prestanda är betydligt viktigare på vältrafikerade sajter vilka blir allt fler i takt med att internet breder ut sig. Dessutom ligger det på alla programmerares ansvar att skapa så resurssnåla system som möjligt. IT är tänkt att vara ett grönare och mer miljövänligt alternativ men då måste också alla hjälpa till och inte fastna i gamla mönster och vanor. Idag förbrukar branschen enorma resurser trots allt bättre teknik och det gäller att tänka lite längre.

Nej, det där tänket bör förpassas till det förgångna en gång för alla.
__________________
Full-stack developer, free for smaller assignments

Senast redigerad av tartareandesire den 2011-03-14 klockan 14:00
tartareandesire är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 16:58.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017