---

Hej,

Jeg har i mange år udviklet hjemmesider til private, foreninger og
mindre virksomheder i ASP+Access, men har de sidste par måneder
overvejet at skifte al fremtidig udvikling til PHP og MySQL.
Hvis jeg selv skal sige det, så er jeg ret skrap til ASP, JavaScript,
VBscript og SQL, men har kun læst en smule om PHP. Jeg kender absolut
intet til OO-programmering (Java, dotNET, C# osv).

Hvis DU selv er skiftet fra ASP til PHP, kunne jeg godt tænke mig at
høre 1) hvorfor du skiftede og 2) hvad der var mest besværligt ved at
skifte.
Andre indspark/kommentarer er naturligvis også velkomne

Tak på forhånd!
Peter

---

Peter [5260] skrev:

> 1) hvorfor du skiftede

Jeg skiftede så småt i 2005. I begyndelsen var det af ren nysgerrighed,
men efter noget tid blev jeg glad for php.

På den ene af mine sider skete skiftet i 2 faser:
1) Access blev skiftet ud med MySQL
2) Skift fra asp til php.

Ud over nysgerrigheden lå der dog også at jeg fornemmede at det gamle
ASP nok ville blive "udskiftet" med asp.NET.

Det danske læsestof om asp.NET var på den ene side for "langhåret" til
mit temperament, og på den anden side for meget baseret på at man havde
Visual Studio.NET. Jeg kan ikke finde ud af at lave hjemmesider i
WYSIWYG-programmer. På det tidspunkt fandtes der desuden ikke nogen
gratis-udgave af VS.NET og MS SQL, så der var kun 2 muligheder for mig
der har det svært med engelsk [1]: Enten poste 15.000 kr. i programmet
eller droppe at lære det.

Og når jeg nu har det bedst med at skrive koden i hånden, ville jeg ikke
betale en bondegård for et program som jeg måske alligevel ikke brød mig
om at bruge.

Et tredje aspekt var at jeg ved overgangen til php fik det hele
"gratis", og ofte fik man mere webhotel for de samme penge med php på
dette tidspunkt. Stadig er det sådan på de fleste ASP-hoteller at hvis
man vil køre med MS SQL, får man meget lidt databaseplads, hvor
PHP-hotellerne gerne lægger MySQL og web-indhold (html-filer, billeder
osv.) sammenn i én pulje.

På mine sider fylder databasen gerne pænt meget. (På siden i min
signatur fylder databasen i skrivende stund 27 MB)

Jeg var klar over at det enten måtte blive MySQL eller MS SQL, da Access
ikke regnes som egnet til mere omfattende hjemmesider. Jeg mærkede da
også en gevinst i performance, da jeg skiftede fra Access til MySQL,
selv om koden stadig var ASP.

> og 2) hvad der var mest besværligt ved at
> skifte.

3 ting.

For det første serveropsætning. I begyndelsen ville jeg gerne kunne køre
PHP sammen med ASP på min egen computer. Altså at have det til at køre
på IIS.
Jeg slåssede med det i flere dage (php 5 og MySQL 4), indtil jeg prøvede
at installere en ældre version af MySQL (3.26 mener jeg at den hed) samt
nedgradere til php 4. Så virkede det.
I dag har jeg skiftet IIS ud med XAMPP, og det er pærelet at sætte op.
Under IIS skal man sætte nogle rettigheder (også til ASP), før det virker.

Det var nok konvertering af mine eksisterende databaser.
Der gik et stykke tid, før jeg fandt ud af at man kunne eksportere en
Access-database og ved denne konvertering sætte det datoformat som MySQL
foretrækker (ÅÅÅÅ-MM-DD). Så det blev til at jeg i MySQL lavede et
varchar-felt til datoen, kørte et script til at bytte om på rækkefølgen
i et nyt datofelt for så derefter at slette varchar-kolonnen.

En anden ting som jeg skulle vænne mig til, var at datediff ikke findes
i PHP.
Men det har jeg så klaret på andre måder (bl.a. ved hjælp af mktime() ).
Og i MySQL kan man blot kalde med en sætning som:

select kolonne1,kolonne2 from tabellens_navn
where dato <= '2009-05-29 00:00:00'

Ellers fandt jeg ikke skiftet specielt besværligt. Jeg skulle vænne mig
til at bruge en lidt anden syntaks, og at AltGr-tasten pludselig skulle
flittigt i brug til tegn som $ [ ] { og } (samt \). Lidt bøvlet når jeg
havde været vant til kun at bruge shift-tasten i venstre side af
tastaturet. (Jeg bruger *aldrig* Ctrl- og shift-tasterne til højre).

