array vs variable performance

Husk " eller ' om index, når det er en streng.
$text['send'] = "Send";

Der skulle ikke være noget galt for at lave en fil for hvert sprog:

language_dk.inc.php
$text['send'] = "Send";
$text['slet'] = "Slet";

language_en.inc.php
$text['send'] = "Send";
$text['slet'] = "Delete";

Og så bare inkludere den pågældende fil

Jeg havde nok valgt en XML fil, og evt fået brugeren til at parse den selv (hvis browseren understøtter dette)

drbean >> Kan du uddybe det lidt jeg har ikke arbejdet med xml i forbindelse med php, men jeg ville forstille mig det krævede mere at phpen at læse og forstå en xml fil end det ville at læse en tekst fil, har du eventuelt nogle link jeg kan se ?

hmortensen >> ja det har du da ret i, dem glemte jeg i farten.
Men tror du det er lige meget om jeg bruger variabler eller arryas ?

Nemmeste er da vist at sætte en cookie?

<?php
if(isset($_COOKIE"["lang"])) {
$sprog = $_COOKIE"["lang"];
}else{
$sprog = "dk";
}

include($sprog."inc.php");
?>

Eller, hent din side fra mysql. (stadig med cookie)

sukos >> Jeg tror du har misforstået mit spørgsmål lidt, jeg mangler ikke en måde at finde ud af hvilket sprog der skal vises på siden.

Men jeg vil gerne have lidt råd til hvilken måde jeg skal vælge at lave mine sprog filer, indtil vidre er der 3 muligheder, som variabler, som arrya's og som xml, dog er der ikke nogen der har svaret på hvilken af de 3 der er bedst i forhold til ydelse

"let at oversætte til andre sprog"
findes IKKE!

Og personligt ville jeg bruge en table i DB'en for hvert sprog, og ud fra cookien hente fra DB

Jeg ville nok bruge en fil for hvert sprog, og gemme i array

Enig med sukos i at der ikke findes lette måder at internationalisere på. Faktisk mangler jeg stadig, efter flere års søgen, at finde det perfekte værktøj til at gøre dette i PHP.

Rent bortset fra det, så ville jeg kraftigt overveje at bruge simple tekstfiler der læses ind ved hver kørsel. Det er meget, meget nemmere at vedligeholde, og man kan sætte ikke-kyndige til at vedligeholde dem i div. teksteditorer.

Gu er performance vigtig med 1,000 samtidige brugere -- men at holde overblikket er vel i sidste ende vigtigere :-)

sukos >>
Hva er grunden til du vil bruge en DB, ville det ikke komme til at trække for meget hvis, f.eks man skulle have en hel faq side i databasen ?

hmortensen >>
Den helder jeg også mest til lige i øjeblikket

majkat >>
Jeg kunne ikke være mere enig :-)
Det kunne være man bare skulle kaste sig ud i noget med nogle tekst filer og nogle arrya's

Hvis majkat, hmortensen ligger et svar så får i 15 point hver

Næh!

Tværtimod skal du sidde og rode med forskellige filer, og kan ikke bare så'n lige tilføje et nyt sprog!

sukos >>
Kun du give en god begrundelse ud over du syndes det er mere overskuligt ?

Og som sagt før så vil det da uden trivel trække unøvendigt meget på databasen,
har du også dine billeder til at ligge i din database ??

"og kan ikke bare så'n lige tilføje et nyt sprog!"

Ja, ok, selvf. kan du lave en DB baseret på txt filer, men finder det selv nemmere a tbruge mysql

Unødvendigt?
Du vælger jo kun hvad du vil ha' vist fra DB'en

Du kan jo ha dem i databasen til administration, og så generere sprog filen ud fra databasen, så skal de kun hentes fra databasen ved opdatering

tak for det

Billeder i DB bruger jeg kun jeg kun filnavn. Stien til filen er defineret i scriptet

<ole>

