Läst

[mad_and]

Hur gör man för att ange om ett inlägg i ett forum är läst eller oläst?

 

[lillen_009]

lägg till en ny kolumn i db:n som du kallar tex status.

 

[Magnus Gladh]

lägg till en ny kolumn i db:n som du kallar tex status.

 

Problemet är ju att så fort en person har läst det, så kommer det att vara läst för alla så fall.

 

Vanligast är nog att man skapar en extra tabell i databasen där du sparar ner ID på posten och ID på användaren.

 

Sedan när man hämtar ut posten så kollar man i denna extra tabell om användaren redan har läst den. Och har man inte det, och läser posten så lägger man till en rad i denna tabell.

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!

 

[lillen_009]

Problemet är ju att så fort en person har läst det, så kommer det att vara läst för alla så fall.

 

Ahh, å tolkade jag inte frågan... Han/hon skriver "att om ett inlägg är läst eller oläst". Har en person läst det, så borde det vara läst Förtydligande kanske behövs...

 

[JANspeed]

Skapa ett kolumn som heter views eller nått i den lagrar du ID:t på alla poster denne läst. Sen använder du bara If InStr() för att ta reda på om denne läst posten. Alternativt gör du selecteringen redan i sökningen.

 

/JANspeed

 

 

[Magnus Gladh]

Skapa ett kolumn som heter views eller nått i den lagrar du ID:t på alla poster denne läst.

 

Det bryter mot databasdesignens grundregler att data skall vara "Atomic". Alltså endast innehålla så lite data som möjligt.

 

Men visst det är en lösningen, om än dålig.

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!

 

[JANspeed]

Det gör den ju? Den innehåller ju bara de inlägg man besökt?

 

Alternativet är ju att du börjar bygga en relationstabell och det kan väl knappast betyda mindre data? Då måste man ju börja fiffla med andra ID och liknande också. Det betyder ju inte mindre data precis. Prestandamässigt går det nog inte så snabbt heller.

 

Men är man rädd att det finns för mycket data så får man väl tömma fältet efter ett tag?

 

För övrigt så är aldrig mina lösningar dåliga. ;p

 

 

/JANspeed

 

 

[inlägget ändrat 2003-12-03 09:24:05 av JANspeed]

[mad_and]

Nja jag - som startade tråden - visste faktiskt inte riktigt vad som är standard. Så jag är tacksam för båda versionerna dvs. för en enskild besökare och för alla tillsammans.

 

[Magnus Gladh]

Det gör den ju? Den innehåller ju bara de inlägg man besökt?

 

Som sagt, det bryter mot databasdesignen, det spelar ingen roll att den endast innehåller de inlägg som man har läst, den kommer att innehålla mer än ETT id, och alltså bryter den mot ACID som definerar hur man skall designa sin databas.

 

Alternativet är ju att du börjar bygga en relationstabell och det kan väl knappast betyda mindre data?

Det har inget att göra med att det finns mindre data, det får finnas hur mycket data man vill så länge man följer rätt riktlinjer. Problemet är att du med din lösning inte kan använda dig av databasens inbyggda funktioner så som JOINS och RELATIONER, eftersom du kommer at flera id i samma fält. Och du kommer märka hur dålig lösningen är när man försöker bygga ut den lite mer, som att man skulle vilja se just vid vilken tidpunkt som man läste posten, det kan du inte i din lösning utan att komplicerar det riktigt mycket. En korrekt lösning kräver endast att man lägger till en Datekolumn och sätter ett default värde på den.

 

Prestandamässigt går det nog inte så snabbt heller.

En korrekt databas design är kanske inte alltid optimerad för prestanda, och därför kan man tillåta att bryta lite på den genom att dubbellagra information, men det du föreslår ligger utanför rammarna vad man får göra.

 

Men är man rädd att det finns för mycket data så får man väl tömma fältet efter ett tag?

Det var ju en lyckad lösning, då tappar man ju finessen med att ha en markering på att ett inlägg är läst.

 

För övrigt så är aldrig mina lösningar dåliga. ;p

Du har rätt, den var inte dålig, den var riktigt usel.

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!

 

[inlägget ändrat 2003-12-03 13:01:57 av Magnus Gladh]

[JANspeed]

alltså bryter den mot ACID som definerar hur man skall designa sin databas.

 

Då kan ju du följa dina begränsande regler medans vi andra bygger applikationer som utför det de ska göra utan att dra ner för mycket på prestanda vilket troligtvis är något som är rätt viktigt. Vilket vi bevisligen får se dagligen på eforum.

 

