Voor- en nadelen database gestuurde website

[intert0y]

Ik probeer de mensen hier op mijn werk te overtuigen van het gebruik van een database gestuurde website maar ik kan ze nog niet echt overtuigen.

Ik heb de volgende punten al aangegeven.

1. Aanpassen van content hoeft niet per definitie door de webmaster te gebeuren. Tekst kan worden aangepast in vaste lay-out.

2. Sneller toevoegen en verwijderen van content.

3. Door gebruik van login door gebruiker is het mogelijk om het specifieke surfgedrag van deze gebruiker op de website te analyseren. (voordeel, klant die veel informatie over een bepaald onderwerp opvraagt,hier eventuele aanbiedingen over doen.)

4. Personalisering content voor de gebruiker die ingelogged is. (informatie op maat)

5. Minder foutgevoelig. (je vergeet bij 100en html-bestanden nog al snel een aanpassinkje te maken.)

6. Alle informatie staat standaard in de juiste lay-out geen probleempjes meer met pagina's waar de tabel stiekum groter is dan op de andere.

[dusty]

5. Minder Foutgevoelig.

Database plat -> Helemaal geen informatie meer.

Wat nou MINDER fout gevoelig

[dusty]

6. Alle informatie staat standaard in de juiste lay-out geen probleempjes meer met pagina's waar de tabel stiekum groter is dan op de andere.

Dat kan ook met een Content Management systeem, Ligt eraan hoe goed de text wordt gecontroleerd in het systeem zelf.

[intert0y]

smartass, je snapt neem ik aan wel wat ik bedoel maar ik ken jouw soort.

[Verwijderd]

Op dinsdag 28 augustus 2001 15:43 schreef dusty het volgende:
5. Minder Foutgevoelig.

Database plat -> Helemaal geen informatie meer.

Wat nou MINDER fout gevoelig

Is maar 1 fout

...

Belangrijkste argumenten 'voor' zijn wel gemaakt lijkt me

[dusty]

3. Door gebruik van login door gebruiker is het mogelijk om het specifieke surfgedrag van deze gebruiker op de website te analyseren. (voordeel, klant die veel informatie over een bepaald onderwerp opvraagt,hier eventuele aanbiedingen over doen.)

Dit kan ook gedaan worden zonder een content management systeem.

[dusty]

Op dinsdag 28 augustus 2001 15:45 schreef ItSnows het volgende:
Belangrijkste argumenten 'voor' zijn wel gemaakt lijkt me

Ik zie maar 1 HELFT van een van de belangrijkste argument.

[dusty]

Op dinsdag 28 augustus 2001 15:45 schreef intert0y het volgende:
smartass, je snapt neem ik aan wel wat ik bedoel maar ik ken jouw soort.

En wat voor soort is dat dan ?

[dusty]

1. Aanpassen van content hoeft niet per definitie door de webmaster te gebeuren. Tekst kan worden aangepast in vaste lay-out.

dat hoeft helemaal geen vaste lay-out te zijn. Dat ligt aan de content systeem zelf. Je KAN het echter forceren. (maar dat is een ander punt)

[intert0y]

en nu nog een aantal nadelen zodat ik de mensen ook wat nadeeltjes kan geven.

Ik als geboren optimist kan namelijk ff geen nadelen bedenken. Hooguit die database crash.

Maar er wordt toch al gedatabased deels dat moet zowiezo

[dusty]

Je hebt iemand nodig die de Content Management Systeem kan onderhouden. (is wat lastiger dan alleen de HTML onderhouden)

[dusty]

Over het algemeen zijn er geen uitzonderingen op layout mogelijk.

[Dennis]

Op dinsdag 28 augustus 2001 15:54 schreef dusty het volgende:
Over het algemeen zijn er geen uitzonderingen op layout mogelijk.

leve CSS

[Nielsz]

Dusty door de bocht

[mbravenboer]

Als de content niet dynamisch is (niet door de website bezoekers aan te passen) zou je ook een XML -> XSLT -> XHTML oplossing kunnen gebruiken.

Er zijn bij vast voordelen te verzinnen van deze oplossing t.o.v. het gebruik van een database systeem .