Men alt i alt synes jeg ikke at der er den store forskel på ASP og PHP.
I hvert fald ikke noget som gør at jeg mener at det ene er bedre end det
andet.
Derfor kan jeg heller ikke stå og fortælle nybegyndere, hvad de skal
kaste sig ud i. Kun hvad jeg selv bedst kan lide.


--
Philip - http://chartbase.dk

---

Philip Nunnegaard skrev:

> så der var kun 2 muligheder for mig
> der har det svært med engelsk [1]: Enten poste 15.000 kr. i programmet
> eller droppe at lære det.

Note:
[1] Forstået på den måde at mit engelskniveau er lidt under normalen i
Danmark. Nyt stof *skal* jeg have på dansk. Er jeg først inde i stoffet,
er der dog en god chance for at jeg kan forstå det engelske, hvis det er
formuleret tilstrækkeligt pædagogisk.

www.php.net og www.w3schools.com er eksempler på sider på engelsk, hvor
jeg godt kan være med, fordi jeg kender det grundlæggende i stoffet i
forvejen. Dermed kender jeg terminologien og kan dermed skelne mellem
ord der hører med til terminologien og ord der skal slås op i en ordbog.

Et klasseeksempel er "validering". Når jeg på engelsk læste noget med
"validate", forstod jeg det bare som at det var i orden at "det
virkede". Jeg fattede ikke at det betød at jeg skulle køre koden gennem
validatoren på w3c's side for at teste at jeg havde skrevet
standardoverholdende kode (hvad jeg bestemt ikke havde).

--
Philip - http://chartbase.dk

---

Philip Nunnegaard wrote:

<provokation, Access="no-good", mySQL="no-good">

> Jeg var klar over at det enten måtte blive MySQL eller MS SQL, da Access
> ikke regnes som egnet til mere omfattende hjemmesider. Jeg mærkede da
> også en gevinst i performance, da jeg skiftede fra Access til MySQL

Det kunne være interessant at opleve dine performance 'factors'
I min verden, så performer Access (given the circumtances) som skidt ud af
en spædekalv, eller som 'shit through a goose' som de siger nogle stedere.

Har du nogle faktuelle sammenlingninger, eller er det subjektivt?

(Jeg vil ikke promovere hverken Access eller mySQL, da begge er
'pap-databaser')

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> (Jeg vil ikke promovere hverken Access eller mySQL, da begge er
> 'pap-databaser')
>

Ahhh, syns nu at mySQL er kommet godt igen efter version 5.1, men der er
godt nok heller ikke sket meget efter det (andet end et par bugfixes og
en lille smule hist og pist, men ikke noget stort), og nu har Sun jo
overtaget det, og Sun bliver muligvis overtaget af Oracle - så mon der
overhovedet kommer til at ske mere på den front (efter 6.0)... det må
guderne vide

---

Stig Johansen wrote:
> (Jeg vil ikke promovere hverken Access eller mySQL, da begge er
> 'pap-databaser')

Hvad er dit argument for MySQL er en pap-database?

/Johan

---

Johan Holst Nielsen wrote:

> Hvad er dit argument for MySQL er en pap-database?

'pap-database' er måske et hårdt ord, og det skal nok ikke tages
bogstaveligt.

Jeg er vant til at lave 'kritiske' systemer, hvor det er essentielt at man
kan lave en recovery enten til 'last comitted transaction', eller et fixed
tidspunkt.

Så de databaser der ikke kan det, kalder jeg blot 'pap-databser' over en
kam.

Men det er klart, at hvis man ikke har det behov, så er det et ligegyldigt
argument.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Jeg er vant til at lave 'kritiske' systemer, hvor det er essentielt at man
> kan lave en recovery enten til 'last comitted transaction', eller et fixed
> tidspunkt.

> Men det er klart, at hvis man ikke har det behov, så er det et ligegyldigt
> argument.

Og da ovenstående er sort snak for mig, er det nok fordi jeg ikke har
behovet.
Det kunne straks være mere interessant at høre hvilken database du så
bruger.
Jeg gætter på at du kører dine sider på egen server, så du ikke er
afhængig af hvad webhotellerne understøtter.

--
Philip - http://chartbase.dk

---

Philip Nunnegaard wrote:
> Stig Johansen skrev:
>
>> Jeg er vant til at lave 'kritiske' systemer, hvor det er essentielt at
>> man
>> kan lave en recovery enten til 'last comitted transaction', eller et
>> fixed
>> tidspunkt.
>
>> Men det er klart, at hvis man ikke har det behov, så er det et
>> ligegyldigt
>> argument.
>
> Og da ovenstående er sort snak for mig, er det nok fordi jeg ikke har
> behovet.
> Det kunne straks være mere interessant at høre hvilken database du så
> bruger.
> Jeg gætter på at du kører dine sider på egen server, så du ikke er
> afhængig af hvad webhotellerne understøtter.

