PDF fra MySQL

Et godt råd er hvert fald at lade være med at bruge IE som test-browser i disse tilfælde - du kan risikere den laver unoder som at cache headers, ignorere headers osv. - brug evt. mozilla eller opera som test-browsere og når det er færdigt, så prøv med IE!

Når dette er sagt kan jeg fortælle, at du skal have fat i de rigtige mime-types og sende dem ud med headere - og pga. IE, skal du vist også ud i en høkerløsning før det kommer til at fungere rigtigt!

Generelt er det ønskværdigt at undgå at gemmer hele binære filer i en database.
istedet er det bedre at lade filen ligge i filsystemet som en fil og blot gemme filnavnet i databasen.

En grund til det er at der i mange database implementationer er en øvre grænse for hvor stor databasen kan blive. hvis man gemmer ting i den der er flere hundrede kilobyte store nås den grænse hurtigt.

En anden grund er at så slipper man for at skulle konvertere hele filen til et format der kan ligge i databasen, og igen konvertere tilbage hvergang den hentes. Det koster servertid.

Så prøv at se om ikke du helt kan udgå at gemme hele filer i din DB.

mvh JakobA

jakoba> tak for dine velmente ord, men ellers tak. jeg er helt med på fordele og ulemper ved at benytte databasen til lagring af filer, og det var ikke mit sprøgsmål.
tipsen> hvad mener du med høkerløsning? Hvad er det for nogle problemer IE kan give?

Jeg sender header oplysninger med omkring mime-types. Er der andet, som kunne være relevant. Størrelse på filen f.eks. ???

<ole>

mads_mao >> Hvis du er helt med på fordele og ulemper ved at benytte databasen til lagring af filer - kan du så ikke nævne et par fordele?
Jeg kender ikke rigtig nogen, der kan retfærdiggøre at bruge en DB til det formål - men jeg vil meget gerne lære, hvis du ved noget, jeg ikke gør.

/mvh
</bole>

olebole> for mig at se er der indtil flere fordele. For det første, så giver lagring i databasen mig langt bedre muligheder for at styre, hvem der får adgang til mine filer. Jeg kunne gøre noget tilsvarende med htaccess, men det har så adskillige ulemper i forhold til at styre, hvordan brugere logger ind på min side. Ved at lagre i databasen kan jeg gemme mine filer udenfor selve web-roden, og derved opnå bedre sikring af filerne.

Med hensyn til ulemper, så er den primære grund til ikke at gemme filer i databasen (sådan som jeg har kunnet udlede af diverse news-groups), at det giver et stort performance tab. Jeg har nu testet med mange forskellige filer i mange forskellige størrelser, og det performance tab jeg får er stort set ikke eksisterende.
Den sidste ulempe jeg så kan få øje på er den, at jeg på nuværende tidspunkt har lidt problemer med at få browserne til at behandle forskellige filformater korrekt. Hvis det kan løses, så er jeg af den holdning, at lagring af filer direkte i databasen giver mig langt flere fordele end ulemper.
Som dig er jeg dog meget interesseret i at lære, så hvis du kan komme med nogle inputs, så er jeg meget lydhør.

Du kan blot inkludere filer fra en mappe uden for web-scope, så kun filsystemet har mulighed for at læse dem. Det bør ikke kunne volde problemer med log-in, da du der kan tildele brugeren hans rettigheder i følge info fra DB'en. Den løsning giver dig præcis ligeså god sikkerhed.

Hvad angår performance, så er tabet naturligvis afhængigt af trafikken på serveren - ikke mindst på SQL-serveren. Ved lidt større sites er den ganske væsentlig - ved store sites kan den være meget stor.
At du ikke kan mærke nogen nedgang i performance, må bero på, din server er meget lidt belastet i forvejen og/eller der er tale om meget få filer i DB'en.

Du mærker ikke noget særligt, hvis en enkelt fil skal hentes i ny og næ, men hvis mange brugere simultant skal hente filer fra DB'en, er det en helt anden sag  :)
/mvh

Det kan du have ret i, men hvis brugeren nu skulle have lyst til at downloade en af de filer, som jeg har gemt udenfor web-scope, så er jeg nødt til først at kopiere den til en ny lokation og derefter give brugeren adgang til den fra en placering indenfor web-scope - eller hvad ???
Hvis ja, så giver det jo så ekstra bøvl i forhold til at kopiere filen fra et sted til et andet, samt problemerne i at holde øje med, hvilke filer der ligger i "temp-diret", og om nogle af disse ikke længere er i brug, og derfor skal slettes.

Nej, det behøver du ikke. Filen, der inkluderer den beskyttede fil, skal blot være forsynet med passende headers. Så kører det ... som barnefingre gennem en bakke Kærgåden  :)

Jeg saksede engang dette fra php.net ... den har jeg selv brugt i mange forskellige versioneringer. Her i original version med den oprindelige author's kommentarer:

# Here's a function for sending a file to the client - it may look more complicated than necessary,
# but has a number of advantages over simpler file sending functions:

function send_file($name) {
    $status = FALSE;
    $path = "protected/".$name;
    if (!is_file($path) or connection_status()!=0) return(FALSE);
    header("Content-type: application/octet-stream");
    header("Content-Disposition: inline; filename=\"".$name."\"");
    header("Content-length: ".(string)(filesize($path)));
    header("Expires: ".gmdate("D, d M Y H:i:s", mktime(date("H")+2, date("i"), date("s"), date("m"), date("d"), date("Y")))." GMT");
    header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
    header("Cache-Control: no-cache, must-revalidate");
    header("Pragma: no-cache");
    if ($file = fopen($path, 'rb')) {
        while(!feof($file) and (connection_status()==0)) {
            print(fread($file, 1024*8));
            flush();
        }
        $status = (connection_status()==0);
        fclose($file);
    }
    return($status);
}

# ==================================================================
# And here's an example of using the function:

if ( !send_file("platinumdemo.zip") ) {
    die ("file transfer failed");
    // either the file transfer was incomplete
    // or the file was not found
} else {
    // the download was a success
    // log, or do whatever else
}

# ------------------------------------------------------------------
# - Works with large files, and uses only an 8KB buffer per transfer.
# - Stops transferring if the client is disconnected (unlike many scripts, that continue to read and buffer the entire file,
# wasting valuable resources) but does not halt the script
# - Returns TRUE if transfer was completed, or FALSE if the client was disconnected before completing the download.
# You'll often need this, so you can log downloads correctly.
# - Sends a number of headers, including ones that ensure it's cached for a maximum of 2 hours on any browser/proxy,
# and "Content-Length" which most people seem to forget.
# Note that the folder from which protected files will be pulled, is set as a constant in this function (/protected).

/mvh

Det ser sgu spændende ud. Det kan da afgjort godt ske, at jeg skulle overveje at benytte den metode i stedet. Det skal i hvert fald prøves.
Hvad siger du til en håndfuld points ???

Joo tak  :)

Én ting er sikkert: Det vil forbedre performance - og frigive server-vitaminer til andre jobs  ;o)
/mvh

Det skal i hvert fald komme an på en prøve det er helt sikkert ;-)