Själv tror jag mer på syftet med en viss lösning snarare än att följa regler slaviskt. Visst kan du börja bygga en massa flashiga tabeller med relationer kors och tvärs. Ibland håller det och förbättrar prestandan men ibland så förvärrar det bara och slöar ner.

 

Det har inget att göra med att det finns mindre data.

 

Tja, det var ju du själv som sa det? Jag svarade ju bara på ditt argument. Jag citerar:

 

"Alltså endast innehålla så lite data som möjligt."

 

Eller vill du ändra dig?

 

En korrekt databas design är kanske inte alltid optimerad för prestanda.

 

Nä, en korrekt databas är optimerad för sitt syfte. Men är avsikten med en databas snabbhet eller prestanda och databasen inte är optimerad för detta så skulle jag vilja säga att den inte är korrekt designad.

 

Det var ju en lyckad lösning, då tappar man ju finessen med att ha en markering på att ett inlägg är läst.

 

Först och främst så var det ett förslag på en lösning om man anser att posten skulle bli för stor. För det andra så skulle jag rekommendera detsamma även om informationen om vilka inlägg man läst låg i en relationsdatabas. Oftast är ju tex. inlägg äldre än 1-2 år inte så särskilt intressanta längre.

 

Du har rätt

 

Jag vet.

 

den var inte dålig, den var riktigt usel

 

Ja, fast din var värre i just detta fall.

 

För att återgå till topic dvs. till att vara kreativ (vilket Magnus missat nånstans på vägen), så är ytterligare en sak man kan göra för att optimera prestanda att i ett id lagra både information om trådid och inläggsid. Tex. 123:1234 eller som bara en sträng 1231234. Genom att göra detta så behöver du bara lagra det senaste inlägget som någon har läst i den tråden för du vet ju att alla som har samma trådid och lägre inläggsid redan är lästa. Du sparar då både utrymme och prestanda.

 

 

/JANspeed

 

[inlägget ändrat 2003-12-04 09:41:04 av JANspeed]

[Magnus Gladh]

Först tänkte jag inte bry mig att skriva något svar, eftersom det är tydligt att du inte vet/kan något om databasdesign och systemutveckling. Dessutom så får du implementera dina lösningar precis hur du vill, det är inget som jag bryr mig om.

 

Dock är det fler än du och jag som läser dessa poster och de som är mindre kunniga kan ju tro att din lösning är bra. Så därför tänker jag svar ändå.

 

* Prestanda är inte alltid det viktigast när man utvecklar. Prestanda vägs alltid mot utvecklingstid och modularitet. Flerskiktade lösningar är inte alltid bäst ur prestanda synpunkt, men alltid bättre än att skriva all kod i samma lager, ur modularitet-, återvinings- och utvecklingstidssynpunkt. Att de sedan kan skalera är ju bara ett plus.

 

* Relationer är ingen begränsande regel, det är så man gör för att bygga den mest optimerade och mest utvecklingsmöjliga databas. På samma sätt som man använder OO när man utvecklar program.

Man använder relationstabeller för att de behövs inte för att de är flashiga, och i just detta fall, så spara man både prestanda och uttrymme på servern genom att göra det.