Hvis jeg må blande mig ;) - kunne jeg forestille mig MsSQL, PostgreSQL
og måske også DB2 (så vidt jeg husker - har aldrig selv brugt den).

PostgreSQL tror jeg de har hos nogle webhotel udbydere? (Har dog også
egen server :( så jeg installerer blot det jeg skal bruge).

Men igen - 99,99% af alle "hjemmeprogrammører" vil aldrig bruge det -
selvom de havde adgang til det.

:)

/Johan

---

Johan Holst Nielsen skrev:

> Hvis jeg må blande mig ;) - kunne jeg forestille mig MsSQL, PostgreSQL
> og måske også DB2 (så vidt jeg husker - har aldrig selv brugt den).

Jeg gættede selv på PostgreSQL eller Oracle.
Førstnævnte understøttes af nogle få webhoteller, men efter sigende
skulle det være ret svært for en nybegynder at kaste sig ud i.

De fleste "Hr. & Fru Danmark-webhoteller" kører enten med PHP & MySQL
eller ASP & Access, evt. med mulighed for tilkøb af MS SQL.

Personligt finder jeg de løsninger med tilkøb af MS SQL for ufleksible
til mit behov. Jeg har det bedst med at jeg ved at jeg har f.eks. 1500
MB plads, og så er det ligemeget om det er 800 MB database og 700 andet
indhold eller kun 30 MB database og 1470 MB andet indhold.
(Det er gerne i den størrelsesorden ved de "pakker" og en pæn sjat penge
ekstra hvis man har brug for mere DB-plads. Danhost tilbyder 25 MB MS
SQL, såfremt man har Windows-hotel. 25 MB er for lidt til mig, og i
øvrigt kører jeg med *nix-hotel)

På mine sider fylder databasen en pæn andel at det totale indhold.

> Men igen - 99,99% af alle "hjemmeprogrammører" vil aldrig bruge det -
> selvom de havde adgang til det.

Jeg er nok at tælle blandt de 99,99%. Mit webhotel tilbyder dog kun MySQL.

--
Philip - http://chartbase.dk

---

Johan Holst Nielsen wrote:

> Hvis jeg må blande mig ;) - kunne jeg forestille mig MsSQL, PostgreSQL
> og måske også DB2 (så vidt jeg husker - har aldrig selv brugt den).

Jeg går meget op i SQL standard compliance, så jeg bruger de(n) database
kunden har, herunder
MS SQLServer, Oracle, en enkelt DB/2.

Du har ret i, at mit metier er interne systemer til større virksomheder,
hvor data integriteten er et must.

> Men igen - 99,99% af alle "hjemmeprogrammører" vil aldrig bruge det -
> selvom de havde adgang til det.

Jeg er lidt i tvivl om du mener, at denne gruppe kun er for hjemmehøkere
eller også andre ?

Jeg kan se behovet for alle typer af reservations systemer, webshops,
specielt hvis der indgår betalinger - osv.

Spørgsmålet er om man _har_ behovet, eller ikke _ved_ man har behovet.

Triggeren var OP's bemærkning:
> Min aktuelle udfordring er, at jeg skal have til at lave en temmelig
> db-tung hjemmeside

Afhængig af hvad han mener med 'temmelig db-tung' side, får jeg indtrykket
af, at han er ved at bevæge sig ud over 'begynderstadiet'.

Så jeg synes ikke min oplysning er så irrelevant som du indikerer.

Hvis det er mænger, så tror jeg ikke der er nogen forskel på Access og
mySQL, forudsat man behandler Access 'rigtigt'.

Myten om at Access skulle være langsom beror nok på en forkert tilgang til
ASP/Access (forskellige cursorlocations/cursortypes/locking scheme m.m)

Hvis man laver samme (forkerte) tilgang overfor mySQL, så vil den kon også
'brække sig'.

Men hvordan fortolker du 'db-tung', nu da hverken du eller jeg ved hvad OP's
egentlige problem er?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Johan Holst Nielsen wrote:
>
>> Hvis jeg må blande mig ;) - kunne jeg forestille mig MsSQL, PostgreSQL
>> og måske også DB2 (så vidt jeg husker - har aldrig selv brugt den).
>
> Jeg går meget op i SQL standard compliance, så jeg bruger de(n) database
> kunden har, herunder
> MS SQLServer, Oracle, en enkelt DB/2.

Fint fint.

> Du har ret i, at mit metier er interne systemer til større virksomheder,
> hvor data integriteten er et must.

Godt - så langt så godt.

