Dat kan, om voorlopig te beginnen, prima op een vps. Bij eigen server moet je nog veel meer regelen om uptimes etc te garanderen.

Ik zou inderdaad beginnen met een simpel hosting pakket

Citaat van MBCompany

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:

Citaat van Wikipedia

Een virtuele machine die als dienst verkocht wordt door een hostingprovider. Virtualisatie maakt het mogelijk om op een fysieke server een (groot) aantal virtuele servers te gebruiken waardoor de fysieke server een veel groter deel van de tijd gebruikt wordt. Daarnaast levert het gebruik van virtuele servers inherent beveiliging; een gecompromitteerd VPS heeft geen consequenties voor andere VPS'en op dezelfde (fysieke) machine, zoals dat bij shared webhosting normaliter wel het geval is. Wel delen ze vaak binnen Linux de kernels en de quota-systemen. Dit ligt aan de instellingen en het soort virtualisatie.

Virtualisatie kan ook gebruikt worden om verschillende en niet-uitwisselbare besturingssystemen op dezelfde computer te draaien.

Bij VPS-technologie draait het vooral om het opsplitsen van een fysieke server in meerdere kleinere (virtuele) servers. Iedere VPS krijgt een eigen deel resources toegewezen, welke in principe gegarandeerd beschikbaar zijn voor de VPS. Als voorbeeld kan de fysieke server 8GB RAM hebben, waarvan 256MB gegarandeerd voor elke VPS beschikbaar is.

Elke VPS heeft zijn eigen RAM, eigen schijfruimte, eigen processen, eigen OS, eigen serverload, en zelfs een eigen filesystem. Met andere woorden: elke VPS is geheel onafhankelijk, en dus "Private".

Verschillende VPS-servers staan op één fysieke server maar werken volledig onafhankelijk van elkaar. Als één VPS op de server een hoge load heeft, dan heeft alleen die VPS zelf daar last van en andere VPS'en niet. Echter, in extreme gevallen, zoals bij een grote DDoS-aanval, kan het voorkomen dat het host-systeem zo erg overbeladen raakt, dat de andere VPS'en op dezelfde server daar ook last van hebben. Maar onder normale omstandigheden zijn VPS'en onafhankelijk.

Toon Meer

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.

Citaat van MBCompany

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.

Citaat van Webmediaede

Ik zou inderdaad beginnen met een simpel hosting pakket

Huh? Hosting op een hostingpakket draaien?

Citaat van AarClay

In die gevallen zou ik één database gebruiken, en die gebruiken.

Ik hoop dat je één database per website bedoelt. Eén codebase met meerdere databases op basis van hostname is helemaal niet zo vreemd.

Citaat van FangorN

Ik hoop dat je één database per website bedoelt. Eén codebase met meerdere databases op basis van hostname is helemaal niet zo vreemd.

Maar veel te lastig te onderhouden op den duur. Waarom zou je alles niet centraal opslaan in één database? Ik heb het over één source die op meerdere hostnames draait, hé.

Citaat van AarClay

Maar veel te lastig te onderhouden op den duur.

Toch alleen als er regelmatig iets verandert in de databasestructuur?

Citaat van AarClay

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.

Citaat van AarClay

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.

Ik gebruik Laravel Forge om verschillende soorten web apps te draaien (WP, Vanilla PHP, Laravel en Vue.JS). Geweldige service, het geld dubbel en dwars waard.