[tomato]

Op dinsdag 28 augustus 2001 15:58 schreef mbravenboer het volgende:
Als de content niet dynamisch is (niet door de website bezoekers aan te passen) zou je ook een XML -> XSLT -> XHTML oplossing kunnen gebruiken.

Als ik het niet dacht
Maar dit kun je natuurlijk ook prima doen wanneer je content wel dynamisch is.

Er zijn bij vast voordelen te verzinnen van deze oplossing t.o.v. het gebruik van een database systeem .

Waarom niet allebei?

[mbravenboer]

tomato: Als ik het niet dacht

Ik moet zowat mijn spammer rol aan gaan passen.

Maar dit kun je natuurlijk ook prima doen wanneer je content wel dynamisch is.

Yep, dat klopt maar bij zeer dynamische content (forum, reactie systeem) krijg je wel problemen als je platte XML files opslaat.

Waarom niet allebei?

Dat is in het geval van zeer dynamische content een uitstekende oplossing . Als je bijvoorbeeld een vrij statische product catalogus hebt, is het wat minder noodzakelijk en bespaart zuivere XML content je een aantal problemen: database beheer, SQL kennis enz.

Je kan voor XML gebaseerde content net zo makkelijk beheer tools schrijven als voor database gebaseerde content .

[dusty]

Op dinsdag 28 augustus 2001 15:58 schreef mbravenboer het volgende:
Als de content niet dynamisch is (niet door de website bezoekers aan te passen) zou je ook een XML -> XSLT -> XHTML oplossing kunnen gebruiken.

Er zijn bij vast voordelen te verzinnen van deze oplossing t.o.v. het gebruik van een database systeem .

Content Management Systeem staat in principe los van een database.. daar kan ook iets XML-achtigs achter staan.

[Steven]

Je hebt een server nodig die een database ondersteunt... (= nadeel) Een standaard XS4all accountje voldoet dus niet meer!

[Annie]

Nadelen (sommige zaken zijn al min of meer genoemd):

1. je hebt een database administrator nodig (is wat anders dan een query-bakker ), m.a.w. kost dus onderhoud
2. performance verlies t.o.v. statische pagina's
3. afhankelijk van welke database je neemt ben je geld kwijt aan software licensie(s)
4. extra kennis nodig bij ontwikkeling
5. .... uhm, iemand anders nog wat

Schrijf gewoon alle voor en nadelen op, hoe triviaal cq. belachelijk ze ook lijken. Eerst brainstormen, later kan je daar waardes aan gaan hangen.
En daarna kan je de nadelen dus gaan afwegen tegen de voordelen en dan zullen jullie samen moeten beslissen welke het zwaarst wegen.

[Brakkie]

MMMM Waar zijn alle PHP en MYSQL freakz?!?!!

[intert0y]

Op dinsdag 28 augustus 2001 16:52 schreef Steven_NL het volgende:
Je hebt een server nodig die een database ondersteunt... (= nadeel) Een standaard XS4all accountje voldoet dus niet meer!

mensen er draait hier gewoon een dedicated sun solaris machine dus dat zit wel goed. Apache en MySQL dus dat is hier niet relevant.

[raptorix]

Op dinsdag 28 augustus 2001 17:49 schreef brakkie het volgende:
MMMM Waar zijn alle PHP en MYSQL freakz?!?!!

[Brakkie]

Op dinsdag 28 augustus 2001 19:08 schreef raptorix het volgende:

[..]

[afbeelding]

Jij bent er dus geen...

[mbravenboer]

brakkie: Jij bent er dus geen...

Ezel bedoel je?

[Brakkie]

Ezel bedoel je?

duh

[intert0y]

mensen ajb, er zitten altijd van die mensen onder jullie die overal wel iets negatiefs over hebben te vertellen en die in deze dus nadelen van het gebruik kunnen zijn. Kom op!

* intert0y wil nadelen horen !!!!

[bloody]

Op woensdag 29 augustus 2001 09:47 schreef intert0y het volgende:
mensen ajb, er zitten altijd van die mensen onder jullie die overal wel iets negatiefs over hebben te vertellen en die in deze dus nadelen van het gebruik kunnen zijn. Kom op!