>> Men igen - 99,99% af alle "hjemmeprogrammører" vil aldrig bruge det -
>> selvom de havde adgang til det.
>
> Jeg er lidt i tvivl om du mener, at denne gruppe kun er for hjemmehøkere
> eller også andre ?

Nej - for I så fald burde jeg ikke være her ;)

Men under dette subject ser det ud til vi primært taler om en person der
ikke skal udvikle netbank systemer eller lign.

> Jeg kan se behovet for alle typer af reservations systemer, webshops,
> specielt hvis der indgår betalinger - osv.

Principielt ja - men teoretisk er det ikke sådan.

> Spørgsmålet er om man _har_ behovet, eller ikke _ved_ man har behovet.

Det er nok en blanding. Men jeg har set hundredevis af webshops UDEN, og
de har ikke fejlet i flere år trods mange års drift. Så ser ikke det
store problem, med mindre vi snakker om 1k+ ordre om dagen.

> Triggeren var OP's bemærkning:
>> Min aktuelle udfordring er, at jeg skal have til at lave en temmelig
>> db-tung hjemmeside
>
> Afhængig af hvad han mener med 'temmelig db-tung' side, får jeg indtrykket
> af, at han er ved at bevæge sig ud over 'begynderstadiet'.
>
> Så jeg synes ikke min oplysning er så irrelevant som du indikerer.

Fair - vi har 2 forskellige opfattelser.

> Hvis det er mænger, så tror jeg ikke der er nogen forskel på Access og
> mySQL, forudsat man behandler Access 'rigtigt'.
>
> Myten om at Access skulle være langsom beror nok på en forkert tilgang til
> ASP/Access (forskellige cursorlocations/cursortypes/locking scheme m.m)

Tjah. Jeg har ikke *selv* arbejdet med Access siden slut 90'erne, hvor
jeg rodede med ASP. Men har flere venner og bekendte, der simpelthen
måtte droppe Access pga. problemer ved størrere datamængder - hvor det
løste sig da de skiftede til MySQL. (Skal siges at de siden har skiftet
til MsSQL)

> Hvis man laver samme (forkerte) tilgang overfor mySQL, så vil den kon også
> 'brække sig'.

Og samme med MsSQL og alle andre databaser - der er vidst ikke den store
forskel...

> Men hvordan fortolker du 'db-tung', nu da hverken du eller jeg ved hvad OP's
> egentlige problem er?

DB tung kan betyde meget. Et lille CMS site f.eks. via Joomla kan man
vel definere som DB tungt, eftersom de meste af indholdet ligger i
databasen - og det ikke blot er logins der ligger i databasen.

Selvfølgelig kan det også betyde, som du sikkert har opfattet det, at vi
taler om et site med en stor mængde data i databasen.

I øvrigt - hvor ville *du* købe webhotel til en gut - nu når MySQL er en
papdatabase (som iøvrigt bruges af nogle af Danmarks største
virksomheder). Jeg regner ikke med personen bag har tænkt sig at
administere sin egen server eller lign.. Og der er ikke mange PHP
hoteller man kan få med andet end MySQL (og få tilfælde PostgreSQL). Det
er, ligegyldigt hvad, en udfordring man bliver nødt at tage med i øvelserne.

/Johan

---

Johan Holst Nielsen wrote:

> Stig Johansen wrote:
>
> Principielt ja - men teoretisk er det ikke sådan.

Jo.

>
>> Spørgsmålet er om man _har_ behovet, eller ikke _ved_ man har behovet.
>
> Det er nok en blanding. Men jeg har set hundredevis af webshops UDEN, og
> de har ikke fejlet i flere år trods mange års drift. Så ser ikke det
> store problem, med mindre vi snakker om 1k+ ordre om dagen.

Det er en risikovurdering, og har ikke noget med antallet at gøre.
Jeg er enig i, at man kan forlade sig på, at Hardwaren holder, og negligerer
en nedbrudssituation - men den eksisterer(risikoen).

> Fair - vi har 2 forskellige opfattelser.

Måske - måske ikke.
Hvis det er et ukritisk 'opslagsværk', så er min holdning, at det 'stort set
er ligegyldigt' hvilken database man vælger.

>> Myten om at Access skulle være langsom beror nok på en forkert tilgang
>> til ASP/Access (forskellige cursorlocations/cursortypes/locking scheme
>> m.m)
>
> Tjah. Jeg har ikke *selv* arbejdet med Access siden slut 90'erne, hvor
> jeg rodede med ASP. Men har flere venner og bekendte, der simpelthen
> måtte droppe Access pga. problemer ved størrere datamængder

Hvis vi skal uddybe det, skal vi nok over i .databasegruppen

Hvis man bruger Access via netværk(storage), ja, så du'r den ikke til en
skid.

