Beethoven Skrevet 24. juli 2006 Del Skrevet 24. juli 2006 Hei, Jeg så på Vikingboard, og der ser det ut som alle spørringene er samlet i en klasse. Jeg syntes det virka veldig ryddig og smart. Hva mener dere om sånt? Hva slags fordeler for man ved det? Takker for svar. Lenke til kommentar
endrebjo Skrevet 24. juli 2006 Del Skrevet 24. juli 2006 Det er vel for at brukeren lett skal kunne velge andre databaser enn MySQL i fremtiden. Eller er jeg helt på villspor? Lenke til kommentar
Beethoven Skrevet 24. juli 2006 Forfatter Del Skrevet 24. juli 2006 (endret) Oh, ja, det må nok være noe sånt! Takk! Så dette anbefales ikke å gjøres hvis jeg ikke skal bruke noen andre databaser enn MySQL? Endret 24. juli 2006 av Beethoven Lenke til kommentar
Canute Skrevet 24. juli 2006 Del Skrevet 24. juli 2006 Oh, ja, det må nok være noe sånt! Takk! Så dette anbefales ikke å gjøres hvis jeg ikke skal bruke noen andre databaser enn MySQL? 6547998[/snapback] Du får jo gjøre som du vil, men jeg synes det er litt baklengs. Lenke til kommentar
bjokys Skrevet 25. juli 2006 Del Skrevet 25. juli 2006 Spørs veldig om du skal lansere systemet. Siden VikingBoard er designet som ett generelt forum, er det nesten ett krav om at skal støtte flere databaser. Det blir som du sier veldig ryddig, men det spørs veldig om det er verdt alt det ekstra arbeidet dersom du kun skal bruke MySQL. Lenke til kommentar
genstian Skrevet 28. juli 2006 Del Skrevet 28. juli 2006 Det er egentlig idiotisk. Hvis du skal da ikke standard spøringer i tredjeparts script blir det mye ekstra job. Du må også laste alle spøringene inn i minnet da disse er en del av scriptet. 5-25kb ekstra minne. Det legger også en del til på kjøringstiden, så eneste fordel bli vel at det er rydigere. Lenke til kommentar
???????? Skrevet 28. juli 2006 Del Skrevet 28. juli 2006 Lastetiden er nok ikke noe problem. Lenge siden jeg har vært på forumet nå, men ser at diskusjoene fortsatt går rundt uvenstlige ting. Om dette er lurt er mer avhengig av prosjektet. Ved å plassere alle spørringer i en egen fil så er det enklere å jobbe med disse dersom alle skal endre. Det kan være en fordel på større prosjekter! På mindre prosjekter er dette ofte bortkastet. På større prosjekter så kan samme spørring finnes i mange mange filer, og da oppdatere alle disse er jo mye mer krevende enn å bare endre den en gang. Det blir som bruken av en funksjon. I steden for å skrive samme kode mange ganger så lager man jo selvfølgelig en funksjon. Lenke til kommentar
Ueland Skrevet 28. juli 2006 Del Skrevet 28. juli 2006 Vikingboard inneholder 16k linjer kode så der ble det best å samle alt i en fil, dog har vi merket at det blir en del tregere når php koden ikke er cachet opp, så i v 0.2++ vil alle spørringene ligge over flere filer (dvs "/inc/drivers/sql/mysql_fooside.php") for å forhindre for mye treghet slikt sett. Men som det sies, det er ikke nødvendig før man enten har et stort system, eller man skal kunne støtte flere databaser. Å endre tabellstrukturen i et såpass stort system for så å manuelt endre spørringene i alle filene hadde jo blitt en drittjobb så å da ha det i en fil er rett og slett veldig mye bedre. Lenke til kommentar
DarkSlayer Skrevet 28. juli 2006 Del Skrevet 28. juli 2006 (endret) Mange veier til rom... Jeg er tilhenger av OO programmering, og således så ville jeg ha lagt egne klasser som har funksjoner for å manipulere en tabell/tabellsett. Mange velger å blande sql-queries rett inn i php scriptet der siden genereres. Problemet her er at det foregår mye copy/paste, og dermed lager et lite helvete å rydde opp i dette om spørringene må endres. ERfaringsmessigt så må man ofte det. Ved å putte spørringer inn i funksjoner i det minste gjør at det blir litt lettere å finne spørringene, og vedlikeholde dem. Men det beste er å putte de i egne klasser, i egne filer, i egne mapper så du har best mulighet for å endre/bytte/fikse på spørringene. Da er det også mye enklere å sørge for skikkelig validering av input/output, og håndtering av feil. Er det et krav å måtte støtte flere databaser, så kan det være veldig greit å lage nettopp generelle funksjoner for manipulasjon av databasen, og dermed gjemme spesifikke mysql funksjoner i mysql objekter (bytter du til en annen, så laster du bare ms,oracle, postgre klassene). Ergo så forholder de vanlige skriptene til et sett av funksjoner. Dette gjør vedlikehold mye lettere. Oppgraderes mysql, så er det bare å lage nytt objekt. Bakdelen med å lage generelle funksjoner og rutiner er at man kan gå glipp av optimaliserte sære metoder som en database tilbyr. Dette gjør at du ikke vil få maksimal utnyttelse av koden. Dette kan jo være trist hvis du lager en side for en bedrift som har hosta opp tonnevis av peng for en fancy oracle db. Men altså... det er et ordtak, som jeg gjerne modifiserer litt... Make it work Make it good If necessary, make it faster men shitt ass .... kjøp mer ram og cpu hvis det virkelig brenner på dass. Endret 28. juli 2006 av DarkSlayer Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå