VPS of Server?

  • Hi,


    Ik ben momenteel bezig met een standaard website kan maken. En vraag me af wat ik het beste kan nemen een vps of een Server.


    Ik ga als volgt te werk:


    Bezoeker beland op mijn website waar hij een Account kan maken en inloggen.


    Als de bezoeker een account heeft gemaakt wil ik dat hij een eigen host krijgt en dat een standaard website design op zijn hosting krijgt (Dat het van een locatie op de server of VPS word gekopierd en geplakt op zijn hosting) En een Database moet aangemaakt worden met de bijhorende tabellen en columen etc. Volledig automatisch. (Indien hier tips over zijn hoor ik het graag:).)


    Sorry ben moeilijk met het verwoorden:) hoop dat jullie me begrijpen


    Zou dit ook kunnen met een VPS?

    Ik sta open voor projecten.
    Ik sta ook tehuur als scripter
    PM voor meer informatie

  • Guest, wil je besparen op je domeinnamen? (ad)
  • Hi,


    Ik ben momenteel bezig met een standaard website kan maken. En vraag me af wat ik het beste kan nemen een vps of een Server.

    Zullen we maar even beginnen om de termen uit te leggen? Een VPS is een server. Een Virtual Private Server. En een iets wat ingekorte definitie vanaf Wikipedia:




    Een dedicated server is een echte fysieke server, deze is vaak op maat gemaakt dat deze in een serverrack (19 inch) past, en bomvol hardware voor een goede en snelle performance in het algemeen. Een master-server die VPS'sen draait is eigen dus ook een dedicated server, maar onderscheidt zich met een shitload geheugen en opslag.




    Als de bezoeker een account heeft gemaakt wil ik dat hij een eigen host krijgt en dat een standaard website design op zijn hosting krijgt (Dat het van een locatie op de server of VPS word gekopierd en geplakt op zijn hosting) En een Database moet aangemaakt worden met de bijhorende tabellen en columen etc. Volledig automatisch. (Indien hier tips over zijn hoor ik het graag:).)

    Met welke reden moet er een database met tabellen worden aangemaakt? Welke tabellen? Welke inhoud? Welke kolommen? Je gebruiker wilt er toch zelf vrijheid in hebben? Of lever je een soort SAAS-systeem, waarbij je een online softwarepakket voor je klanten opzet? Of een website-editor waarin die zijn site in elkaar kan klikken? In die gevallen zou ik één database gebruiken, en die gebruiken. Alles op de domeinen komt uit op één en zelfde script die je via een enkel deurtje benaderd. Aan de hand van de hostname ($_SERVER['HTTP_HOST']) kan je de domein bepalen, waarna je nodige data eruit kan toveren.


    Als je dit nu steeds per domein apart uitrolt, dan heb je een hoop werk met updaten, en moet je al je domeinen af om de boel te updaten. Daarom liever één basis.

  • Maar veel te lastig te onderhouden op den duur.

    Toch alleen als er regelmatig iets verandert in de databasestructuur?


    Waarom zou je alles niet centraal opslaan in één database?

    Dit is niet per definitie een probleem, totdat je een keer een lokale kopie nodig hebt van een specifiek hostname - dan zul je *alle* data binnen moeten harken terwijl je mogelijk maar een fractie nodig hebt? Het maakt een database een stuk minder mobiel / transporteerbaar.


    Als je trouwens één database hebt voor meerdere hosts zou dit dus ook inhouden dat er een extra criterium in deze data moet zitten om de verschillende domeinen te kunnen onderscheiden? Dit is extra complexiteit die waarschijnlijk geen positieve invloed heeft op de performance. Tenzij de data voor elke site hetzelfde is, which begs the question, waarom zijn daar dan meerdere sites voor nodig?


    Het hangt natuurlijk van de applicatie af of de opzet met een enkele database geschikt is, dit is niet een vraag met één universeel antwoord, maar een enkele database voor meerdere sites wordt al snel een baksteen, vooral als de sites veel (verschillende) content hebben. Je moet dan continu alles overal naar toe zeulen.


    Op eenzelfde manier wil je waarschijnlijk ook bijbehorende media (documenten, filmpjes en afbeeldingen et cetera) gescheiden houden, zodat je al deze informatie per hostname vrij kunt selecteren en verplaatsen.


    Ik heb het over één source die op meerdere hostnames draait, hé.

    Ja, we hebben het allebei nog steeds over hetzelfde. Ik heb toevallig in het verleden gewerkt met zo'n constructie, maar dan wel met meerdere databases. Het betrof elektronische leeromgevingen. Elke hostname had toch wel een aparte insteek, met aparte cursussen en content, terwijl de codebase hetzelfde bleef. Dit was als ik het mij goed herinner niet het geval voor de media - en dat was best wel een ramp...


    Heb jij een voorbeeld van een product (codebase) waarbij het volgens jou geoorloofd is om deze in een enkele database te stoppen terwijl de verschillende sites (niet triviale en) verschillende content hebben? Ik kan geen voorbeeld bedenken. En dan dus echt een database die de hostnames hun uiterlijk en inhoud geeft uiteraard, niet een gezamenlijke database die door meerdere sites als informatiebron (denk aan statistieken of meetgegevens) wordt gebruikt, ik snap dat je daarvoor één database wilt, zodat je één bron blijft houden. Maar toch niet als de content per site verschilt?


    En je zou dus ook best beide kunnen hebben, zolang je maar in het oog houdt wat zinnig is om te delen, en wat beter is om gescheiden te houden.

  • Typisch een vraagstuk waar de meningen over verdeeld zijn. Net als 'de kip of het ei' discussie.


    Als het losse sites zijn, dan zou het prima kunnen. Maar als het geheel bij één site hoort qua content is één database juist prima.


    Het is een kwestie van afwegen of het het nodig is, of niet.
    Als je een hosting-omgeving aanbiedt (Saas) dan is een gescheiden database sowieso wel prima. Ieder zijn mening hierover.....


    Op het moment dat het niet meer te trekken is, dan kan je altijd de overstap doen. Kost wat moeite, maar het is te doen.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!