"ontwerp" keuze, status website
Ik ben bezig met het inrichten van mijn VPS.
Stel dat ik over een tijdje meerdere websites heb, dan wil ik die kunnen "bedienen" via mijn CMS. Met bedienen bedoel ik dat ik bijvoorbeeld wil kunnen aangeven dat website A actief is, dat website B inactief is en dat website C "under contruction" is. Eigenlijk dus de "status" van de website.
Nu vraag ik me af wat jullie zouden doen. Ik zit te twijfelen tussen 2 opties:
1) Ik sla de status op in de database.
Het voordeel is nu dat de status van iedere website netjes in de database staat. De database bepaalt dus wat de status van een website is. Het nadeel is dat tenminste 1x per sessie de status moet worden opgehaald uit de database. Indien de database niet werkt, zal er op het scherm een foutmelding worden getoond "Onze excuses er is een fout opgetreden. Probeer het later nogmaals." Aangezien de status van de website niet kan worden bepaald, houdt het script hier op.
2) Ik sla de status op in zowel de database als in een configuratiebestand.
Het voordeel is dat de status nu is opgeslagen in een configuratiebestand. De database hoeft niet meer geraadpleegd te worden. Als de database niet werkt, zal toch de lay-out van de website kunnen worden getoond. De foutmelding "Onze excuses er is een fout opgetreden. Probeer het later nogmaals." zal in de lay-out van de website getoond kunnen worden. Het nadeel is echer dat niet de database, maar het configuratiebestand nu leidend is. Stel dat iemand in het configuratiebestand de status wijzigt van "actief" naar "inactief" dan lijkt het in het CMS (de database) alsof de site actief staat, terwijl dat in werkelijkheid niet zo is.
Wat is volgens jullie de beste optie? Optie 1 waarbij de database leidend is? Of optie 2 waarbij het configuratiebestand leidend is?
Ozzie mag ik vragen waarom de database eventuu weel niet zou werken? Ik neem aan dat die gewoon aan blijft 24/7 brhalve.als je website crasht maar dan zou als het goed is een heleboel dingen niet werken. Ik zou gewoon voor de cms / databasr variant gaan.
Dat is dus ook een beetje mijn vraag... of ik het via de database moet doen, of via database en configuratiebestand. Een configuratiebestand werkt altijd, maar brengt weer wat andere nadelen mee inderdaad.
Als een database niet werkt gaat als het goed is je hele site naar de klote. Daarvoor hebben ze iets uitgevonden: een backup. Dus die redenering vind ik ronduit dom
Euh.. wat bedoel je nu Moose? Je database kan ook tijdelijk down gaan. Wat heeft een backup hiermee te maken?
In dat geval hoef je niet naar databases te kijken, maar zou je de Vhost gewoon kunnen herschrijveb vanuit een eigen CMS. Je wilt dus een simpel webhostingcontrolpanel maken om site uit de lucht te halen?
Toen was dus mijn vraag. Zet ik deze status in de database en laat ik die 1x per sessie ophalen? Of... zet ik de status in de database, maar sla ik deze tevens op in een configuratiebestand, en haal ik de status telkens op uit het configuratiebestand in plaats van uit de database? (in dit laatste geval hoef ik de database niet te raadplegen, en hoef ik ook niet per se een sessie aan te maken om de status in op te slaan).
Quote:
Als jij aan het eind van het jaar je rekening niet betaalt, zet ik 'm op inactief. Dat is een beetje het idee.
Is het dan niet handiger om de virtual host gewoon te disablen?
Dus dan kan je net zo goed hem laten verwijzen naar een andere map en of misschien wel een eenvoudige .htaccess?
Als de site gereed is voor gebruik kan je toch hem gewoon naar het pad laten verwijzen van de site/user zelf?
Zou daar niet te veel moeite in gaan steken om dit te bewerk stellen.
Gewijzigd op 26/01/2013 19:50:54 door Bart V B
Nee, lijkt me juist helemaal niet handig om virtual hosts te gaan disablen. Die manier die ik voor ogen heb is prima, maar de vraag is dus... met alleen een database, of... met een database en configuratiebestand.
Ik zou dit regelen met een licentiecode en een config bestandje, ik zou geen gebruik maken hierbij van een database, kost alleen maar resources, en tijd :)
Pffff... waarom zegt iedereen iets anders ;)
Hoe wil je het zelf?
Ik twijfel tussen de database oplossing, of de oplossing waarbij de database en een configuratiebestand wordt gebruikt. Zie mijn 1e post.
vooral bij het developen zijn er erg veel mening goed. Wat je als developer moet doen is je eigen mening vormen, wat vind jij de beste methode? Ik merk vaak dat jij opzoek bent naar dat ene ding dat echt goed is, maar dat bestaat helemaal niet. Wat goed is is het geen wat jij denkt dat het beste is. Denk jij na het lezen van andere meningen dat jou manier de beste is? Nou, dan ga je die manier gebruiken. Denk je, hmmm ik hou eigenlijk meer van Local Dev's manier, dan gebruik je die. Idem voor al die andere forumleden.
hoe zou je het toepassen/controleren?
@Local: Dat staat ook in de beginpost. Het gaat mij vooral om wat het slimste is qua resources. Als ik een config bestand gebruik dan hoef ik de database niet aan te spreken en hoef ik niet per se een sessie te starten. Da's een voordeel. Een nadeel is dat niet de database maar het config bestand dan leading is.
Er zijn tig manieren om hetgeen wat jij hier beschrijft uit te voeren, waarbij alle ideeën op hetzelfde uitkomen, en waarbij een persoonlijke voorkeur de overhand heeft.
Ozzie PHP op 26/01/2013 18:11:45:
2) Ik sla de status op in zowel de database als in een configuratiebestand.
Regel 1:
Zorg dat data altijd consistent is en nooit dubbel wordt opgeslagen. Ga je namelijk data dubbel opslaan dan moet je het op twee plekken correct bijhouden en verveelvoudig je de kans op fouten en inconsistente data. Wat doe je dan als het op de ene plek niet meer hetzelfde is als op de andere?
Optie 2 valt dus af, blijft over....
Gewijzigd op 27/01/2013 00:07:31 door Erwin H
(Houdt dus wel in dat ik ALTIJD verplicht ben om een sessie aan te maken. Dat vind ik dan wel weer minder...)
Database
- Hier sla je de status op van de website. De status wordt hierin bijgewerkt.
Status cache
- Wanneer de status in de database op "actief" is gezet, wordt er een cache van de status aangemaakt. Hierdoor hoeft er niet voor elke sessie in de database gekeken te worden naar de status van de website. Vervolgens wordt er elke X periode(automatisch) gekeken of deze status nog actueel is.
Dan heb je de status van een website wel primair in een database, maar heb je niet voor elke sessie een verbinding naar de database. Door het toevoegen van een optie om de cache ook handmatig te vernieuwen, zorg je dat je even snel de status kunt aanpassen als wanneer je alleen een database zou gebruiken. Volgens mij het je dat de voordelen van je beide punten wel te pakken, terwijl je de nadelen (grotendeels) weg haalt.
Ben al best wel lang wakker (ongeveer 18 uur nu), dus kan zijn dat stukken wat vaag omschreven zijn. Excuus daarvoor...
Ik zat zelf nog te denken... ik zou ook de status niet in de databse kunnen opslaan, maar het zo maken dat je de status wel via het cms kunt regelen, maar dat ie 'm niet opslaat in de database, maar in een config bestand. Als je de status wil wijzigen kan dit ook via het cms, maar dan lees je eerst het config bestand in (om te zien wat de actuele status is) en vervolgens pas je de status aan en dit wordt dan in het config bestand opgeslagen. Of zou dat te omslachtig zijn?