At skulle belaste en database med den slags, vil jeg anse for helt unødvendigt. Det vil måske ikke betyde så meget på 'sitet om husets kat' - men det bliver på et større site hurtigt en unødig belastning.

Jeg ville helt klart vælge en løsning med et array, der bliver importeret i en include-fil. Dog ville jeg nok gøre det vanskeligere for ubehagelige personer at inkludere en hvilken somhelst fil på serveren:

<?php
if(isset($_COOKIE"["lang"])) {
    switch ($_COOKIE"["lang"]) {
        case "en":
            $sprog = "en";
        break;
        case "fr":
            $sprog = "fr";
        break;
        case "de":
            $sprog = "de";
        break;
        default:
            $sprog = "dk";
    }
}

include($sprog."inc.php");
?>

/mvh
</bole>

Og selvf. er der ikke "ens" filnavne :O)

olebole -> Den tror jeg bare ikke på! Det vil jo blive minimalt opslag i DB, men ok, nu ved jeg så heller ikke hvad siden skal kunne!
"Unødvendigt" -> Du vil helst afvikle "javascript" (såhutjegvikser?) :O)

Findes der større sites som IKKE bruger en DB???

Hmm jeg har aldrig fattet det her point system nu fik majkat jo alle point, hmortensen og olebole er i intresseret i jeres point, for så opretter jeg lige et andet spørgsmål med 60 point i kan få at dele

sukos >>
Så vidt jeg ved bruger både
PHPBB
Coppermine Photo Gallery
phpmyadmin

alle metoden med tekst filer

"Coppermine is a multi-purpose fully-featured and integrated web picture gallery script written in PHP using GD or ImageMagick lib with a MySQL backend."

PHPBB gider jeg ikke kommentere.
PHPMyadmin?

Men nok om det! :O)

sukos >>
Ved du ik hva phpMyadmin er eller ved du ikke hvad jeg menner når jeg siger de bruger tekst filer til deres sprog ???

sukos >> Jeg skriver 5-6 forskellige sprog og vælger somregel det, jeg finde bedst til opgaven - jeg har ikke favoritter på den måde  :)

Det er muligt, du ikke tror på det, men det er noget, jeg har set med egne øjne. 'Små databaseopslag' er der ikke noget, der hedder på et større/stort site (og ja, næsten alle store sites bruge database). Netop her gælder det om at cache så meget som overhovedet muligt i fysiske filer. De, der ikke gør det, kan du kende på laaaaangsomme loadtider  ;o)

Ja, for hvor'n fa'n skulle de ellers kunne gi' dig noget kode som resulterer i dansk?
Du skal jo vise en side, men ikke levere koden.
Og den er iøvrigt ikke specielt hurtig! :O)

Og så ikke mere om det! :O)

Ja, ok, og så IKKE MERE OM DET I DETTE SPM. ;O)

Kunne du ikke forholde dig til meningsudvekslingen i stedet for at vælge at råbe, at du ikke vil høre mere om det? Er du enig, uenig - eller har du taget fejl, men formår bare ikke at skrive det?

Nåh, så skide være med det.............

Vil næsten tro (tro) at hvis PHPMyadmin som "opstart" fik lov at vælge sprog m.m, og kunne lave en DB med sprog, ja, så ville den afvikles hurtigere, i langt de fleste tilfælde, (serverhardware), men nu er jeg også ude at snakke for min syge moster!!!!

Næh, olebole, jeg er jo uenig, hvis du læser indlæg!
Men det er jo for ikke "at kævles" om det, jeg skriver "ikke mere"

Og PHPMyadmin som sådan er jo "et lille site", omend der selvf. kan være mange brugere logget ind på samme tid.

Og langsom, ja det er den, men om det skyldes sprog, skal jeg sgutte kunne sige

Nok mere alle de ting man kan med den

Så...indtil nogen af jer har et "real life" eksempel hvor hastigheden er testet med DB hhv. tekstfil skal vi vist lade ladefoged bruge det han har det bedst med :)

