Webbutvecklingur Utveckling - Övrigt
10 svar · 616 visningar · startad av Noob
Hej gubbs å girls!
Jag har suttit i en del timmar nu och försökt komma fram till den optimala lösningen för tabeller, kolumner och kopplingar för att göra databasen så proffsig som möjligt... Varför? Jo jag gick en fyraveckors grundkurs i ASP och Databas i skolan och läraren tutade i mig att det var jätteviktigt att man tänkte rätt från början när man skapade sina relationsdatabaser så det skulle ta mindre plats, vara enklare att indexera och bli smidigare att använda.. Men hur mycket skall man stirra sig blind på detdär?
Jag tycker att jag bara krånglar till det ibland med att lägga ut vissa värden i egna tabeller och koppla dem med varandra.. Så då ångrar jag mig och lägger tillbaks dem i samma tabell igen.. men sen tillbaks i en egen tabell igen.. jag vet ju inte hur jag ska göra..
Hur många poster börjar vi snacka om innan det märks nån skillnad i prestandan i databasen?
Kan det inte bli tvärtom att för många tabeller innebär krångligare SQL-frågor och fler databaskopplingar å det i sin tur belastar web-serverns prestanda?
Just nu kör jag IIS 5.1 och MS Acess 2000... Och min databas ska i slutändan innehålla en massa olika drinkar med deras ingredienser, mått, tillvägagånssätt osv.. Men sen börjar man tänka till lite mer och då vill man ju dela in drinkar i kategorier(cocktail, longdrink, kaffedrink osv) och dels vilken spritbas det är i dem osv.. sen kan man koppla en tabell till med olika glas som används och ytterligare en tabell med olika redskap som kan användas för att göra drinken... varför inte då lägga alla ingredienser i en tabell och koppla ihop dem med ett drinknamn i en tabell och där bestämma måtten.. till slut känns det som det blir krångligt att presentera allt på en websida... eller tänker jag helt fel? blir det enklare ju mer uppstyckad datan är?
Det känns krångligare att lägga till data i databasen iaf.. Jag tycker ändå att jag ver ungefär vad det är jag vill lagra i databasen, men hur skall jag lägga upp det i tabeller och kopplingar?
Vad skall man lägga vikten på? Hur pet-noga skall man vara?
Re: Noga med databasmodulering?
Noob skrev:
Hur pet-noga skall man vara?
Det är ungefär som med måleri. Först lär man sig tekniken perfekt och målar med skärpa och briljans efter konstens alla regler. När du väl är kung på det, ja då kan du måla hur fan du vill och ändå vara kung.
;)
Du ska ju vara petnoga med att moddelera det du ska presentera/verksamheten/verkligheten/behoven på ett korrekt sätt, då finns det inte så otroligt många olika sätt att lösa det hela på rent DB-arkitekturmässigt. Jag börjar med UML och efter det översätter jag det så gott det går till en databas, eftersom relationsdatabaser inte har stöd för alla saker UML har stöd för.
Ska man bara slänga ihop något haffsigt så är det som Clarkbones säger samt att erfarenheten man har sedan tidigare bara ligger där. Övning ger färdighet, du kan ju normalisera allt till absurdum men det behövs aldrig utan det gäller att hitta en lösning som passar ändamålet. Mitt råd är att kolla exakt hur allt ska representeras, vad man ska kunna göra etc, där har du grunden för hur du ska modellera din db
Är man inte noga från början, blir det rätt slitsamt när man upptäcker att man modellerade basen fel.
Noob skrev:
varför inte då lägga alla ingredienser i en tabell och koppla ihop dem med ett drinknamn i en tabell och där bestämma måtten..
Ja, varför inte? Nu är jag inte så hemma på drinkar. Det kanske är tillräckligt för att täcka behoven som finns när man ska lagra drinkrecept? Det vet du nog bättre.
Om man ska dela in drinkarna i kategorier, skulle jag välja en enda stor drinktabell. Vid sidan skulle jag ha en kategoritabell. Sedan får drinktabellen referera till kategoritabellens olika kategorier. Då har du en enda enkel drinktabell, samtidigt som du kan sortera drinkarna utifrån vilka kategorier de tillhör. Skulle du ange kategorierna i klartext i drinktabellen, finns det utrymme för felaktigheter, som att någon har stavat ett kategorinamn fel. Då spricker den sorteringen.
Angående spritbas, känns det som om spriten helt enkelt är en av ingredienserna. Eftersom du ändå hade tänkt ha en tabell för ingredienser redan, känns det som att du redan har en lösning på det problemet.
Angående din databas; såhär hade nog jag gjort.
tblIngredient
IngredientId - PK
IngredientName
IngredientTypeId - FK
tblIngredientType
TypeId - PK
TypeName
tblDrink
DrinkId - PK
DrinkName
DrinkDescription
DrinkCategoryId - FK
tblDrinkCategory
CategoryId - PK
CategoryName
tblDrinkIngredient
DI_DrinkId - FK
DI_IngredientId - FK
DI_Quantity
DI_UnitId - FK
tblUnit
UnitId - PK
UnitName
De två mest centrala tabellerna, tblDrink och tblDrinkIngredient, håller den viktigaste datan. tblDrinkIngredient ser till att bestämma vilken drink (DI_DrinkId) som innehåller vilka ingredienser (DI_IngredientId, en ingrediens per rad), antal enheter (DI_Quantity) och vilken enhet det handlar om (DI_UnitId). tblUnit kan innehålla t.ex. ml, cl, msk, tsk eller andra liknande drinkmått. Vidare; tblIngredientType är till för att dela upp ingredienserna i olika typer, som t.ex. Alkohol, Likör, Färgämne, Frukt, Spädricka osv.
En ganska enkel regel som jag slaviskt följer är att aldrig spara samma data på två eller fler ställen.
Med hjälp av databasnormalisering (alltså att få din databasstruktur att följa en viss "standard" på uppbyggnad) är detta det mest optimala sättet att lagra data. Lägg därför mycket energi på att göra en bra struktur för din databas, snarare än att om några månader framöver gå ifrån "all data i en tabell" till en korrekt använd relationsdatabas.
Kan också tillägga att det finns en mening varför ordet "relation" finns med i ordet relationsdatabas. ;)
Pace, jag håller inte riktigt med om att följa det slaviskt. Ibland finns inte behov för att samma data inte kan få finnas på flera ställen, även om det oftast blir det. Kan tex ta en sak som ort, kanske inte alltid behov av att ha en separat tabell med en miljard poster i enbart för att normalisera ut Ort och få mindre redundans i dbn.
Men en bra grundregel är det ;)
erka skrev:
Pace, jag håller inte riktigt med om att följa det slaviskt. Ibland finns inte behov för att samma data inte kan få finnas på flera ställen, även om det oftast blir det. Kan tex ta en sak som ort, kanske inte alltid behov av att ha en separat tabell med en miljard poster i enbart för att normalisera ut Ort och få mindre redundans i dbn.
Men en bra grundregel är det ;)
Jag håller inte riktigt med dig heller, bara nästan. ;)
Om du har ett adressregister för dina kunder (som Du underhåller!) där du har avancerad sökningar och matchningar med hjälp av ortnamn är det betydligt bättre att relatera datan.
Om vi snackar ett enklare form av register räcker det såklart med att lagra ortsnamnet i en egen kolumn, speciellt om användaren själv ska kunna ange det (som här på webForum). Men så fort man ska göra matchningar (jämför platsbanken på AMS) så är relationer betydligt smidigare, om inte nödvändigt.
Jag använder båda varianterna nämnda ovan, så lite fel var det kanske att skriva "följa slaviskt". :p ;)
Ok, nu har jag fått olika svar på samma fråga.. gå tillbaks till ruta gå.. =) hehe.. ne men jag tror jag förstår vart dethär leder - "gör som du känner, du fixar biffen i vilket fall"... men de e ok.. jag förstår att alla har olika sätt att lösa det på.. jag får helt enkelt testa olika sätt att bygga det hela.. jag menar - hur annars ska man lära sig allt om inte genom att testa på allt! =)
Pace, där har du ett exempel där man ska normalisera, absolut. Men vad jag ville påpeka var att normalisera inte bara för sakens skull. Jag skrev, "kanske inte alltid behov av att ha en separat tabell". Man måste kolla på vad det ska användas till, vi är helt överens där, förstår inte vad du menar med
"Jag håller inte riktigt med dig heller, bara nästan. " ;)
Anpassa normaliseringen efter applikationens nuläge, inte för framtiden för du vet ändå inte vart den bär dig. Lyckas du med det och normaliserar till en sådan grad att databasmodelleringen representerar applikationens datastruktur korrekt kommer det dock vara bra förutsättningar för framtida förändringar.
Oavsett vad soms sägs om normalisering finns det även en form av denormalisering som just tar hänsyn till snabbhet i utskrifter och liknande. Ingen kan följa normaliseringsregelr till fullo. Doch är nycklar en viktig sak att tänka på.
Jag tycker att tidsaspekten ofta försummas.
