Database Multipli

[dreadnaut]

Il motivo per cui ho suggerito SQLite è la completa separazione dei dati, ma anche delle prestazioni: come dice @alemoppo se c'è un collo di bottiglia nella scrittura, è separato per ogni database.

Il collo di bottiglia è comunque decine di scritture al secondo, che mi sembrava un volume più che sufficiente per un negozio, dove la maggior parte dei visitatori guardano (assumiamo una scrittura per pagina visita), ed ogni tanto qualcuno compra (10 scritture nell'arco di 2-3 pagine di "checkout", quindi minuti)

Come scrivevo sopra, la scelta è fra imparare a gestire e scrivere un sistema multi-utente, o imparare un diverso dialetto SQL. Nella mia esperienza ho trovato la seconda cosa più facile, ma dipende da quello che serve o interessa a @rigidbodyinteractive.

In entrambi i casi penso sia importante inserire un livello fra le pagine e l'accesso al database. Spargere query SQL ovunque renderà il lavoro più complesso e fragile.


P.S. non piazzatemi su una colonna troppo alta, eh, che c'è vento e si cade spesso

E per rispondere ad 1/2/3 sopra: immagino i clienti vogliano tutto separato, quindi tutto sarebbe diviso a livello di https://sito.altervista.org/<cliente>/pagine. Se accedi ad una pagina sotto /<cliente>/, tutte le chiamate vanno a <cliente>.sqlite.

[frasidipace]

Ciao,
ok, ma se sulla piattaforma ho 100 vendor e come utente che fa acquisti cerco un prodotto che è venduto da soli 10 vendor, dovrò fare 90 accessi a DB inutilmente.
A cosa serve, quindi, tenere i DB separati?

Ciao

[alemoppo]

Non credo che la scelta sia fare ricerche "su più vendor", o meglio non credo sia quel che voglia fare rigidbodyinteractive. Se fosse così, riconfermo la soluzione con un unico db e un'unica tabella "clienti", una "prodotti" etc.

Da quel che ho capito, rigidbodyinteractive vorrebbe proprio tenere separati i vari "portali". Quindi se un utente entra nel "portale" di venditore1, verrà usato solo il database venditore1.sqlite

Ciao!