Den virkelige verden bugner af løsninger, hvor man bruger oceaner af resourcer på at lave caching-systemer til at aflaste databaser med. Flere af de store, professionelle CMS'er bruger caching - og det er heller ikke uden grund, der i .net er lavet en stor cahcing-løsning. Den slags udvikling betaler men ikke for, hvis ikke det er nødvendigt  ;o)

I bl.a. mssql har man mulighed for at anvende 'stored prcedures' for at aflaste for de mange ens databasekald, der kan forkomme i store systemer - andre gange kobler man f.eks. en AS400 op som 'buffer'.
Når man derimod arbejder med MySQL er mulighederne ikke så store, så her gælder det virkelig om at holde tungen lige i bukserne og tøjle sin facination af database-begrebet. WWW flyder med dårlige og ineffektive MySQL-løsninger, hvor DB'en i voldsom grad 'over-bruges'.

For en mand med en fin, ny hammer kommer alt til at ligne søm  :)
/mvh

MySQL i de nyere versioner understøtter vist nok Stored Procedures

Og som jeg ser det er stored procedures udelukkende et spm. om sikkerhed/kompabilitet, og ikke hastighed.

ladefoged >> se venligst http://www.eksperten.dk/spm/552269 så du kan få dine 15 point igen

Vi er vist ved at bevæge os lidt væk fra det centrale, men jeg kan ikke undslå mig for at komme med et par kommentarer vedr. MySQL og performance generelt:

"MySQL i de nyere versioner understøtter vist nok Stored Procedures" - korrekt, men "nyere versioner" = 5.0. Og den befinder sig stadig (svjv) i alpha-stadiet. Jeg tror ikke vi skal forvente at se en production release indtil en gang tidligst midt-2005, og hos ISPer endnu senere.

"stored procedures [er] udelukkende et spm. om sikkerhed/kompabilitet, og ikke hastighed." - her vil jeg sige "både-og". Sikkerhed/kompatibilitet er helt sikkert topscorere, men hastighed kan også være en faktor. Hvis du f.eks. har brug for store, midlertidige resultsets kan du med stored procedures holde dem på serveren frem for at behandle dem i dit program. Resultatet er, at du kun skubber de data til programmet som det rent faktisk skal bruge. Ikke uvæsentligt, hvis database-serveren står langt fra webserveren netværksmæssigt. Omvendt giver det selvfølgelig mere load på serveren, så det er altid et trade-off.

Jeg kan ikke undslå mig for at lige at gøre opmærksom på MySQLs query cache som giver et stærkt performance boost hvis man kører den samme forespørgsel igen og igen uden at de underliggende data ændrer sig. Og netop i dette tilfælde må man vel antage at de oversættelser der er tale om ret hurtigt vil stabilisere sig set ift. måske tusinder af queries/min.

Skal man så vælge at gemme oversættelserne i MySQL? Ikke nødvendigvis - for operativsystemet vil jo også cache en evt. tekstfil med oversættelser, så der er nok en god chance for at den altid vil være cachet hvis den tilgås igen og igen på den travle server.

Min personlige holdning er at databaser er noget man skal bruge til data der (bruges sammen med data som) ændrer sig forholdsvis tit. Til mere statiske ting bør man bruge det værktøj der giver det bedste overblik og er nemmest at håndtere på lang sigt. Det *kan* være en database, men ud fra de informationer vi har set her, ville jeg stadigvæk sætte min lid til tekstfiler.

Til alle dem der har holdt ved hertil: Tak for tålmodigheden, og sov godt :-)

majkat >> Har smit et svar til dig

hmortensen >> Sig lige til hvis du vil have dine point

Ja sikke en diskutation det kunne sætte igang, men jeg er nu efterhånden kommet frem til det samme som majkat forklare, jeg vil sætte min lidt til tekst filer da jeg også kan de der er mange store projekter der bruger det, så det må jo virke fint.

Takker for en dejlig lærerig diskution håber der er mange andre der kan drave lige så meget nytte af den som jeg kan