Men hvis man bruger den serverside, så ser jeg ingen forskel på at bruge
COM+ eller en serverprocess (bortset fra serverprocesser giver ekstra
overhead)

FYI: Nu du er inde på årstal, så har jeg arbejdet med større
databasersystemer siden '80.

> løste sig da de skiftede til MySQL. (Skal siges at de siden har skiftet
> til MsSQL)

En 'forkert tilgang til databaser kan lægge alt ned, incl MS SQLServer osv.
Det er let nok - det er sværere at opretholde performance når det bliver
'stort'

>> Hvis man laver samme (forkerte) tilgang overfor mySQL, så vil den kon
>> også 'brække sig'.
>
> Og samme med MsSQL og alle andre databaser - der er vidst ikke den store
> forskel...

Enig, jeg kom til at skrive det lidt længere oppe.

> I øvrigt - hvor ville *du* købe webhotel til en gut - nu når MySQL er en
> papdatabase

Det vil jeg ikke - jeg forholder mig til OP's oprindelige indlæg:
.....
> Jeg har i mange år udviklet hjemmesider til private, foreninger og
> mindre virksomheder

I min optik falder han ikke ind under dine:
> 99,99% af alle "hjemmeprogrammører"


> Jeg regner ikke med personen bag har tænkt sig at
> administere sin egen server eller lign..

Jeg ved ikke hvad 'personen bag' har tænkt sig, så jeg ved ikke hvilken
løsning, der er 'den rigtige'.

Kommer blot med lidt impulser.
--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
>>> Spørgsmålet er om man _har_ behovet, eller ikke _ved_ man har behovet.
>> Det er nok en blanding. Men jeg har set hundredevis af webshops UDEN, og
>> de har ikke fejlet i flere år trods mange års drift. Så ser ikke det
>> store problem, med mindre vi snakker om 1k+ ordre om dagen.
>
> Det er en risikovurdering, og har ikke noget med antallet at gøre.
> Jeg er enig i, at man kan forlade sig på, at Hardwaren holder, og negligerer
> en nedbrudssituation - men den eksisterer(risikoen).

Det har til deles noget med antallet at gøre. Det er begrænset hvor
mange resourcer man ønsker at sætte ind i forskellige situationer.

Hvis du kører en replikering mod en anden server via MySQL f.eks., vil
du ikke opleve særlig store datatab.

>> Fair - vi har 2 forskellige opfattelser.
>
> Måske - måske ikke.
> Hvis det er et ukritisk 'opslagsværk', så er min holdning, at det 'stort set
> er ligegyldigt' hvilken database man vælger.

Okay - så er vi (næsten) enige. Men du skriver stort set - så vi er nok
enige :)

>>> Myten om at Access skulle være langsom beror nok på en forkert tilgang
>>> til ASP/Access (forskellige cursorlocations/cursortypes/locking scheme
>>> m.m)
>> Tjah. Jeg har ikke *selv* arbejdet med Access siden slut 90'erne, hvor
>> jeg rodede med ASP. Men har flere venner og bekendte, der simpelthen
>> måtte droppe Access pga. problemer ved størrere datamængder
>
> Hvis vi skal uddybe det, skal vi nok over i .databasegruppen
>
> Hvis man bruger Access via netværk(storage), ja, så du'r den ikke til en
> skid.
>
> Men hvis man bruger den serverside, så ser jeg ingen forskel på at bruge
> COM+ eller en serverprocess (bortset fra serverprocesser giver ekstra
> overhead)

Som nævnt - jeg har ikke store erfaringer med Access databaser - det er
MEGET begrænset, hvor meget jeg kender til det. Jeg har kun arbejdet
overfladisk med det. Min primære viden (eller mangel på samme) har jeg
fået via venner og bekendte, primært .NET udviklere.

> FYI: Nu du er inde på årstal, så har jeg arbejdet med større
> databasersystemer siden '80.

Tillykke ;)
Mit årstal var ikke for at være erfaring - tværtimod - mere at Access
højst sandsynlig har udviklet sig siden slut halvfemserne.

>> løste sig da de skiftede til MySQL. (Skal siges at de siden har skiftet
>> til MsSQL)
>
> En 'forkert tilgang til databaser kan lægge alt ned, incl MS SQLServer osv.
> Det er let nok - det er sværere at opretholde performance når det bliver
> 'stort'

God. Vi er trods alt enige en del steder ;)

>> I øvrigt - hvor ville *du* købe webhotel til en gut - nu når MySQL er en
>> papdatabase
>
> Det vil jeg ikke - jeg forholder mig til OP's oprindelige indlæg:
> ....
>> Jeg har i mange år udviklet hjemmesider til private, foreninger og
>> mindre virksomheder
>
> I min optik falder han ikke ind under dine:
>> 99,99% af alle "hjemmeprogrammører"

