n° 219
Novembre 2017
Dicembre 13, 2017, 07:17:54 *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
Notizia:
 
   Indice   Linux Windows Techassistance Gameassistance videogame hardware Aiuto Ricerca Agenda Downloads Accedi Registrati  


* Messaggi recenti
Messaggi recenti
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: Curiosità su grandi Database  (Letto 4556 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
morriluca
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 5


Mostra profilo E-mail
« inserita:: Giugno 07, 2016, 11:11:32 »

Ciao a tutti.
Ho sempre usato MySql per piccoli e medi progetti e mi è sorta una curiosità
su come sia possibile strutturare un progetto complesso (forse nei prossimi mesi dovrei cominciare a realizzarne uno)

Pensate per esempio al sito erpnext.com, fatture24, ecc.. ecc.
dove ogni utente accede ed ha la propria gestione privata.
Secondo voi, quando si hanno strutture dati di quel genere, i dati relativi ad ogni utente come sono strutturati, o come dovrebbero essere strutturati?

1) Un db per ogni utente che accede?
2) tabelle che hanno un nome primario identificato in base all'utente?
3) tabelle uniche di gestione dove ogni record inserito ha l'id dell'utente di appartenenza?
4) Che?!?

Riuscite a darmi qualche delucidazione?
Grazie.
Registrato
paooolino
Full Member
***

Karma: +16/-10
Scollegato Scollegato

Messaggi: 380

Ideas in programming


Mostra profilo WWW
« Risposta #1 inserita:: Giugno 07, 2016, 04:18:48 »

Citazione
1) Un db per ogni utente che accede?
No!

Citazione
2) tabelle che hanno un nome primario identificato in base all'utente?
Noo!

Citazione
3) tabelle uniche di gestione dove ogni record inserito ha l'id dell'utente di appartenenza?
Sì!

MySQL gestisce benissimo questo tipo di struttura e non mi sognerei di pensare a qualcosa di diverso.

Avrai una tabella "utenti" che memorizza le credenziali (con password criptate) e altre informazioni che ti servono.

Tutte le tabelle esterne che devono essere associate agli utenti avranno un campo id_utente che si riferisce all'id della tabella utenti.

Registrato

morriluca
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 5


Mostra profilo E-mail
« Risposta #2 inserita:: Giugno 08, 2016, 11:21:02 »

Grazie mille per l'informazione.

Un'ulteriore domanda.
Nella caso di avere tanti utenti nel sistema, nella soluzione con tabelle uniche,
quali tecniche si possono usare per l'ottimizzazione delle query in lettura/scrittura?

Con l'ipotesi delle tabelle distinte io mi sarei immaginato di mettere le tabelle in DB differenti, magari anche su server differenti, in modo da suddividere il carico di lavoro.
Registrato
paooolino
Full Member
***

Karma: +16/-10
Scollegato Scollegato

Messaggi: 380

Ideas in programming


Mostra profilo WWW
« Risposta #3 inserita:: Giugno 08, 2016, 12:04:31 »

Per la scrittura non vedo alcun problema.

In entrambe le situazioni devi scrivere un solo record, solo che con le tabelle uniche avrai un campo in più. Non credo che questo possa influire negativamente sulle prestazioni.

In lettura devi solo filtrare per id_utente, anche qui non vedo particolari controindicazioni aggiungendo un WHERE id_utente = x.

Tabelle di questo tipo anche con decine di migliaia o centinaia di migliaia di record vengono gestite egregiamente da un server appena decente.

Sulle soluzioni per distribuire MySQL su più server non saprei dirti, ma so che ci sono possibilità di mantenere sincronizzati i database a livello di sistema operativo. Certo il massimo della scalabilità sarebbe utilizzare DB di tipo diverso progettati a monte per essere distribuiti, ma a meno che non devi costruire un database con una quantità di dati inimmaginabile (tipo FB o Google) credo che un MySQL vada bene nel 99,9% dei casi, anche per progetti piuttosto grandi.
Registrato

morriluca
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 5


Mostra profilo E-mail
« Risposta #4 inserita:: Giugno 08, 2016, 12:15:22 »

Prefetto, Grazie mille per l'informazione.

Mettere un campo in più in tabella "id_utente" e poi gestirlo è piuttosto semplice.

L'idea però di avere tabelle distinte per utente non mi sembrava una cattiva idea, in quando avevi
una suddivisione maggiore dei dati (che però in questo caso è una cosa negativa), e avevi la completa sicurezza che ogni utente operasse solo e solamente sui suoi dati.
Solo che quando cominci ad avere una mole di utenti sui (5000/6000), nel caso che le tabelle di gestione di ogni utente siano 30, 180.000 tabelle fa abbastanza PAURA Scioccato
Registrato
fermat85
Full Member
***

Karma: +6/-2
Scollegato Scollegato

Messaggi: 596


Mostra profilo WWW
« Risposta #5 inserita:: Giugno 08, 2016, 12:37:59 »

mi aggiungo ai consigli che ti hanno già dato.

non usare tabelle distinte.
diventerà un dramma gestirle.
e te lo dico per esperienza, per progetti non miei che ho sistemato, sviluppati con questa logica.
struttura bene le tabelle con indici e foreign key per evitare ridondanza dei dati inutili.
e vai tranquillo.
Registrato

morriluca
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 5


Mostra profilo E-mail
« Risposta #6 inserita:: Giugno 08, 2016, 03:06:21 »

Perfetto, seguirò il vostro consiglio.

Grazie tante per l'informazione
Registrato
+m+
Newbie
*

Karma: +1/-5
Scollegato Scollegato

Messaggi: 29


Mostra profilo
« Risposta #7 inserita:: Giugno 08, 2016, 03:55:24 »

Chissà perchè questo thread mi dice qualcosa  Ghigno

Citazione
e avevi la completa sicurezza che ogni utente operasse solo e solamente sui suoi dati.
Si chiamano "viste"

Riguardo all'uso di più server per mysql ci sono le configurazione multimaster, con mariadb (in realtà si può montare il plugin anche su mysql) c'è l'engine spider.

Ma sono adatti per lavori moooolto ma mooooolto più grandi

Database grande ha vari significati essenzialmente
1) gli indici sono più grandi della RAM disponibile
2) [per estensione, in realtà non sono grandi ma lenti] il livello di concorrenza è molto alto con locking su poche righe in scrittura
3) non c'è sufficiente selettività per rendere utili gli indici \ il carico di aggiornamento in scrittura è proibitivo
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #8 inserita:: Giugno 10, 2016, 03:01:56 »

Non sono state sufficienti le risposte già ricevute su https://www.iprogrammatori.it/forum-programmazione/progettazione-database/consiglio-per-databse-grande-dimensione-t28189.html#p8558472 ?

Thread chiuso per cross posting.
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
Pagine: [1]   Vai su
  Stampa  
 
Vai a:  

Copyright © 2017 Edizioni Master SpA. p.iva : 02105820787

Tutti i diritti di proprietà letteraria e artistica riservati. - Privacy



powered by Simple Machines