Violazione dei principi SQL

5 clients and that their info will never join their data together. Is it admissible to have a potentially infinite number of tables with a table per client?

Non sono sicuro di dove stai andando. Disponi di più copie della tabella Client ? hai più copie delle tabelle che sono unite con Client ? In entrambi i casi, entrambi questi progetti causeranno problemi in futuro, principalmente con problemi di manutenzione a lungo termine.

Di solito ciò che succede è che il modello di dati cambia, quindi devi propagare la modifica a tutte le tabelle copiate e sperare che non si rompa nulla. Ad esempio, la rimozione / modifica delle colonne potrebbe non compromettere l'integrità referenziale per la maggior parte dei client, ma potrebbe esserlo per alcuni, quindi l'ambiente di test deve includere esempi di tutti dati copiati.

Un altro problema è che se stai facendo report, devi unire tutte le tabelle copiate se vuoi che il tuo report copra più di un sottoinsieme delle strutture copiate. Ciò può comportare interrogazioni molto lunghe e ingombranti e, se dimentichi la tabella di un cliente, i risultati saranno sbagliati.

E poi hai il problema di avere query e codice legati ai nomi delle tabelle copiate anche se potrebbero fare tutte la stessa cosa.

Ci sono alcuni casi in cui ciò è utile e forse necessario, ma trovo che sia qualcosa che richiede un po 'di riflessione e una buona ragione per farlo.

Is it admissible to make an unordered query and just assume that is implicitly ordered?

Se l'ordinamento del set di risultati non ha importanza, o se hai intenzione di riordinarlo più tardi nella tua applicazione (magari dopo qualche filtraggio / processo in-application molto specifico), allora non vedo perché questo è un problema. Se vuoi assicurarti che il set di risultati sia ordinato correttamente, aggiungi una clausola ORDER BY alla tua query.

Naturalmente, se si scopre che alcune tabelle vengono frequentemente colpite con la stessa query e le stesse condizioni di ordinamento, potrebbe avere senso ordinare l'indice utilizzato dalla query in modo che sia ordinato come il modo più comunemente utilizzato. Questo potrebbe darti dei miglioramenti nelle prestazioni. Anche se lo fai, direi che è comunque una buona idea includere ORDER BY . Principalmente in modo che qualcuno che non ha familiarità con il codice sa esattamente quale sia l'ordine e non deve scavare attraverso le definizioni del database per capirlo. Il modo in cui fai questo può variare a seconda del prodotto del database che stai utilizzando (se è addirittura supportato, ma penso che la maggior parte dei principali motori di database lo supportino).

Ok - non puoi creare un piccolo tavolo ordinato - l'ordine in cui inserisci i record non è garantito come l'ordine in cui li fai uscire quando fai un SELECT - assumendo qualsiasi altra cosa e stai per chiedere dei bug in futuro anche se ora funziona.

Una tabella per client va bene, ma probabilmente non è necessaria: è una di queste cose che dipende dalla tua situazione specifica.

Tuttavia, l'aggiunta di una clausola di ordinamento a una query quando appropriato non sarà costosa - le cose che ti servono per assicurarti che tu stia andando bene:

La normalizzazione Struttura delle query / solo recupero dei dati corretti

Il problema principale con la maggior parte dei nuovi sviluppatori di database è che hanno enormi tabelle di Dio con centinaia di colonne e in realtà non interrogano per quello che vogliono: mirano a recuperare la minor quantità di dati necessaria e quindi l'ordinamento diventa banale.

Non è mai garantito che la query venga restituita in ordine di indice cluster, che è l'unico ordine che è probabile che ottenga implicitamente. La "convenienza" per te è che il sistema si comporta come ti aspetti, ma qualcun altro che sta interrogando o modificando il sistema può avere aspettative diverse che portano a bug.

Avere la stessa tabella ripetuta per client è un modo di fare multi-tenancy che è un argomento separato.

Non ci si deve preoccupare se i dati nella tabella siano ordinati o meno in SQL. Esiste la clausola ORDER BY in SQL se è necessario ordinare il risultato della query. Se non hai bisogno di ordinare resuts, basta selezionare. Le prestazioni dipenderanno dall'uso di una corretta indicizzazione e dalla conservazione degli indici e delle statistiche e fino ad oggi. 1 concerto può sembrare grande, ma nel mondo di oggi non dovrebbe essere un grosso problema per creare una struttura di tavolo performante.

Non è necessario avere molti piccoli tavoli per ogni cliente. Non si desidera supportare un database con molte tabelle in cui solo alcune saranno necessarie, a meno che non si desideri fornire tali livelli di isolamento come servizio. In altre parole, un modello che può essere distribuito su 1 a molte istanze e da 1 a molti server.

Ci sono circa 3 livelli per il tuo modello:

• Condivisi - Un server, un database, molti client, i client hanno condiviso il stesso modello e tabelle.
Istanza
• Un server, più database, molti client, client condividere o avere la propria istanza del modello.
• Server - Server multipli, database multipli, più istanze, molti client - Client condividere, avere la propria istanza o avere la propria istanza e il proprio server (Isolato)

Costo saggio $ Condividi < $$$ Intannce < $$$$$ Server e dovrebbe essere valutato come tale.

Che cosa dici al tuo capo?

Svilupperemo 1 modello di database che può essere distribuito secondo necessità, a seconda di come il cliente vuole isolare i propri dati.

Penso che sia sempre importante avere abbastanza umiltà per dire che sono sopra la mia testa e ottenere un aiuto professionale.