Jag håller på med en teknisk spec av en databas. Har bara skrivit specar för hemsidor förut så jag vet inte riktigt vad jag ska ha med... Så här ser det ut nu
Databas: Access
Gränssnitt: Web
Syfte: Produktkatalog
Databaskoppling: OLEDB
Lista på tabeller + alla fält i varje tabell
Lite om varför den är uppbyggd som den är
Vad behövs mer? Hur man anropar databasen, exempel på SQL-satser, hur data loopas ut med ASP?
Databasfälten beror till viss del på vad det är för produkter som ska presenteras och i vilket sammanhang...
Grundregel
1. Allt du skriver ska EJ vara kopplat till detta projektet.
Du måste kunna återanvända så mycket som möjligf ia alla andra tänkbara sammanhang. Skriv inte kundens namn i kod och text, döp inte tabeller som relaterar till kunden eller ditt företag.
Jag skulle säga att det har mycket med designen att göra också.
***
För övrigt är jag en stor påhejare av den här typen av trådar!
Longshot
Här är dokumentationen för en e-handelsplats, modell enkel. Idag använder jag fältnamn av typen intID, strName osv. så du får se nedanstående som ett utgångsläge att fiska idéer från.
Det är bra att tänka själv, därför ska jag inte ge dig mer hjälp än nöden kräver. Jag kräver att du INTE använder mina namn för de suger fett! :-)
[prodBrand] olika produktgrupper
x_ID
x_name 50
x_sortfield tal
x_view boolean
[products]
x_ID
x_selectID tal
x_brandID tal
x_date datum
x_name 255
x_price valuta
x_shipping valuta
x_sortfield tal
x_view boolean
x_viewTo datum
x_text PM
x_imageLow1 text, 100 - sökväg till liten bild
x_imageHigh1 text, 100 - sökväg till större bild
x_imageLow2 text, 100 - sökväg till liten bild
x_imageHigh2 text, 100 - sökväg till större bild
x_width tal - bredd och höjd på den mindre bilden
x_height tal
x_pdfName text, 50
x_pdf text, 100 - sökväg
x_wordName text, 50
x_word text, 100 - sökväg
[shopper] håller ordning på alla inköp, själva 'korghanteraren'
x_ID
x_date datum
x_sessionID tal
x_productID tal
x_quantity tal
Själva handlandet går till så att då man klickat på "lägg i korg" så kollas databasen mot session ID och detta blir alltså användarens unika ID.
Är kvantitet = 0 då tas posten bort, i annat fall blir det en ny post för varje ny vara.
Jag vet inte riktigt hur folk brukar göra då de gör en shop, den här varianten är nog inte så vanlig. Jag tyckte det var lite enklare att börja på detta sättet, det blir lite mer konkret, lite att ta på, liksom!
Givetvis kan man spara den här typen av data som sessioner men det blir så himmla svårt att hålla reda på alla data. Man måste tänka på dokumentationen och det faktum att man måste kunna förstå koden helst på direkten efter lång tid.
Det är över två år sedan detta projektet och jag kan posta koden på forumet med gott samvete!
Jag vet att det inte var en shop du skulle göra men skillnaden mellan en shop och en produktkatalog är väl obefintlig... Men om du gör en ordentlig produktkatalog kan du enkelt koppla en shop till den i efterhand.
(oups! har du inget liv på en lördag eller... ;-) )
Pace, korrekt.
Standard SQL fungerar utan modifikation rakt av i Access och MS SQL Server. (Enklare grejer) Med lite modifikation här och där fungerar det i PHP med MySQL.
Jag är osäker på varför man ska skriva kod i dokumentationen?? Vad tillför det!? Jag har aldrig sett det... Självdokumenterande kod är bättre! :-)
Heja Cecilia Tänk om fler inom IT värden ville(kunde) göra en enkel skiss på vad som skall byggas.
Vill att vi hamnar där arkitekter och byggare är idag.
Skall följa upp denna tråd.
Heja Cecilia Tänk om fler inom IT värden ville(kunde) göra en enkel skiss på vad som skall byggas.
Eh, vet inte vilken del av IT-världen du befinner dig i, men i den del jag befinner mig i så görs det mer än bara enkla "skisser" över vad som skall byggas.
Ett seriöst projekt börjar med en analysfas, sedan makro- och mikrodesign, därefter utveckling med enhetstester och sist en testfas med acceptanstest.
Databasdelen går in i mikrodesignen. Vilken databas det är lär man redan ha ställt upp i kravspecifikationen, syftet med databasen torde stå rätt klart i detta skede, så även gränssnittet. Det jag främst vill se är en databasmodell vilket är ett grafiskt schema över databasens struktur som är trevlig att ha som utvecklare samt beskrivning av tabellernas funktion och relationer samt hur dom används.
Ecplise grundregel att "allt du skriver ska EJ vara kopplat till detta projektet" förstår jag inte, saknar relevans, det är inte ofta man återanvänder en databasstruktur rakt av, i vart fall inte i större projekt.
Ett seriöst projekt börjar med en analysfas, sedan makro- och mikrodesign, därefter utveckling med enhetstester och sist en testfas med acceptanstest.
Tjena mittbena! Det är möjligt att det går till så i varje projekt på det företaget du arbetar på. Däremot kan jag säga att det vinns väldigt många företag och pojekt som faktureras med vinst men som inte är fullt så kvalificerade som det du beskriver.
Ecplise grundregel att "allt du skriver ska EJ vara kopplat till detta projektet" förstår jag inte, saknar relevans, det är inte ofta man återanvänder en databasstruktur rakt av, i vart fall inte i större projekt.
Det är riktigt. Vi använder inte heller något "rakt av". Däremot utgår vi från att kod återanvänds i senare projekt. Det blir som olika moduler man bygger.
Jag vet att man gärna vill ändra lite. Det är inte så troligt att man vill använda två år gamla grejer även om det skulle vara samma sak man gör! Ska man ändra för mycket kan man lika gärna skriva om allting!
Våra projekt är medvetet framtagna så det ska gå snabbt och enkelt att även ändra både i kod och dokunemtation.
Ja... givetvis beror det helt på vad det är för något man gör! På mindre grejer går det kanske bättre, på mer komplexa projekt är det kanske inte möjligt!
274 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
