Database e tabelle

venerdì 23 febbraio 2007 - 18.04

fabiogvn Profilo | Newbie


Tenendo conto che non ci sono particolari motivi per privilegiare una scelta o l'altra, in linea di massima è megliio avere molti database contenenti poche tabelle o un solo database con molte tabelle al suo interno?

Faccio un esempio per chiarire quello che intendo: i vari database non hanno nessun tipo di relazione in comune, ma hanno la stessa identica struttura dati. Diciamo che ogni database rappresenta un'azienda e che ogni database ha tre tabelle:

- anagrafica dipendenti (con una media di 100 record totali)
- archivio messaggi mail di ogni dipendente (con una media di 100 record aggiunti al giorno ed un archivio storico di un anno, quindi 365000 record in un anno)
- attività giornaliere di ogni dipendente (con la stessa media di numero di record della tabella dei messaggi, quindi 365000)

Lo scenario prevede ipoteticamente un centinaio di aziende-database senza nessuna correlazione tra loro
Ecco le due soluzioni, con indicato tra parentesi il numero ipotizzato di tabelle per database e di record per ogni tabella

Esempio 1: un database per ogni azienda (100 database)

Database_1 (3 tabelle)
Anagrafica (100 record)
Messaggi (365000 record)
Attività (365000 record)
Database_2 (3 tabelle)
Anagrafica (100 record)
Messaggi (365000 record)
Attività (365000 record)
Ecc.


Esempio 2: un database unico con tre tabelle per ogni azienda:

Database_X (300 tabelle)
Azienda1.Anagrafica (100 record)
Azienda1.Messaggi (365000 record)
Azienda1.Attività (365000 record)
Azienda2.Anagrafica (100 record)
Azienda2.Messaggi (365000 record)
Azienda2.Attività (365000 record)
Ecc.
ecc.

sanbiz Profilo | Senior Member

Dipende molto anche dal database che stai utilizzando.
Se si tratta di Access direi che meno dati inserisci in un database e meglio è. Quindi la soluzione dei 100 database io la preferire. Anche perchè se si danneggia un database sai quello che perdi.

Piuttosto sarebbe molto interessante migrare ad un database un po' più serio, tipo SQL
Qui adotterei la strategia delle tre tabelle Anagrafica, Messaggi, Attività tutte e tre con un campo "codAzienza" che ne discrimina i dati.
In questo modo quando andrai a cercare, ad esempio, le anagrafiche dell'azienza "pippo" farai una cosa del tipo:
select * from Anagrafica where codAzienda = 'pippo'

Imho questa è la solizione ottimale soprattuto per gestire grosse moli di dati.
--
Sandro Bizioli
http://blogs.dotnethell.it/sandro/

Jumpa Profilo | Junior Member

confermo e sottoscrivo cio che dice sanbiz!

in più ti direi che tenendo "tutto insieme" hai vantaggi in evntuali operazioni "cross-azienda" mi viene in mente magari la gestioen dei cambi valutari sono uguali per tutti, e la gestione delle aziende molto piu semplificata tipo crearne una nuova...non devi creare un nuovo db ma semplicemente un nuovo codice azienda



ciao ciao

Jumpa
-------------------------
Follow the White Rabbit...

http://www.jumpa.org
-------------------------

fabiogvn Profilo | Newbie


In effetti ho omesso la cosa principale, ovvero che la base dati è SQL Server.

Anch'io sono propenso a cercare di integrare il tutto nello stesso db, addirittura mi sarebbe piaciuto creare un'unica tabella aziende, dipendenti, messaggi e attività e discriminare il tutto con i vari campi Id sulle tabelle, ma la mole di record sarebbe in questo caso veramente alta, facendo un'ipotesi approssimativa saremmo intorno ai 3.500.000.000 record per le tabelle messaggi e attività e non so cosa potrebbe succedere eseguendo delle query su una tabella così grande, non ho esperienze di questo tipo purtroppo.
Qualcuno di voi ha esperienza con SQL Server e grandi numeri di record, oltre il miliardo in questo caso?
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5