Okay. Beklager det var en "grim" betegnelse.

Dog mener jeg stadig ikke at brugeren falder udenfor webhotel-genren -
hvis man kan kalde ham for det?

>> Jeg regner ikke med personen bag har tænkt sig at
>> administere sin egen server eller lign..
>
> Jeg ved ikke hvad 'personen bag' har tænkt sig, så jeg ved ikke hvilken
> løsning, der er 'den rigtige'.
>
> Kommer blot med lidt impulser.

Helt fint. Altid sund med lidt debat, selvom jeg føler vi er rimelig
off-topic efterhånden. Vi burde nok hoppe over i databasegruppen, hvis
diskussionen skal køre ret meget længere...

/Johan

---

Johan Holst Nielsen wrote:

> Vi burde nok hoppe over i databasegruppen, hvis
> diskussionen skal køre ret meget længere...

Given the facts fra OP:
> Jeg har i mange år udviklet hjemmesider til private, foreninger og
> mindre virksomheder i ASP+Access, men har de sidste par måneder
> overvejet at skifte al fremtidig udvikling til PHP og MySQL.
> Hvis jeg selv skal sige det, så er jeg ret skrap til ASP, JavaScript,
> VBscript og SQL,

Forstår jeg ikke hvilket problem, og hvilken løsnimg, der gør at 'man' vil
lave et paradigmeskifte fra ASP/DB, til PHP/mySQL?

PHP tilbyder ikke mere end ASP (hvis man kan installere sine egne
komponenter)

Men hvilket problem har OP, siden han vil skifte?

Hvis manden(OP) er skrap til ASP, hvilken fordel har han så ved at skifte?

Performanceproblemer bliver ikke løst ved at skifte DB,

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Johan Holst Nielsen wrote:
>
>> Vi burde nok hoppe over i databasegruppen, hvis
>> diskussionen skal køre ret meget længere...
>
> Given the facts fra OP:
>> Jeg har i mange år udviklet hjemmesider til private, foreninger og
>> mindre virksomheder i ASP+Access, men har de sidste par måneder
>> overvejet at skifte al fremtidig udvikling til PHP og MySQL.
>> Hvis jeg selv skal sige det, så er jeg ret skrap til ASP, JavaScript,
>> VBscript og SQL,
>
> Forstår jeg ikke hvilket problem, og hvilken løsning, der gør at 'man' vil
> lave et paradigmeskifte fra ASP/DB, til PHP/mySQL?

Måske har spørgeren erfaret, at hovedparten af (de potentielle) kunder
har webhoteller, som er PHP/mySql baserede..

---

Stig Johansen wrote:
> Forstår jeg ikke hvilket problem, og hvilken løsnimg, der gør at 'man' vil
> lave et paradigmeskifte fra ASP/DB, til PHP/mySQL?

Næh. Eftersom han ikke spørger *hvorfor* han skal skifte, men *hvor
besværligt* det er at skifte, må man formode at der er en god årsag til det.

> PHP tilbyder ikke mere end ASP (hvis man kan installere sine egne
> komponenter)

Nej - men der tilbydes andre elementer. F.eks. en god slat OpenSource
CMS'er, som jeg *personligt* synes er bedre end dem der tilbydes under ASP.

> Men hvilket problem har OP, siden han vil skifte?

Aner det ikke.

> Hvis manden(OP) er skrap til ASP, hvilken fordel har han så ved at skifte?

Ingen siger det nødvendigvis er en fordel. Da jeg i sin tid skiftede var
der flere årsager. Bl.a. at PHP var hurtigere at udvikle i (for mig),
samt at der var en god slat tools til PHP, som jeg ikke umiddeltbart på
den tid kunne finde til ASP. Det er så 10 år siden - så meget kan blive
ændret pga. det.

> Performanceproblemer bliver ikke løst ved at skifte DB,

Den diskussion gider jeg ikke køre længere. Så må den tages op i
databasegruppen.

Målet med gruppen her, er ikke at vi skal overbevise brugerne om de ikke
skal skifte, hvis de har et ønske om at skifte. Og det virker til det er
det du er igang med nu.

Vi må formode at brugeren har taget sine overvejelser - ellers må der
oprettes en ny tråd.

Gider ikke diskutere den gamle "religionskrig" mellem PHP og ASP. Det er
mit liv for kort tid.

/Johan

---

Johan Holst Nielsen wrote:

> samt at der var en god slat tools til PHP, som jeg ikke umiddeltbart på
> den tid kunne finde til ASP. Det er så 10 år siden - så meget kan blive
> ændret pga. det.

Nææh, men med det rigtige tool, også for 10 år siden, tager det vist ikke
ret mange splitsekunder at lave sine egne komponenter (hvis man har et sted
at installere det)

