Ik heb een vraag meer op database gebied. Hoe kan ik het best aanpakken als jij bijv een webshop aan kan maken op een site. Ieder tabel een webshop_id meegeven of hoe dit aan te pakken. Want dan krijg je een enorme database.
Of allemaal verschillende servers met ieder max 10 webshops?
Hoop dat beetje duidelijk heb uitgelegd (Heb webshop gekozen omdat dat veel data nodig heeft)
Als het een bestaand type webshop gaat, dan lijkt me het beste om te kijken of er een plug-in bestaat om alles genormaliseerd op te slaan in 1 database met gedeelte tabellen, maar dit is voor menig grote applicatie behoorlijk ingrijpend dat ik dat betwijfel...
Anders loont het om voor elke webshop een eigen database aan te maken. Performance-technisch gezien moet je zelf even meten hoeveel webshops er op jouw server kunnen, maar dan ben je in ieder geval al voorzien van een schaalbare implementatie om databases te kunnen verhuizen naar andere servers als het nodig is.
Je kan er ook voor kiezen om een enkele zware server alleen dienst te laten als database-server.
Als het om een nieuwbouw webshop gaat, dan raad ik alles aan om het op te slaan in een enkele database. Of je deze op een externe server laat draaien, of je huidige waar je de webshop op host, dat moet je zelf even performen. Webshop zijn vaak zware scripts met veel berekeningen en veel data.
Elke webshop een eigen database geven en elke database een eigen account. Als zij in de code kunnen dan zien ze het db wachtwoord als je meerdere shops in een database pleurt dan is dat totaal niet veilig
Elke webshop een eigen database geven en elke database een eigen account.
Als zij in de code kunnen dan zien ze het db wachtwoord als je meerdere shops in een database pleurt dan is dat totaal niet veilig Mensen moet je niet bij de source laten kunnen; mensen die de source snappen zetten zelf wel een webshop op, en mensen die het niet snappen moet je niet aan de source laten.
Gewoon alles in één database stoppen dus, eventueel verspreid over meerdere servers.
Wel keigoed optimaliseren en backuppen, want je gaat gigantische tabellen en een hoge databasebelasting krijgen als je concept goed loopt.
Elke webshop een eigen database geven en elke database een eigen account.
Als zij in de code kunnen dan zien ze het db wachtwoord als je meerdere shops in een database pleurt dan is dat totaal niet veilig Mensen moet je niet bij de source laten kunnen; mensen die de source snappen zetten zelf wel een webshop op, en mensen die het niet snappen moet je niet aan de source laten.
Gewoon alles in één database stoppen dus, eventueel verspreid over meerdere servers.
Wel keigoed optimaliseren en backuppen, want je gaat gigantische tabellen en een hoge databasebelasting krijgen als je concept goed loopt.
Dit is het meer, mensen komen niet bij de code. Zit wel met leuk idee in mijn hoofd maar dit is toch wel een belangrijk element, ik kies en dan voor een webshop een server toe te wijzen zodat en max 10 op een database staan bijv.
Elke webshop een eigen database geven en elke database een eigen account.
Als zij in de code kunnen dan zien ze het db wachtwoord als je meerdere shops in een database pleurt dan is dat totaal niet veilig Mensen moet je niet bij de source laten kunnen; mensen die de source snappen zetten zelf wel een webshop op, en mensen die het niet snappen moet je niet aan de source laten.
Gewoon alles in één database stoppen dus, eventueel verspreid over meerdere servers.
Wel keigoed optimaliseren en backuppen, want je gaat gigantische tabellen en een hoge databasebelasting krijgen als je concept goed loopt.
Maar als iemand een andere template wil? En die maakt hij zelf, en die template is php. Dus kan je ook querys uitvoeren. En dus ook data opvragen van andere gebruikers.
Elke webshop een eigen database geven en elke database een eigen account.
Als zij in de code kunnen dan zien ze het db wachtwoord als je meerdere shops in een database pleurt dan is dat totaal niet veilig Mensen moet je niet bij de source laten kunnen; mensen die de source snappen zetten zelf wel een webshop op, en mensen die het niet snappen moet je niet aan de source laten.
Gewoon alles in één database stoppen dus, eventueel verspreid over meerdere servers.
Wel keigoed optimaliseren en backuppen, want je gaat gigantische tabellen en een hoge databasebelasting krijgen als je concept goed loopt.
Maar als iemand een andere template wil? En die maakt hij zelf, en die template is php. Dus kan je ook querys uitvoeren. En dus ook data opvragen van andere gebruikers.
Dit is natuurlijk ook een punt van aandacht heb hier wel aangedacht maar niet naar de oplossing. Alleen dat door een van de aangewezen mensen layout kunnen installeren ?
Bij Biedmeer kan je wel een eigen template aanbieden voor je door hun gehostte webshop. Deze wordt dan tegenbetaling omgezet naar Smarty, zodat het op hun platform draait.
met Smarty (of menig ander TPL-parser) hoef je geen PHp meer uit te voeren.
Elke webshop een eigen database geven en elke database een eigen account.
Als zij in de code kunnen dan zien ze het db wachtwoord als je meerdere shops in een database pleurt dan is dat totaal niet veilig Mensen moet je niet bij de source laten kunnen; mensen die de source snappen zetten zelf wel een webshop op, en mensen die het niet snappen moet je niet aan de source laten.
Gewoon alles in één database stoppen dus, eventueel verspreid over meerdere servers.
Wel keigoed optimaliseren en backuppen, want je gaat gigantische tabellen en een hoge databasebelasting krijgen als je concept goed loopt.
Maar als iemand een andere template wil? En die maakt hij zelf, en die template is php. Dus kan je ook querys uitvoeren. En dus ook data opvragen van andere gebruikers.
Dat moet je sowieso niet toestaan. OF je laat ze zelf templates uploaden maar zorgt dat er geen kwade code in kan staan (dus ze kunnen enkel pure HTML uploaden), OF je laat ze kiezen uit een setje bestaande templates. Natuurlijk kun je ze wel de CSS laten customizen enzo.