* intert0y wil nadelen horen !!!!

het nadeel is dat je illegale quotes moet afvangen

[demonite]

maar een rare discussie dit...

wie vraagt zich nou af waarom je een database gestuurde website moet hebben ??

De vraag die jij aan je collega's zou moeten stellen is "wat willen met onze website doen? wat voor functionaliteit moet ze bieden?"

en dan ga je pas nadenken over de implementatie daarvan... lijkt me zo ??


en nou heb ik ook weer niet zo heel veel ervaring met dit soort dingen hoor.. Maar het lijkt me toch vrij duidelijk dat als je een zeer dynamische website hebt, dat je daar iets anders achter moet hebben zitten als alleen plat html ? dan komt daar php / asp / jsp en dergelijke bij kijken... en waar die hun data dan vandaan halen lijkt me ook niet zo heel ingewikkeld.

degene die het wiel opnieuw probeert uit te vinden door alles in tekstfiles op te slaan is niet goed bij z'n hoofd... Daar gaan bugs in komen, ontwikkeltijd is lang etc.

Lijkt me toch vrij vanzelfsprekend dat daar een database achter komt te hangen?

[drm]

Voordelen van db-driven gaan pas zwaar tellen als je veel content hebt.

Bij een kleine site met veel statische tekst die niet vaakt gewijzigd hoeft te worden is er echt geen sprake van db-driven.

Maar het moeilijkste er aan is dat het schaalbaar moet zijn, flexibel, de klant wil namelijk altijd dingen die technisch het rotst te realizeren zijn.

Waar webdevvers voor op moeten passen (maak ik mezelf ook schuldig aan) is dat ze niet doen wat het best en efficientst is voor de klant c.q. opdrachtgever maar wat ze zelf het leukst vinden om te maken. Tuurlijk is db-driven veel leuker om te maken, maar plain HTML is goedkoper, bij kleine sites sneller klaar, hogere performance.
De klant kan het vaak helemaal niet schelen wat voor techniek erachter ziet, en hoe mooi je de html gemaakt hebt, blablabla, maar hoe het eruit ziet, en of het werkt.

Ik weet niet precies wat voor punt ik nou wou maken, maar ik geloof dat ik eventjes ging spuien

[drm]

demonite zei:
degene die het wiel opnieuw probeert uit te vinden door alles in tekstfiles op te slaan is niet goed bij z'n hoofd... Daar gaan bugs in komen, ontwikkeltijd is lang etc.

onzin. Textfiles zijn veel makkelijker te onderhouden qua content. Zijn alleen klote te structureren in een site. Hier en daar heb ik liever een output van textfile dan dat ik een complete db-connection moet maken en sql-queries uitvoeren etc.

[PhoeniX-]