> Målet med gruppen her, er ikke at vi skal overbevise brugerne om de ikke
> skal skifte, hvis de har et ønske om at skifte. Og det virker til det er
> det du er igang med nu.

Nææh, undrer mig bare over at OP, som tilsyneladende er velbevandret udi ASP
vil skifte:
jfr:
> Hvis jeg selv skal sige det, så er jeg ret skrap til ASP

Jeg er ikke ude på at lave religionskrig mellem ASP og PHP (eller andre
scriptsprog) - de er lige langsomme.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Johan Holst Nielsen wrote:
>
>> Målet med gruppen her, er ikke at vi skal overbevise brugerne om de ikke
>> skal skifte, hvis de har et ønske om at skifte. Og det virker til det er
>> det du er igang med nu.
>
> Nææh, undrer mig bare over at OP, som tilsyneladende er velbevandret udi ASP
> vil skifte:
> jfr:
>> Hvis jeg selv skal sige det, så er jeg ret skrap til ASP
>
> Jeg er ikke ude på at lave religionskrig mellem ASP og PHP (eller andre
> scriptsprog) - de er lige langsomme.

Jeg synes stadig det er temmelig off-topic at begynde at betvivle OP's
beslutningsdygtighed. Han har ytret ønske om at skifte - hvorfor skal
han så udspørges om det? Det kommer reelt ikke os ved.

Jeg kunne finde masse af årsager til at skifte.

/Johan

---

Philip Nunnegaard skrev:

> > Jeg er vant til at lave 'kritiske' systemer, hvor det er essentielt at man
> > kan lave en recovery enten til 'last comitted transaction', eller et fixed
> > tidspunkt.

> Og da ovenstående er sort snak for mig, er det nok fordi jeg ikke har
> behovet.

Ja.

Hvis en bank skal udføre en transaktion hvor der overføres penge
fra én konto til en anden, skal der udføre to operationer - en
hævning og en sænk ... øh, indsættelse.

Hvis hævningen går godt, men indsættelsen kikser, er det en
katastrofe. Data er korrupte.

Derfor er det nødvendigt at kunne sige "Ups!" og vende tilbage
til situationen før man forsøgte sig med transaktionen. Det
hedder "recovery", "roll back" eller lignende.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:

> Hvis hævningen går godt, men indsættelsen kikser, er det en
> katastrofe. Data er korrupte.

Det er transaction handling, som Access har understøttet i laaang tid, og
vistnok nu (visse versioner?) af mySQL.

En database der ikke engang understøtter transaction handling (aka ACID) vil
jeg absolut kalde en pap-database.

> Derfor er det nødvendigt at kunne sige "Ups!" og vende tilbage
> til situationen før man forsøgte sig med transaktionen. Det
> hedder "recovery", "roll back" eller lignende.

Det hedder commit/riollback, men det er ikke det, jeg snakker om.

Kald det disaster/recovery i stedet.

Det handler om, at hvis der sker et nedbrud (disk fejl eller lign.) eks.
midt på dagen, og man tager eks. natlig/ugentlig backup, så skal man ud fra
sidste backup+transaction log, kunne genskabe data til umiddelbart før
nedbruddet, eller et givet tidspunkt før nedbruddet.

Ellers mister man data fra backup til nedbrud.

(NB: Det er set i det virkelige liv, at 2 diske i RAID er stået af)

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Det handler om, at hvis der sker et nedbrud (disk fejl eller lign.) eks.
> midt på dagen, og man tager eks. natlig/ugentlig backup, så skal man ud fra
> sidste backup+transaction log, kunne genskabe data til umiddelbart før
> nedbruddet, eller et givet tidspunkt før nedbruddet.

For en ordens skyld, bør det nok nævnes, at MySQL understøtter dette
(interesserede kan søge efter "binary log" i MySQL manualen).

Men hvis man har behovet, bør man nok tage sig en grundig snak med sit
webhotel - der er f.eks. ikke meget sjov ved at have sin log liggende på
samme RAID-sæt som ens data!

M.v.h.

Jonathan

--
Er din email vigtig? Er du træt af, at din hjemmeside er nede?
Stabilt webhotel på redundant setup med daglig backup.
POP3, IMAP, PHP, JSP, Java, Perl, Python, Telnet, SSH, Cron-jobs m.v.
http://www.jsp-hotel.dk/

---

Stig Johansen wrote:
> Johan Holst Nielsen wrote:
>
>> Hvad er dit argument for MySQL er en pap-database?
>
> 'pap-database' er måske et hårdt ord, og det skal nok ikke tages
> bogstaveligt.

Ja meget.