Det finns som sagt undantag när man bryter mot relationernan och det är när man får 4-5 eller fler JOINS i en SQL fråga, då kan man bättre prestanda genom att dubbellagra information (alt lägga information i "fel tabell). Man bryter dock aldrig mot reglen att data i en kolumn skall vara atomär, alltså att den data endast skall ha en betydelse.

 

* databasen eller din tabell får innehålla hur mycket data som helst, däremot så skall kolumnen alltid vara atomär.

 

* Återigen så väger man prestanda mot att dubbellagra information och den risk som det med för att man kan få inkosekvens i sin data. I detta fall så är min lösning bättre prestanda mässigt än din, samt att den kommer att ta mindre uttrymme. Alltså faller båda dina argument. Se nedan.

 

* Att ta bort data är något man skall vara riktigt försiktig med, det kan vara så att man vid ett senare skede kanske vill ha statistik på vilken inlägg som är den mest lästa, eller visa hur många inlägg som en person har läst. Om man då plockar bort denna information får man inte korrekt statistik. Sedan kan du inte med ditt förslag själv bestämma när du skall tömma ditt fält. Se nedan.

 

Ja, fast din var värre i just detta fall.

Tillåt mig småle, och berätta att min aldrig kan ge runtime-error medans din kan. Hur kan då min vara värre?.

 

Okej då slår vi ihål på dina argument.

 

 

Spara utrymme säger du!!

Nu är det så att spara talet 999 (tillsammans med en separater) som en text, kräver 4 stycken tecken, ett tecken tar upp 8 bitar. Alltså kräver det att du har 4 bytes för att kunna lagra talet 999 med separator. Med 4 bytes kan jag deklarera 2 stycken SmallInt som vardera kan hantera tal mellan (-32,768) och (32,767). Alltså på samma mängd uttrymme som du du max kan lagra talet 999 på kan jag istället lagrar poster upp till 32.767.

Sedan är det så att eftersom du kommer att använda dig av VarChar() i det fältet så kommer det läggas på en "slut på strängen" tecken sist. Och det tar minst 1 bytes (tror det är 2). Så något utrymme lär du inte spara med din lösning. För den delen är inte hårddisk något som är dyrt idag.

 

 

Bättre prestanda säger du!

Det skulle kunna vara så att prestandan för databasen är något bättre (knappast märkbar och jag tror knappast det, med tanke på att det tar längre tid att läsa en VarChar() än en Int, samt att du måste skicka mer information från databasen till klient) att göra som du säger.

Tyvärr måste du då istället implementera en Klientlösning där du får din sträng med alla idena i. Åå denna måste du göra en InStr(), det betyder att nu kollar du igenom hela strängen om just detta id finns med, och det gör du på alla poster även de som använadren inte har läst. Det tar prestanda.

 

Nästa lösning som du blandar in, är att man skall lägga till trådid för att spara lite uttrymme i databasen, du föreslår då 2 lösningar, dels med en spearator, vilket gör att du nu måste använda dig av split() för att få ut vad som är trådid och vad som är inläggsid. Gissa om split() kostar prestanda.

 

Din andra lösning fungerar inte ens, eftersom du inte kan säga vilka tal som tillhör representerar trådid och vilka som representerar inläggsid.

 

Sedan har du en annan aspekt för prestandan när du förslår din lösning, det är att du måste göra en strängoperation på din kolumn med idena i. Dels måste du lägga till de sist i strängen och dels måste du leta upp den andra posten som var den sista lästa inlägget i denna tråd , och sedan tar bort denna från tråden. Och det tar ju ingen prestanda?

 

 

Din lösning generar runtime error.

Problemet med att lägga iden i en lång sträng är att den strängen inte är obegränsad hur lång den får vara (om man inte använder Text, för då är den iprincip obegränsbar, fast då tappar du verkligen prestanda) och oftas använder man sig av VarChar() som får vara max 8000 tecken.

Det betyder att när man försöker uppdatera en läst post och det råkar vara den 8001 tecken så kommer du få ett runtime error som säger att längden på strängen är för stor. Det är ju bara att tömma tycker du. Visst men när skall du göra det, du kan inte göra det på någon bestämt tidpunkt eftersom olika besökare kommer att läsa olika många poster på ett givet tidsintervall. Så säg att du skall tömma det varje månad, då kan det finns användare som hinner läsa så många inlägg att det blir fler än 8000 tecken på en månad, speciellt om inläggsid börjar bli stora.

Här märker man också att din design är dålig då man måste tabort data för att kunna garantera en bra drift.

 

Så JANSpeed du får gärna vara kreativ, men att föreslå lösningar som är riktigt usla, samt kan generera fel och sedan inte förstå bättre och ta åt sig av kritiken, är inte kreativt.

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!

 

[inlägget ändrat 2003-12-04 16:58:41 av Magnus Gladh]

[Christoffer Eklund]

Jag tror att DU, Magnus, är en av de få personer som skulle kunna få mig att börja gråta.

 

[[SH]]

Av glädje då eller..?

 

/Stefan

___________________________________________________________

Last night I lay in bed looking up at the stars in the sky and thought to myself, "Where the heck is the cieling ?!" - Dilbert

 

[NoiseKiller]

Haha.. Ja *några småsvordommar* Det här var vackert! :')

 

Okej, Magnus du är lite hård i orden mot JANSpeed - själv hade jag precis som Doffe börjat gråta. Men du verkar ha koll på dina databaser!

 

För guds skull - lämna aldrig eforum!

 

 

[inlägget skrivet av NoiseKiller]

 

[TicoRoman]

Vill bara även jag infoga att Magnus har helt rätt. Att spara flera värden i en kolumn är helt fel inte särskilt lyckat då det är prestandakrävande och svårt att jobba med. Att sedan dela upp det som värde1:värde2 är ännu värre, och det är inget nyskapande med det.

 

Att ha en normaliserad separat tabell är både snabbare och effektivare!

 

Att kolumner ska vara atomära (dvs innehålla endast _ett_ värde) är det första man lär sig på en databasdesignkurs. Det är också den första och mest grundläggande normaliseringsregeln.

 

Dessa regler har uppkommit för att skapa optimerade och effektiva databastabeller...

 

_________

TicoRoman - Anfall är bästa försvar

 

[inlägget ändrat 2003-12-04 17:42:06 av TicoRoman]

[JANspeed]

Först tänkte jag inte bry mig att skriva något svar, eftersom det är tydligt att du inte vet/kan något om databasdesign och systemutveckling.

 

Först tänkte jag inte skriva något svar för ditt inlägg är så sablans långt och fullsmockat med besservisser termer och dessutom en förskräckligt nedlåtande attityd. Men sen ändrade jag mig. Det stämmer att jag inte har någon utbildning i varken systemutveckling och databasdesign men det betyder inte att jag inte kan veta vad jag snackar om. Och jag blir mer och mer tveksam över om det är någon nytta att ha en sån eller inte om det betyder att man blir som du dvs. nedlåtande.

 

Jag började med att posta ett förslag som jag tycker funkar bra. Det första du gjorde var att klanka ner på någon annan. Dock fortfarande utan att presentera en egen lösning.

 

* Prestanda är inte alltid det viktigast när man utvecklar.

 

Håller med, återigen skulle jag dock föreslå att så är fallet med ett forum.

 

Relationer är ingen begränsande regel, det är så man gör för att bygga den mest optimerade och mest utvecklingsmöjliga databas.

 

Optimeringen beror på applikationen inte på databasen. Visserligen är kanske ditt alternativ mer utvecklingsbart. Men frågan återstår om man har ett behov av att utveckla vidare på lästa poster. Detta kan dock inte jag avgöra utan bara användaren.

 

Det finns som sagt undantag när man bryter mot relationernan och det är när man får 4-5 eller fler JOINS i en SQL fråga, då kan man bättre prestanda genom att dubbellagra information (alt lägga information i "fel tabell).

 

Och det vet du att man inte får i detta exempel? Återigen så är det användaren som avgör.

 

Man bryter dock aldrig mot reglen att data i en kolumn skall vara atomär, alltså att den data endast skall ha en betydelse.

 

Datat har bara en betydelse enligt mig dvs. de inlägg man har läst. Varifrån regeln kommer ifrån vet jag inte och därför följer jag den inte heller slaviskt förräns jag fått en bra motivering varför. Det betyder dock inte att jag aldrig gör det.

 

det kan vara så att man vid ett senare skede kanske vill ha statistik på vilken inlägg som är den mest lästa

 

Den informationen kan man lagra ändå på andra sätt.

 

Tillåt mig småle, och berätta att min aldrig kan ge runtime-error medans din kan. Hur kan då min vara värre?.

 

Jag får aldrig runtime errors? Brukar du få det eller?

 

"Fånig kommentar om att slå hål på nått."

 

på kan jag istället lagrar poster upp till 32.767.

 

Hur många inlägg har eforum? Och hur många inlägg tror du de räknar med? och hur många användare? Bara antalet inlägg på ASP, VBscript överstiger din smallint.

 

Det betyder att för varje id så behöver du minst 4 bytes för en int. Med två stycken såna så tar det 8 bytes. Med en varchar så tar varje tecken en byte. Så för att spara id:t 999 behöver mitt exempel 4+2 bytes medans ditt behöver 8 eftersom du även måste spara användarid:t.

 

Skulle jag dock ha ännu ett ID typ. 999 i mitt fält så skulle du behöva: 2x8=16. Jag skulle dock bara behöva 2x4+2=10. Med 3 inlägg blir det för dig 24 bytes för mig blir det 3x4+2=14 bytes. Det betyder att samma antal inlägg tar nästan hälften av utrymmet. Detta sätt att jämföra på ger dock ingen vidare rättvis bild då id:t ökar i samband med antalet inlägg. Detta har jag dock inte räknat på. Men det kan säkert du göra med dina flashiga systemutvecklingskunskaper?

 

tar längre tid att läsa en VarChar() än en Int

 

Även nu medger jag att jag inte har någon utbildning i skillnaden mellan int och varchar men enligt erfarenhet har jag inte märkt nån större skillnad. Dock så krävs det i ditt exempel att du läser låt säga 100 int Medans mitt exempel endast läser en varchar. Storleken skiljer dem visserligen åt men som vi såg i mitt exempel så tar min varchar mindre plats än dina 100 int. Därmed också mindre data att föra över.

 

När det gäller att jämföra resultat vet jag inte riktigt hur du hade tänkt lösa det för det har du tydligen glömt att nämna? Men jag gissar att du antingen gör någon typ av join eller så låter du frågorna gå mot databasen. Enligt min erfarenhet tar dock join betydligt längre tid än om man typ loopar ut från en enkel tabell för en Join innehåller oftast en hel del redundant information. En stor del av den prestanda man sparar i databasen går visserligen åt till InStr på webservern men jag tror ändå man sparar i prestanda jämfört med Join. Dessutom avlastar man databasen.

 

Om det är frågor mot databasen du tänkt dig så vet jag inte riktigt hur du tänkt dig. men förklara gärna så kanske jag lär mig något nytt.

 

Nästa lösning som du blandar in, är att man skall lägga till trådid för att spara lite uttrymme i databasen

 

Denna lösning är baserad på att slippa lagra redundant information. Dvs. Har du ett inläggsid och trådid:t är en del av detta så slipper du du lagra de tidigare inläggen från samma tråd. Den enda skillnaden med ditt exempel hade varit att man även lagrar med trådid i en särskild kolumn och kan då göra en update istället för lägga till en helt ny post. Då sparar man både prestanda och utrymme. Självklart går det inte att slå ihop dem. Jag var för snabb. Tanken var att som i exemplet ovan lagra även trådid i en särskild kolumn. Men då behöver man inte trådid även i inläggsid:t. Däremot så funkar mitt första exempel lika bra för det.

 

Split skulle jag nog inte använda ut snarare InStr och Left alt. Right.

 

måste du lägga till de sist i strängen och dels måste du leta upp den andra posten som var den sista lästa inlägget i denna tråd , och sedan tar bort denna från tråden. Och det tar ju ingen prestanda?

 

En replace tar inte så värst mycket prestanda. Inte en update heller för den delen. Och informationen måste du ju ändå hämta. Sista inlägget kan du hämta när du ska visa inläggen eller tråden.

 

Visst men när skall du göra det, du kan inte göra det på någon bestämt tidpunkt eftersom olika besökare kommer att läsa olika många poster på ett givet tidsintervall.

 

Då får man väl sätta en gräns på 8000 tecken och sen skriva över den när den blivit full? Detta gör man så klart innan den blivit 8000 tecken. Eftersom du ändå hämtar informationen vid läsning. Problemet är att du tänker i banorna att bara lägga till information vilket självklart inte funkar. Men om en post tar 4 bytes som i ditt exempel så får du plats med nästan 2000 inlägg i minnet vilket borde räcka. Det blir runt 60 inlägg per dag per dag på en månad vilket definitivt räcker för mig i alla fall.

 

Så JANSpeed du får gärna vara kreativ, men att föreslå lösningar som är riktigt usla, samt kan generera fel och sedan inte förstå bättre och ta åt sig av kritiken, är inte kreativt.

 

Det är inte heller särskilt kreativt eller professionellt att klanka på andra och slänga ur sig kritik innan man tänkt efter själv. Det går faktiskt att fråga innan. Kom med konstruktiv kritik som håller så tar jag åt mig den. Det har du dock inte lyckats med än så länge i något av dina inlägg i den här tråden. Och presentera gärna en bättre idé om du har någon.

 

/JANspeed

 

 

[TicoRoman]

Jag vill inte på något sätt lägga mig i er "pajkastning", men vill kommentera vissa saker.

 

Jag började med att posta ett förslag som jag tycker funkar bra.

Förslaget fungerar nog, men är inte "framtidssäker". Så fort du behöver ta bort data för att få plats med ny data så är det inte bra.

 

Visst om man vill så kan man väl ta bort markeringarna för inlägg som lästs för länge sedan, men tänk om du utvecklade ett affärssystem där data inte får tas bort. Då fungerar det inte.

 

När man utvecklar ex databasdesignen så ska man tänka på att applikationen ska kunna växa hur mycket som helst. Databasdesign som medför begränsningar är därför felaktig. Man får inte tänka "men idag finns det bara 200 användare". Vad ska hända om användarna ökar till 2000? Databasdesigen, en vital del, ska alltid hålla.

 

Optimeringen beror på applikationen inte på databasen.

Nej, det är inte hela sanningen. Olika databashanterare returnerar data olika snabbt. Även databasdesignen påverkar. Normaliserade databaser är snabbare. I speciella fall kan man dock göra avsteg från normaliseringsreglerna.

 

 

Så, vad spelar det för roll om en procedur tar 1 eller 1,5 sekunder? En halv sekund är väl inget? Nej det är det inte på system där det kanske finns väldigt få användare.

 

Tänker man storskaligt så är en halv sekund väldigt väldigt mycket. Det är 50% långsammare än 1 sekund. Tänk tex på Lunarstorm som har en hel del klustrade servrar. Om vi tänker oss våra procedurer i dessa sammanhang så skulle ex proceduren som tar en sekund kräva 10 servrar medan den proceduren som vara bara lite långsammare skulle kräva 15 maskiner. Jag hoppas ni förstår den något dåliga jämförelsen.

 

 

Man bryter dock aldrig mot reglen att data i en kolumn skall vara atomär, alltså att den data endast skall ha en betydelse.

 

Datat har bara en betydelse enligt mig dvs. de inlägg man har läst. Varifrån regeln kommer ifrån vet jag inte och därför följer jag den inte heller slaviskt förräns jag fått en bra motivering varför. Det betyder dock inte att jag aldrig gör det.

Varför? Ja, just för att man ska slippa köra en massa tidskrävande jämförelsealgoritmer i applikationen. Det går snabbare att behandla data i kolumnerna då man alltid vet att de är atomära.

 

det kan vara så att man vid ett senare skede kanske vill ha statistik på vilken inlägg som är den mest lästa

Den informationen kan man lagra ändå på andra sätt.

På vilket sätt då, om man ska ta bort gamla saker för att få plats med nya?

 

Hur många inlägg har eforum? Och hur många inlägg tror du de räknar med? och hur många användare?

De lagrar nog inte flera värden i en kolumn. Vet inte vad frågorna har med saken att göra, men ska inte kommentera för mycket då jag inte noga följt de tidigare inläggen.

 

Dock så krävs det i ditt exempel att du läser låt säga 100 int Medans mitt exempel endast läser en varchar. Storleken skiljer dem visserligen åt men som vi såg i mitt exempel så tar min varchar mindre plats än dina 100 int.

Du förlorar prestanda eftersom du måste stycka upp och jämföra din inlästa varchar. Därför är 100 fristående int snabbare.

 

Dessutom så behöver man förmodligen inte alls läsa in alla int, utan endast de som behövs. I ditt fall måste du alltid läsa in hela varchar.

 

Enligt min erfarenhet tar dock join betydligt längre tid än om man typ loopar ut från en enkel tabell för en Join innehåller oftast en hel del redundant information. En stor del av den prestanda man sparar i databasen går visserligen åt till InStr på webservern men jag tror ändå man sparar i prestanda jämfört med Join. Dessutom avlastar man databasen.

En databas är gjord för att leverera data blixtsnabbt. En join-fråga är lika bra/dålig som dess skapare.

 

Denna lösning är baserad på att slippa lagra redundant information.

Redundans är inte prestandans värsta fiende. Det är dock dålig databasdesign, som resulterar i att man i applikationen måste göra jämförelser osv...

 

Då får man väl sätta en gräns på 8000 tecken och sen skriva över den när den blivit full? Detta gör man så klart innan den blivit 8000 tecken.

Fel fel fel och återigen fel. Det är ett dumt sätt att göra det på. Din databasdesign begränsar användningen.

 

Men om en post tar 4 bytes som i ditt exempel så får du plats med nästan 2000 inlägg i minnet vilket borde räcka. Det blir runt 60 inlägg per dag per dag på en månad vilket definitivt räcker för mig i alla fall.

Jaa... beror förstås på för vem det ska räcka.

 

Ditt förslag, JANspeed, fungerar definitivt, men den är krånglig, prestandakrävande och svår att underhålla.

 

När olika skribenter ställer frågor på eForum så strävar jag efter att ge ett svar enligt konstens regler (det jag kan iaf). Det är ingen mening att lära nybörjare att göra på ett felaktigt (om än fungerande, dock begränsat) sätt, när man kan lära de att göra det riktigt.

 

Jag menar inte att försöka vara en besserwisser eller något i den stilen. Absolut inte. För 2 år sedan visste jag knappt vad en databas var. Genom att studera ämnet så lär man sig varför det ska vara på ett visst sätt, även om det i början inte verkar helt logiskt. Jag kommer ihåg första gången vi skulle göra en enkel normaliserad databasdesign. Det var nästan så att man tyckte att läraren var en idiot eftersom det ju verkade helt fel. Efter ett litet tag förstår man dock varför det ska vara på ett visst sätt.

 

_________

TicoRoman - Anfall är bästa försvar

 

[Magnus Gladh]

suck...

 

---

Jag skall dock påpeka att ACID inte alls definerar hur man designar sin databas, ut är ett vilkor för hur databaser skall fungerar.

 

Det jag menad när jag skrev ACID var ju så klart Normalisering, som TicoRoman skrev.

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!

 

[JANspeed]

Förslaget fungerar nog, men är inte "framtidssäker".

 

Detta har jag inte sagt nått om. Och även om jag tror mitt förslag håller ett bra tag så kan det tänkas att man ändå får börja tänka om och designa om databasen i framtiden. Att konvertera min lösning till en separat tabell för lästa inlägg är inte särskilt svårt.

 

men tänk om du utvecklade ett affärssystem där data inte får tas bort.

 

Det är det jag menar med att det är applikationen som avgör. Mitt förslag baserade sig dock på ett forum. Hade det varit ett affärssystem så hade jag nog planerat annorlunda.

 

Vad ska hända om användarna ökar till 2000? Databasdesigen, en vital del, ska alltid hålla.

 

Precis, det är därför jag är mån om både utrymme och prestanda.

 

Tänker man storskaligt så är en halv sekund väldigt väldigt mycket.

 

Jo, definitivt men tänker man storskaligt så är det vad jag förstått lättare att klustra webservrar än databaser. Även om databaser fortfarande är bäst lämpade för databasoperationer så är det bra att befria databaserna från så mycket arbete som möjligt. Eller har jag fel?

 

Det går snabbare att behandla data i kolumnerna då man alltid vet att de är atomära.

 

Använder man de funktioner som databaserna är designade för dvs. SELECT, UPDATE, INSERT osv. så går det självklart snabbare. Men att jobba med textbehandling är det inte nödvändigtvis och måste du ändå hämta informationen till klienten så kan det ibland vara bättre att behandla informationen där än att behöva hämta informationen flera gånger i databasen.

 

På vilket sätt då, om man ska ta bort gamla saker för att få plats med nya?

 

Statistik om hur många som läst ett inlägg skulle jag lagra i tabellen för inlägget. Jag skulle definitivt inte börja räkna alla poster som läst inlägget. Det kanske ni anser som redundant information men det skulle nog garanterat spara en hel del prestanda med en update snarare än att selectera alla lästa trådar hos alla möjliga användare. Dessutom så skulle det inte ge en korrekt bild då folk som inte är användare kanske också ska kunna läsa inlägget.

 

De lagrar nog inte flera värden i en kolumn. Vet inte vad frågorna har med saken att göra, men ska inte kommentera för mycket då jag inte noga följt de tidigare inläggen.

 

Jag skrev inget om hur eforum gjort sin lösning men de har säkert fler inlägg än 32.767 som är begränsningarna för den smallInt som Magnus hade i sina beräkningar.

 

Du förlorar prestanda eftersom du måste stycka upp och jämföra din inlästa varchar. Därför är 100 fristående int snabbare.

 

Jag måste inte stycka upp min varchar. Jag gör en InStr även om det kanske är vad du menar så går det troligtvis snabbare än att tanka den redundanta datan som följer med vid en JOIN.

 

Dessutom så behöver man förmodligen inte alls läsa in alla int, utan endast de som behövs. I ditt fall måste du alltid läsa in hela varchar.

 

Hur ska databasen hitta vilka som behövs utan att göra jämförelser eller en join? Om du vet ett sånt sätt så får du gärna beskriva det för mig? Så kanske jag lär mig nått nytt.

 

En join-fråga är lika bra/dålig som dess skapare.

 

Samma svar där. Det kan mycket väl tänkas att jag missat något där så du får gärna förklara det närmare om du vet ett sätt som är bättre.

 

Din databasdesign begränsar användningen.

 

Det är jag medveten om men det är också avsikten. Det håller dessutom storleken nere. I början av en databas utveckling uppfyller det dock sitt syfte. Utvecklas databasen vidare så bör man kanske se över mer än bara lästa-trådar-funktionen. Vill man däremot konvertera tille en tabelldriven funktion så går det alldeles utmärkt som jag skrev tidigare.

 

Jaa... beror förstås på för vem det ska räcka.

 

Frågan är också om det är så smart att han en funktion som sträcker sig över detta. Vilet jag själv inte skulle rekommendera. Det är väldigt sällan jag läser inlägg som är över en månad gammla. Och dyker ett sådan upp igen så skulle jag nog vilja få det markerat som oläst. Annars är det via mina inlägg som jag skulle letat rätt på det och där är det inte aktuellt då jag redan vet att jag läst inlägg. Det är då mitt andra förslag kommer väl till användning.

 

Ditt förslag, JANspeed, fungerar definitivt, men den är krånglig, prestandakrävande och svår att underhålla.

 

Krångligt, ja kanske. Prestandakrävande, nä inte enligt min erfarenhet och inte enligt det räkneexempel jag demonstrerade för Magnus. Svår att underhålla, håller inte med där heller riktigt.

 

Däremot kan jag hålla med om att den inte riktigt är helt framtidssäker ur prestandamässig synpunkt. Men det ser jag som ett framtida problem och då har antagligen de ursprungliga förutsättningarna redan ändrats oavsett val av lösning från början.

 

Det är ingen mening att lära nybörjare att göra på ett felaktigt (om än fungerande, dock begränsat) sätt, när man kan lära de att göra det riktigt.

 

Vad som är rätt och vad som är fel kan bara var och en avgöra själva med ett objektivt sinne. Hur många tror ni inte det var som kritiserade Darwins och hundratals andra forskares upptäckter innan människorna började tänka om och det blev allmänt vedertaget? Nu säger jag inte att det här har någon direkt liknelse med vad jag påstår men jag har däremot presenterat den fakta som jag känner till och den bevisar vad jag stödjer mina argument på.

 

Sen kan det tänkas att det finns bättre lösningar men då får fakta som stödjer dessa presenteras först.

 

/JANspeed

 

 

[JANspeed]

Jag skall dock påpeka att ACID inte alls definerar hur man designar sin databas, ut är ett vilkor för hur databaser skall fungerar.

 

Jag har ingen aning om vad ACID är för något och det kanske är en brist. å andra sidan funkar mina databaser alldeles utmärkt. Kan tänkas att dessa kanske skulle kunna vara ännu snabbare men då får detta gärna förklaras för mig på annatt sätt än bara en hänvisning till nått jag aldrig hört talas om?

 

/JANspeed

 

 

[Magnus Gladh]

ACID är inget som du behöver bry dig om, inte heller dina databaser, utan själva databasen. Alltså MySQL, Access, MS SQL server måste klara av ACID för att få kalla sig en "riktig" databas.

 

Din databaser som du designar (om de är relationsdatabaser, vilket det garanterat är) skall följa normalisering. (Normalisering grad 3 tror jag räcker, finns upp till 7 (om jag kommer ihåg rätt, är ju ett tag sedan man läste databaskursen)).

 

Mer om ACID kan du läsa här: http://www.fredosaurus.com/notes-db/transactions/acid.html

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!

 

[dAEk^]

Det är ingen mening att lära nybörjare att göra på ett felaktigt (om än fungerande, dock begränsat) sätt, när man kan lära de att göra det riktigt.

 

Är det ok om jag snor det citatet och slänger in den i min signatur ?

 

Håller med i det uttalandet till 100%!

 

[TicoRoman]

Är det ok om jag snor det citatet och slänger in den i min signatur ?

Självklart!

 

_________

TicoRoman - Anfall är bästa försvar

 

[NoiseKiller]

Lite lustigt.. fick ett e-post från en av våra större Audi-klubbars forum.

Ämne: VARNING! 

Den läsbuffert som håller reda på vilka inlägg som du läst börjar bli full.

För att frigöra utrymme i databasen ber vi dig att nollställa den. Alla inlägg som är postade före denna tidpunkt kommer räknas som lästa. 

Om du inte nollställer läsbufferten nu kommer den automatiskt bli nollställd när bufferten blir full. 

 

Ska vi gräva ner stridsyxan å slå ihjäl varandra för hands?

 

[inlägget skrivet av NoiseKiller] - svänger förbi eforum

 

[Magnus Gladh]

sorligt...

 

- Magnus

-----------------------------------------------------

Våga vägra bredband med nerladdningstak!!!!