Deze week moest ik weer een en ander aan html bakken .. steeds dezelfde pagina met andere kleuren enzo .. en dan is een wat geautomatiseerder systeem toch wel ERG handig .. ik denk tydens het maken van statische site gelyk in php (-:

maar een database wordt vooral erg makkelijk als er veel verbanden tussen verschillende elementen in een site zijn .. dit zal ook vast wel kunnen met een (of meer) textfiles .. maar daar heb ik geen ervaring mee (-:

Maar als je dan toch zo'n solaris bak hebt staan, wat houd je tegen ?

[MoBi]

moet op zoek naar een host die php en mysql ondersteund of een andere als je een andere ontwikkelings taal hebt zoals cold fusion. Meestal als je op een virtual account zit, wil de database server nog wel eens traag zijn omdat andere misschien niet zo nette sql schrijven.

[intert0y]

uhmz, het betreft momenteel zo'n 150 a 200 pagina's denk ik. en dan nog een aantal kleinere pop-up-achtige paginaatjes. Bij elkaar 250 html filez.

[Verwijderd]

Grootste nadeel: zoekmachines kunnen er niks mee.

Je pagina's bevatten nl, geen content meer. En als ik bij mezelf naga hoeveel ik opzoek via Google of Altavista, dan is dat een erg gemiste kans. En dan in 't kwadraat, of zo.

[Nielsz]

Als ik meer als 10 pagina's moet maken (ok, eigenlijk doe ik het altijd maar dat is een ander verhaal) doe ik het lekker met db's.
En 10 uur php'en om een mooi systeem maken is leuker en beter als 10 uur htmltjes aanpassen, telkens dezelfde...

[b_buster]

Op woensdag 29 augustus 2001 22:41 schreef Afterlife het volgende:
Grootste nadeel: zoekmachines kunnen er niks mee.

Je pagina's bevatten nl, geen content meer. En als ik bij mezelf naga hoeveel ik opzoek via Google of Altavista, dan is dat een erg gemiste kans. En dan in 't kwadraat, of zo.

Maar t.net is toch ook database-driven? Als ik bv. bij google intik "itanium review" komt tweakers bovenaan te staan.

ja toch?

[Killemov]

[theorie-mode]
Tis maar net hoe je 'database' definieert. Een verzameling html-bestanden kun je ook als database beschouwen. (primary key = path+filename+extension) En zo kun je ook een virtueel filesyteem in een dbms opslaan.
[/theorie-mode]

Bottom line: mooie verhalen over de mogelijkheden van DBMS-en en scripttalen zijn niet voor de oren van de persoon die over de financien gaat. Die is alleen maar geinteresseerd in hoeveel resources NU moeten worden geinvesteerd om LATER mogelijk hoeveel resources te besparen.

Dus: Als jij een webbuilder bent en je maakt alles DBMS-driven, dan ben je jezelf mogelijk aan het wegbezuinigen.

[Verwijderd]

Op woensdag 29 augustus 2001 22:41 schreef Afterlife het volgende:
Grootste nadeel: zoekmachines kunnen er niks mee.

Je pagina's bevatten nl, geen content meer. En als ik bij mezelf naga hoeveel ik opzoek via Google of Altavista, dan is dat een erg gemiste kans. En dan in 't kwadraat, of zo.

uh als een zoekpagina... de pagina opvraagt krijgt hij gewoon een normale uit de database gehaalde door php gegenereede content hoor........ het zelfde wat jij krijgt als jij het opvraagt....

[Verwijderd]

Op donderdag 30 augustus 2001 00:23 schreef raymanontweakers het volgende:
uh als een zoekpagina... de pagina opvraagt krijgt hij gewoon een normale uit de database gehaalde door php gegenereede content hoor........ het zelfde wat jij krijgt als jij het opvraagt....

Klopt, denkfoutje van mij.
Ik zat te denken aan knowledge base achtige sites waarbij je de pagina's alleen maar op kunt vragen na het ingeven van 1 of meer zoekargumenten. Dat is iets wat een zoekmachine niet doet.
Maar wanneer de URL's gewoon op een pagina staan, is er niks aan de hand.

[dusty]

Op woensdag 29 augustus 2001 14:22 schreef PhoeniX- het volgende:
Deze week moest ik weer een en ander aan html bakken .. steeds dezelfde pagina met andere kleuren enzo .. en dan is een wat geautomatiseerder systeem toch wel ERG handig .. ik denk tydens het maken van statische site gelyk in php (-:

De oplossing voor kleuren noemen ze CSS.

[drm]

Op woensdag 29 augustus 2001 22:21 schreef intert0y het volgende:
uhmz, het betreft momenteel zo'n 150 a 200 pagina's denk ik. en dan nog een aantal kleinere pop-up-achtige paginaatjes. Bij elkaar 250 html filez.

Lijkt me zat om er een db achter te hangen. Denk alleen heel goed na over het ontwerp. Dat is het belangrijkste van alles. Dan is scripting etc. peanuts.

[eamelink]

Het enige 2 nadelen, die ik kan verzinnen, zijn dat de DB plat kan gaan (Maar als je die machine goed laat lopen is de kans klein), en de beveiling wordt iets belangrijker. Als je met forms of gewoon via de url variabelen mee gaat sturen, waar je query's van maakt, dan moet je toch altijd iets beter oppassen dan statische html files.

Er zijn altijd van die mannetjes die er zo : uitzien, die rare dingen gaan sturen.

[dusty]

Op donderdag 30 augustus 2001 12:40 schreef eamelink het volgende:
Er zijn altijd van die mannetjes die er zo : uitzien, die rare dingen gaan sturen.

[Nielsz]

Op donderdag 30 augustus 2001 12:56 schreef dusty het volgende:

[..]

[Anders]

Lekker serieus allemaal hier.

Wat ik persoonlijk het grootste nadeel vind aan sites die volgens een bepaald content management systeem te onderhouden zijn, al dan niet gekoppeld aan een database, is dat je zo vaak vast zit aan de beperkingen van zo'n systeem. Als er niet van tevoren rekening mee is gehouden, kom je dan in de problemen en moet je voor iets kleins heel diep het systeem induiken (en dat kost weer geld). Als je van tevoren met zoveel mogelijk dingen rekening wilt houden kost het ook weer geld, en bovendien is het dan weer lastig om het CMS overzichtelijk te houden voor de gebruiker.

1. Aanpassen van content hoeft niet per definitie door de webmaster te gebeuren. Tekst kan worden aangepast in vaste lay-out.
(...)
6. Alle informatie staat standaard in de juiste lay-out geen probleempjes meer met pagina's waar de tabel stiekum groter is dan op de andere.

Precies wat ik bedoel dus: wat als je nou wel een keer een net iets grotere tabel nodig hebt? Wat als je een keer wel van de vaste lay-out wilt of moet afwijken, bijvoorbeeld voor die ene tijdelijke actie?

Wat de login van een gebruiker met dit alles te maken heeft weet ik niet. Veel gebruikers hebben een gruwelijke pesthekel dat ze zich keer op keer voor van alles moeten registreren. Tegenover de grote voordelen zitten dus ook grote nadelen.

Veel van de punten die genoemd worden in de eerste post hebben niks met het database gestuurd zijn op zich te maken, maar alles met de manier waarop het CMS in elkaar zit. Ook zonder database kun je zorgen dat een aanpassing overal wordt doorgevoerd. Met een simpele preprocessor bijvoorbeeld.

[HenkS]

zoekmachines kunnen gewoon pagina's zoals index.php?id=10&blaat=aap ofzo niet goed aan, ik maar dan ook altijd een soort redirect scripts, dat als je bv index.html_10 invoert (die ik dus bij de zoekmachine aanmeld) dat je dan op bovenstaande pagina uitkomt.


en wat ik me afvraag, waarom moet je je collega's nog overtuigen???? bedoel, die solaris machine met sql+apache is toch ook al aangeschaft? waarom is die er dan?

[intert0y]

Op donderdag 30 augustus 2001 14:33 schreef HenkS het volgende:
zoekmachines kunnen gewoon pagina's zoals index.php?id=10&blaat=aap ofzo niet goed aan, ik maar dan ook altijd een soort redirect scripts, dat als je bv index.html_10 invoert (die ik dus bij de zoekmachine aanmeld) dat je dan op bovenstaande pagina uitkomt.


en wat ik me afvraag, waarom moet je je collega's nog overtuigen???? bedoel, die solaris machine met sql+apache is toch ook al aangeschaft? waarom is die er dan?

Helemaal gelijk maar het gaat er nu om ofdat de hele site DB-driven moet worden of alleen gedeeltes. BTW deze combinatie is vooral gekozen omdat er zeg maar ook interactie met klanten moet kunnen bestaan. Zij kunnen dan in de toekomst zelf adresgegevens wijzigen enzo. (deze klanten zijn dus al klanten zeg maar +- 180.000 stuks) Daarvoor is de solaris aangeschaft.

[Bezulba]

al moet je een voorbeeld van dbase driven database hebben kiek dan ff op www.my-mps.com (jaja ff reclame maken hoor alle paginas (behalve de echt belangrijke zoals jaarverslag) zijn dynamisch en kunnen door een gebruiker aangepast worden. erg handig voor pers stukjes en dat zoort dingen.

ook zit er een inlever stuk in voor deelnemers die ook op de database draait maar ik geloof niet dat dat voor jouw relevant is

[drm]

_{[extremely off-topic]}
ontwerp (die buttons vooral)

De mouseover bij "mps" is verkeerd-om
_{[/extremely off-topic]}