> Jeg er vant til at lave 'kritiske' systemer, hvor det er essentielt at man
> kan lave en recovery enten til 'last comitted transaction', eller et fixed
> tidspunkt.

Tjah - så er det vidst begrænset hvor mange databaser vi taler om der
ikke er pap-databaser? Især hvis man ikke skal ud i noget hvor man skal
have special webhotel, egen server o.lign... den eneste jeg kan komme i
tanke om som fungerer godt sammen med php og er tilgængelig på
webhotelmarkedet er pgsql.

> Så de databaser der ikke kan det, kalder jeg blot 'pap-databser' over en
> kam.

Tjah - jeg har en cykel med Dura Ace gear - og vil nødigt køre med
andet. Men derfor kalder jeg ikke alle andre cykler pap-cykler.

Generelt synes jeg det er et temmeligt dårligt udtryk - især overfor en
relativ nybegynder i verdenen. Især fordi MySQL overgår Access med
længder - så putte dem i samme kasse er dårlig kategorisering.

> Men det er klart, at hvis man ikke har det behov, så er det et ligegyldigt
> argument.

Yes - dvs. for personer som ovenstående vil det i 99,999% af tilfældene
være ligegyldigt. Hvorfor så give noget information der var så dårligt
uddybet.

/Johan

---

Stig Johansen skrev:

> Har du nogle faktuelle sammenlingninger, eller er det subjektivt?

Jeg har ikke nogle konkrete målinger, hvis det er det du efterlyser, så
det er nok det som du kalder subjektivt.

Når jeg taler om "performance", tænker jeg først og fremmest på hvor
lang tid der går fra jeg klikker, til siden er færdig med at blive
indlæst på min skærm.
Jeg kan så ikke udelukke at min følelse har været ren placebo.

--
Philip - http://chartbase.dk

---

Philip Nunnegaard <nunnenospam@hitsurf.dk> wrote in
news:4a1f859d$0$15891$edfadb0f@dtext01.news.tele.dk:

> Jeg kan ikke finde ud af at lave hjemmesider i
> WYSIWYG-programmer.

Visual Studio er ikke (kun) et wysiwyg program. Jeg har brugt VS til
hjemmeside i flere år efterhånden og har faktisk ikke brugt design delen
til det overhovedet. Bruger man ikke ASP.NET er Visual Studio dog nok under
alle omstændigheder det forkerte program til webudvikling.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

Philip, tak for et super svar!
Som jeg læser dit indlæg, er vi nogenlunde i samme båd.
Min aktuelle udfordring er, at jeg skal have til at lave en temmelig
db-tung hjemmeside, og der vil Access nok komme til kort.
Jeg er overbevist...det bliver et total skifte fra asp til php
Mvh
Peter

---

On Mon, 01 Jun 2009 09:25:42 +0200
Stig Johansen <wopr.dk@gmaill.com> wrote:

>
> Det er transaction handling, som Access har understøttet i laaang tid, og
> vistnok nu (visse versioner?) af mySQL.
>
MySQL har understøttet transaktioner lang tid før MS Access.
Understøttelse af transaktioner dateres sig tilbage til før år 2000, og
har blot været et spørgsmål om at anvende en passende database engine..

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Michael Rasmussen wrote:

> MySQL har understøttet transaktioner lang tid før MS Access.
> Understøttelse af transaktioner dateres sig tilbage til før år 2000, og
> har blot været et spørgsmål om at anvende en passende database engine.

Jeg er ikke interesseret i at starte en 'flame war', men med Access 2K
skulle det efter sigende være samme optimizer/storage engine som i MS
SQLServer.

Som sagt vil jeg ikke promovere Access eller mySQL, da der nok er en årsag
til, at Access ikke kan det samme som MS SQLServer, og på samme måde at
mySQL ikke kan(kunne) det samme som SAPDB, later MaxDB, som de (mySQL)
sikkert har lært lidt af.

Hvad der sker i fremtiden, efter Oracle har overtaget den, vil jeg ikke
udtale mig om, men et gæt er, at den på ingen måde kommer til at konkurrere
med Oracles egne produkter.

--
Med venlig hilsen
Stig Johansen

---

On 30 Maj, 06:19, Stig Johansen <wopr...@gmaill.com> wrote:

> Så de databaser der ikke kan det, kalder jeg blot 'pap-databser' over en
> kam.
Hvis en given anvendelse ikke fordrer 'det store gear', vil den app
der blot løser opgaven ofte performe bedre.

---

On Mon, 01 Jun 2009 15:56:14 +0200
Stig Johansen <wopr.dk@gmaill.com> wrote:

>
> Jeg er ikke interesseret i at starte en 'flame war', men med Access 2K
Det er jeg heller ikke, men urigtige oplysninger bør ikke stå upåtalt
hen.

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.