rilevante

Ciao a tutti.
Forse l'oggetto è un po fuorviante.

Ho un'applicazione (web) che utilizza un database, che mantengo su un mio
SQL Server.

Ogni distribuzione dell'applicazione dovrebbe utilizzare una diversa copia
dei dati,
isolata dalle altre.

In poche parole, un cliente deve utilizzare la sua copia dei dati, diversa
da quella di un altro cliente.
Ma ovviamente la struttura del database rimane la stessa, cambiano solo i
dati che lo popolano.

La domanda è la seguente:
al crescere del numero delle distribuzioni, è meglio creare una nuova copia
del database per ogni installazione (ovviamente via script e non a mano !)
oppure sarebbe meglio che tutte le applicazioni utilizzassero lo stesso
database, e che in ogni tabella del database ci sia un campo che identifica
a quale applicazione si vuole fare riferimento?

Spero di essere stato chiaro.

Grazie
Ciao
Roberto

Salve Roberto,
"Roberto Sartori" <robertosartori_ns> wrote in message
news:2420
[..]
> dati che lo popolano.
>
> La domanda è la seguente:
> al crescere del numero delle distribuzioni, è meglio creare una nuova
> copia del database per ogni installazione (ovviamente via script e non a
> mano !) oppure sarebbe meglio che tutte le applicazioni utilizzassero lo
> stesso database, e che in ogni tabella del database ci sia un campo che
> identifica a quale applicazione si vuole fare riferimento?
>
> Spero di essere stato chiaro.

Una domanda per capire meglio:
per ogni distribuzione crei anche una copia dell'applicazione web?
o stai pensando (nel caso di creare n copie di database per distribuzione)
di configurare una stringa di connessione ad-hoc per ciascun cliente?

> Grazie
> Ciao
> Roberto

Andrea

"Andrea Benedetti" <abenedetti> wrote in message
news:2988
> Salve Roberto,
> "Roberto Sartori" <robertosartori_ns> wrote in message
> news:2420
>
> Una domanda per capire meglio:
> per ogni distribuzione crei anche una copia dell'applicazione web?
> o stai pensando (nel caso di creare n copie di database per distribuzione)
> di configurare una stringa di connessione ad-hoc per ciascun cliente?

Per ogni distribuzione creo una copia dell'applicazione.
Quindi creo N applicazione identiche che si connettono tutte allo stesso
tipo di database, ovvero tutte a database con lo stesso schema.
Il mio dubbio era se creare N database uguali (con lo stesso schema) con
dati diversi, oppure se creare un unico database e filtrare le righe delle
tabelle in base all' I-esima applicazione.
Ovvero avrei una tabella del tipo

ID ApplicationName
1 Cliente1
2 Cliente2
.......

e poi nelle varie tabelle

AppId Campo1 Campo2
1 ... ...
1 ... ...
2 ... ...
2 ... ...

Mi interessava sapere soprattuto se ci sono controindicazioni da un punto di
vista delle prestazioni. Infatti se devo fare una query su una tabella
seguendo il primo metodo, la query lavora solo sulle righe di quella
applicazione. Invece usando il secondo metodo la query dovrebbe prima
filtrare le righe in base al valore del campo AppID, e poi eseguire la query
vera e propria (in sostanza si tratta solo di aggiungere una clausola WHERE,
ma volevo sapere quanto questo può influenzare sulle prestazioni,
specialmente se si prevedono grosse moli di righe)
Il vantaggio è che se devo aggiornare qualcosa, lo devo fare solo su un
database e non su N database.

Spero di aver chiarito

Grazie
Ciao
Roberto

"Roberto Sartori" <robertosartori_ns> ha scritto nel messaggio
news:a656
>
[CUT]
> Il vantaggio è che se devo aggiornare qualcosa, lo devo fare solo su un
> database e non su N database.
>

Lo svantaggio è che se devi fare un restore del database di una singola
applicazione perché l'utente ha fatto una ca++-+a lo devi fare manualmente.

>
> Grazie

Prego

> Roberto

David

Salve Roberto,
"Roberto Sartori" <robertosartori_ns> wrote in message
news:a656
[cut]
[..]
> seguendo il primo metodo, la query lavora solo sulle righe di quella
> applicazione. Invece usando il secondo metodo la query dovrebbe prima
> filtrare le righe in base al valore del campo AppID, e poi eseguire la
> query vera e propria (in sostanza si tratta solo di aggiungere una
> clausola WHERE, ma volevo sapere quanto questo può influenzare sulle
> prestazioni, specialmente se si prevedono grosse moli di righe)
> Il vantaggio è che se devo aggiornare qualcosa, lo devo fare solo su un
> database e non su N database.
>
> Spero di aver chiarito

