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!

[rigidbodyinteractive]

accesa discussione vedo :) mi fa piacere, grazie per l'interessamento.

giusto per chiarire: il sito non e' un vero e proprio multivendor (non nel senso canonico almeno) e' piu' un vero e proprio sistema di gestione aziendale.

ci si registra con un account "owner" (gestito da me su un file .config) su un MySQL DB, questo crea una cartella col nome del owner a un SQLite DB specifico(contenente tabelle come clienti, citta' fatture, prodotti ecc). se un utente si vuole registrare come user normale deve specficare un email di un owner gia' esistente, ed ereditera' il suo db. una volta loggato ogni utente puo' fare le fatture, cioe' aggingere prodotti, clienti, sconti ecc. ed inviare la fattura al cliente finale. non si compra niente, non ci sono vetrine o carrello dove aggigere i prodotti e gli utenti(miei potenziali clienti) non saranno poi cosi' tanti. almeno credo, poi se le cose diventan serie ed avessi milioni di clienti magari si potrebbe contemplare qualcosa di piu' professionale con SQL e database multipli(sql).

se volete provarlo(giusto per curiosita' potete trovarlo qui https://rigidbodydata.altervista.org/

potete creare un account usando queste credentials

        'info@owner1.com' => [
            'owner_pass' => '111',
            'user_pass' => 'aaa'
        ],
        'info@owner2.com' => [
            'owner_pass' => '222',
            'user_pass' => 'bbb'
        ],
        'info@owner3.com' => [
            'owner_pass' => '333',
            'user_pass' => 'ccc'
        ],
        'info@owner4.com' => [
            'owner_pass' => '444',
            'user_pass' => 'ddd'
        ],
        'info@owner5.com' => [
            'owner_pass' => '555',
            'user_pass' => 'eee'
        ],
        'info@owner6.com' => [
            'owner_pass' => '666',
            'user_pass' => 'fff'
        ],
        'ciao@ciao.com' => [
            'owner_pass' => 'ciao',
            'user_pass' => 'ciao'
        ], 

cosi' vedete di cosa sto parlando. in questo scenario non credo che le request multiple siano molte e si sovrappongono. ma potrei sbagliarmi