Labb LABB 11 MIN LÖSNING Blocket-databas Plushögskolan Frågeutveckling inom MSSQL - SU14
Detta är min lösning till labb 11, det blir en del att läsa men å andra sidan så gav uppgiften en hel del att tänka på :) Först min standard disclaimer när det gäller sådana uppgifter. Detta är min lösning, det är inte den enda sanna kanoniska allena rådande lösningen. Nog om det Hmm jag ser nu att jag borde ha kört rättstavning på labb11 :( Här är min lösning. Lösning Bakgrund... 2 Grundmaterialet... 3 Normalisering... 5 Persontabellen:... 5 Varutabellen:... 5 Försäljning:... 5 Kvitto och betyg:... 5 Övriga tabeller... 5 er... 6 Persontabellen:... 6 Varutabellen:... 6 Försäljning:... 7 Kvitto och betyg:... 7 Övriga tabeller... 7 Indexering... 9 Persontabellen:... 9 Varutabellen:... 9 Försäljning:... 9 Kvitto och betyg:... 9 PM... 9 Städer... 9 Foto... 9 Vyer... 10 Slutsats... 11 SELECT 1 as [PageNumber];
Bakgrund För några år sen blev jag kontaktad av en egenföretagare som ville skapa en ny variant av blocket. Den skulle fungera liknande, men den skulle inte ha kluddiga registrerings- och inloggningsfunktioner. Det skulle vara enkelt att skapa användarnamn och sen var man inne och kunde sälja och köpa. Jag spenderade alltså ett par timmar med att försöka förklara att det finns något som kallas Scammers och hälare som med glädje skulle uppskatta hans sida utan krav på identifiering. Det gick inte igenom för honom, man måste beundra hans tro på människans goda vilja, men jag valde att inte ta på mig uppdraget. SELECT 2 as [PageNumber];
Grundmaterialet Listan med de 4 områden som vi ska hålla reda på är ganska enkel och vanlig. För att reda ut röran behövs några antaganden. Jag brukar skriva upp mina antaganden som en lista och sortera dem efteråt. Antagande Alla kan vara säljare och köpare Ska alla fält anpassas till respektive typ? Ska mått anges som en sträng eller decimaler? Vikt kan vara bra att ha i decimaler om man ska räkna ut vad portot ska bli. Pris, ska det vara money eller smallmoney, decimal eller bara en int? Namn, adress och presentation, hur stora ska de vara? Hur ska foton sparas? Varornas foton kommer att bytas ut ofta, då annonserna försvinner efter en tid, det kanske skulle underhållsarbete att ha dem i databasen. När posten raderas så försvinner bilden. Ska Genomfört vara en bool? Slutsats Samma tabell kan användas till köpare och säljare Då detta är en databas som ska användas mest för att visa data, så behövs inte någon riktig exakthet i decimaler och annat. Keep it simple! Mått anges ofta i form av höjd x bredd, det kanske är lika bra att låta det vara en string Vettigt argument faktiskt. Vikt kan vara decimal (10,2) Undrar om någon säljer varor på en sådan site i prisform 17:50, 27:90 osv En int borde räcka, men för att vara på den säkra sidan, så varför inte smallmoney. Tror inte det någonsin kommer att säljas något över 214000 men det tar plats i databasen att ha större värden, så smallmoney får duga. Namn och adress borde räcka om de är uvarchar(100), Presentationen borde begränsas i storlek, men det kan man bestämma i C#. Alltså får den bli uvarchar(max) Profilfoton finns kvar rätt länge, så de kan laddas upp till en mapp med just profilfoton. När en ny bild laddas upp så raderas den gamla (exempelvis) Det kan spara tid i underhåll, men det kan orsaka laddningstid om bilden är för stor. Då den ska hämtas från databasen, omvandlas och visas upp. En temp-mapp är bättre. Det beror på hur många steg man vill kolla upp. Man skulle kunna ge den flera värden istället för att begränsa sig till 3 Null = opublicerad 0 = publicerad 1 = Köp pågår 2 = Köp abrutet 3 = Köp avslutat SELECT 3 as [PageNumber];
Det beror helt och hållet på programmeraren, så för att inte begränsa statusen så kör vi på en tinyint. Då har programmeraren 255 olika flaggor att skapa en enum på. Publiceringsdatum, ska det bara vara datum eller också tid? Ska betyget sparad i försäljningstabellen? Som nyfiken person vill jag gärna veta tiden, så datetime får det bli. Nja, om man sparar den där måste man även spara varuposten, annars kommer den att peka på null vara. Det är kanske bättre att gå på Alexis-tankebana och skapa en tabell med kvitto. SELECT 4 as [PageNumber];
Normalisering Nu när jag vet ungefär vilka typer jag ska använda så ska jag nu välja Persontabellen: Den ska innehålla persondata (användarnamn, lösenord, Riktig namn, epost, telefonnummer, adress, postnummer, stad, foto, presentation), men inte stad. Då man söker ofta på stad så vill jag ha staden i en tabell för sig. På så sätt kan jag också begränsa olika stavningar på städer. (Malmö, Malmo, Malmoe, Mälmo osv). Bilderna får sparas i en tempmapp, varchar(50) borde räcka som filnamn om man stoppar in en UID + filändelse. Dock ska persontabellen bara innehålla en foreign key till bilden. Varför undrar du? Jo, för att man kan göra en right join på Persontabellen och bilder, alla bilder som har null från persontabellen är inte kopplade till profil och kan därmed raderas. Lätt att underhålla med andra ord. Varutabellen: Här ska vi bara ha beskrivning på varan, egentligen samma uppbyggnad som Persontabellen (Annonstitel, Namn på varan, beskrivning, pris, vikt, längd x bredd, publiceringsdatum, foto, länk). Även här hamnar foton i en specifik mapp på hårddisken. Försäljning: Den här tabellen är egentligen en kopplingstabell bara. Men den ska ha ID till säljaren, köparen, varan, försäljningsstatus. Kvitto och betyg: När försäljningen är genomförd kan ska man skapa ett kvitto. Dit kan man kopiera Varans namn, Pris, fylla i försäljningsdatum, Säljarens ID och Köparens ID, och självklart där kan man betygsätta säljare och köpare. Betygen ska kanske också ha en varchar(300) för att ge folk möjlighet att förklara betyget. Övriga tabeller Det kommer att behövas en tabell för PM så att säljare och köpare kan kommunicera. Stad tabell måste också finnas, som sagt Och självklart en fototabell. SELECT 5 as [PageNumber];
er Nu när jag vet ungefär hur jag ska bygga upp databasen, så är det dags att planera datan. Persontabellen: PersonID Användarnamn Lösenord Email Telefonnr GatuAdress Postnummer Fk_stad Fk_foto Presentation bigint Exempel: HashBytes('SHA1', 'MyPassword'); Int Int Varchar(max) Varutabellen: VaruID Annonstitel Varunamn Beskrivning Pris Varchar(100) Varchar(max) Smallmoney Vikt Decimal (10,2) Mått Publiceringsdatum Fk_foto Länk DateTime bigint Varchar(100) Är länken större än 100 tecken, hänvisa till shorturl.com SELECT 6 as [PageNumber];
Försäljning: FörsäljningsID Fk_säljare Fk_köpare Försälningsstatus (aka genomförd) Tinyint Kvitto och betyg: KvittoID Vara Pris Försäljningsdatum Fk_säljare Fk_köpare Betyg_säljare Betyg_säljare_text Betyg_köpare Betyg_säljare_text Smallmoney Datetime Tinyint Varchar(300) Tinyint Övriga tabeller PM PM_ID Fk_sender Fk_reciever Fk_prevmessage (recursive foreign key) * prevmessage hänvisar till ett meddelande i PM tabellen SELECT 7 as [PageNumber];
Städer StadID Stad Int Foto FotoID Sökväg Int Varchar(100) SELECT 8 as [PageNumber];
Indexering Nu när jag har tabellerna så ska jag välja indexering. Jag gör det enkelt för mig och sätter alla Primary Keys som standard indexerade, alltså blir de clustrade och jag vet om att tabellerna kommer att hållas städade i hårddisken. Persontabellen: Index på namn, epost och telefonnummer (var för sig) är nog bra att ha. Det är oftast det man söker på. Varutabellen: Index på Annonstitel, Namn, var för sig. Den här tabellen ändras ofta, så clustered index på nyckelfältet är kanske inte så nödvändigt. Försäljning: Denna ändras också ofta, så clustered index på nyckelfältet skulle nog göra den långsammare. Kvitto och betyg: Kvittot ska indexeras på VaruNamn, datum, säljarens ID och köparens ID, var för sig. PM Primary key index räcker gott och väl, men för att snabba upp filterandet så fk_sender och fk_reciever kan få sitt eget index. Städer Stad tabell klarar med primary key index Foto Foto klarar sig också med primary key index. SELECT 9 as [PageNumber];
Vyer Vilka vyer kan behövas? 1. Senaste publicerade varor per stad 2. Alla varor per stad 3. Alla varor per säljare och stad 4. Specifik vara 5. Toppsäljare 6. Profil med presentation, foto och betyg 7. Betyg och kommentarer för en viss person 8. Foton som saknar koppling till person eller vara 9. Kvitton per säljare 10. Kvitton per köpare Och generiska sökningar 1. Alla varor 2. Alla säljare 3. Alla säljare och varor Ska vyerna indexeras? Behövs det? Finns nog bara ett sätt att veta att prova och se. SELECT 10 as [PageNumber];
Slutsats Nu har databasen en grund till att kunna fungera för försäljning. Dock ska man vara redo att fler förändringar kan ske, mest att nya tabeller uppkommer. Men för detta labb räcker det gott och väl med den uppbyggnaden av tabeller. /m SELECT 11 as [PageNumber];