Lunghezza del campo di stringa SQL in un db con circa 6 diversi tipi di indirizzi, con circa 20 mercati e ambienti

Question

Lunghezza del campo di stringa SQL in un db con circa 6 diversi tipi di indirizzi, con circa 20 mercati e ambienti

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

0

Recentemente ho sostenuto che tutti i campi stringa dovrebbero essere ntext / nvarchar (max) - stiamo usando MS SQL Server. Le obiezioni sembrano essere "non è una buona idea" (senza alcun motivo) o "che permetterebbe al cliente di inviare un sacco di merda". Dal momento che credo di filtrare la merda prima che colpisca il database, c'è un motivo buono perché la mia idea è sbagliata?

Il mio argomento principale per non limitare i campi stringa è che ho scoperto che abbiamo circa sei diversi tipi di indirizzi (cliente, rivenditore e così via), con circa 20 mercati (ognuno con il proprio database) e ambienti. Ho individuato almeno dieci lunghezze diverse per dire Address1 e la stessa cosa accade per altri campi. Invece di "standardizzarli" e poi scoprire che ci siamo persi qualcosa, ho suggerito di andare avanti e limitare gli input e lasciare che il database gestisca qualsiasi cosa.

Qualcuno ha un pro / contro che non vedo?

(Ho visto Regola empirica per le dimensioni dei campi ma il mio obiettivo è "sta rendendo tutto sbagliato nella dimensione massima?")

sql architecture

posta Marcel Popescu 05.03.2014 - 14:04

fonte

3 risposte

Leggi altre domande sui tag sql architecture

Applicazione punti vendita online e offline [chiusa] attivatore sqlite o evento applicativo?

score 2 · Answer 1

Ti suggerisco di andare al link o ai forum MSDN SQL e porre questa domanda. Potresti ricevere minacce fisiche suggerendo una cosa del genere.

Da un punto di vista della programmazione, ha senso. Perché non dovresti semplicemente lasciare il database in possesso di qualsiasi cosa e quindi limitarlo nell'applicazione? Dal punto di vista della modellazione dei dati, è come una bestemmia. Dovresti scoprire qual è il massimo consentito e usarlo, oppure analizzare e strutturare il database in modo che ogni mercato abbia le sue specifiche tabelle di indirizzi. A parte il problema di prestazioni, è una cattiva progettazione del database. È un cattivo design del database perché un indirizzo è una cosa reale e ogni paese ha regole molto specifiche sugli indirizzi. Negli Stati Uniti, la documentazione è ... scoraggiante. Ma esiste.

Potresti anche considerare che solo perché il database non è destinato ad essere popolato da nessuna parte eccetto questa applicazione, è possibile che possa finire in quel modo più tardi.

score 1 · Answer 2

Mentre si è tentati di passare alla recinzione e fornire una quantità di spazio sufficiente (mai interfacciato con un sistema COBOL con record minuscoli a larghezza fissa?), non è necessariamente una buona idea.

Per i campi di testo enormi esiste una penalizzazione delle prestazioni, come sottolineato da utente1021726 . Probabilmente non sarai in grado di creare indici su quei campi.

La mia regola empirica è guardare alcuni dati di esempio, trovare la stringa ragionevole più lunga che si possa inserire e aggiungere il 50%. Se un indirizzo può contenere al massimo 40 caratteri, imposta il campo 60. Ciò non si applica alle stringhe a larghezza fissa come un SSN o un ID fiscale federale.

Vorrei anche pensarci due volte sull'uso di Unicode ("N" per il carattere "Nazionale") su ogni campo. Anche se è certamente una buona idea per qualcosa come un nome o un indirizzo che l'utente vedrà, vorrei evitarlo per qualsiasi campo interno che potrebbe essere usato da un indice o unirsi a e l'utente non può inserire direttamente i dati in esso. So che con almeno SQL Server, Unicode rende gli indici e i join più lenti. Anche in SQL Server, gli indici possono essere solo tanti byte e NVARCHAR ha una larghezza doppia. Per questi campi interni, l'utilizzo di campi VARCHAR più brevi è sicuramente di aiuto per le prestazioni.

score 0 · Answer 3

Potresti fare tutto al massimo, ma poi devi metterti alla prova. Prestazioni quando ogni campo supera i 2 GB di spazio di archiviazione? Probabilmente non va bene.

Pertanto, è sempre una buona idea porre dei limiti alle cose, così ora vedrai come funzionerà il sistema e per limitare i dati che il sistema può accettare e trasmettere.