Si, chiarissimo.
Per quanto riguarda le performance credo che potresti notare differenze nel
momento in cui le applicazioni (quindi i clienti) dovessero diventare tante.
Io opterei per un database unico con identificazione dei record dei clienti.
Valutando l'opportunità di creare degli indici sulla colonna che identifica
il proprietario del record (l'ID del cliente)

> Grazie
> Ciao
> Roberto
>
Ciao,
Andrea

salve,
Andrea Benedetti wrote:
>
> Per quanto riguarda le performance credo che potresti notare
> differenze nel momento in cui le applicazioni (quindi i clienti)
> dovessero diventare tante. Io opterei per un database unico con
> identificazione dei record dei clienti. Valutando l'opportunità di
> creare degli indici sulla colonna che identifica il proprietario del
> record (l'ID del cliente)

io invece, non a livello tecnico bensi' "legale (?)" considererei diversi
database.. brevemente, a livello tecnico questo potrebbe forse impattare le
performance per certi aspetti negativamente (ad esempio doppioni di piani di
esecuzione per le stesse esecuzioni su db diversi) e per certi versi
positivamente (contenimento del numero di righe presenti nelle tabelle in un
certo senso "partizionate" a livello di acquirente), mentre ad esempio la
manutenzione di ogni singolo acquirente potrebbe avere le proprie strategie
di salvataggo/ripristino, con procedure che non impattino altri acquirenti
stessi e, sicuramente dal punto di vista della privacy, minori problematiche
a livello di accesso...
saluti

"Andrea Montanari" <andrea.sqlDMO> wrote in message
news:riu1
> salve,
> Cut[..]

> e per certi versi
> positivamente (contenimento del numero di righe presenti nelle tabelle in
> un
> certo senso "partizionate" a livello di acquirente)

A questo proposito, volevo sapere quanto il numero di righe in una tabella
influisce sulle performance di esecuzione di una query, specialmente in
termini di velocità.
Ovviamente (credo) c'è una notevole differenza nel fare una query su 100
record e la stessa su 1000000 record ... ma fino a quanto questa differenza
è "trascurabile" ?

> Cut[..]
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> [..] [..]
> DbaMgr2k ver 0.11.1 - DbaMgr ver 0.57.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> --------- remove DMO to reply
>
Grazie
Ciao
Roberto

salve Roberto,
Roberto Sartori wrote:
>
> A questo proposito, volevo sapere quanto il numero di righe in una
> tabella influisce sulle performance di esecuzione di una query,
> specialmente in termini di velocità.
> Ovviamente (credo) c'è una notevole differenza nel fare una query su
> 100 record e la stessa su 1000000 record ... ma fino a quanto questa
> differenza è "trascurabile" ?
>

e' difficile dare un'indicazione in tal senso tanto piu' che chiaramente
dipende dall'hardware sottostante, come anche dalla base dati stessa a
livello di potenziale frammentazione, indicizzazione, consistenza delle
righe relativamente al numero di pagine utilizzate per l'archiviazione delle
tabelle, oltre che chiaramente dalla "bonta'" del codice utilizzato per le
operazioni CRUD... e chiaramente non sono confrontabili operazioni tra 100
righe e 1 milione d righe :)
per tanti aspetti queste problematiche vanno isolate e gestite in base al
proprio scenario...
saluti

[cut]
> io invece, non a livello tecnico bensi' "legale (?)" considererei diversi
> database..
[cut]

Di contro, con una soluzione del genere, deve essere cura dello sviluppatore
/ dba (ricordarsi di) replicare a cascata, su ogni singolo database, ogni
possibile correzione/aggiunta/modifica di procedure, funzioni, trigger e
quant'altro ...

Saluti,
Andrea

salve Andrea,
Andrea Benedetti wrote:
>
> Di contro, con una soluzione del genere, deve essere cura dello
> sviluppatore / dba (ricordarsi di) replicare a cascata, su ogni
> singolo database, ogni possibile correzione/aggiunta/modifica di
> procedure, funzioni, trigger e quant'altro ...

giusto... non dimentichiamo cioe' che tutte le operazione di manutenzione,
siano esse ordinarie o straordinarie, vanno replicate per ogni database...
saluti