Il codice EF utilizza innanzitutto nvarchar (max) per tutte le stringhe. Questo danneggerà le prestazioni delle query?

Ho creato alcuni database usando prima Entity Framework Code; le app funzionano e in generale sono abbastanza contento di ciò che Code First mi permette di fare. Per prima cosa sono un programmatore e un secondo DBA. Sto leggendo su DataAttributes per descrivere ulteriormente in C # cosa voglio che faccia il database; e la mia domanda è: quale penalità dovrò mangiare avendo queste nvarchar(max)stringhe nella mia tabella (vedi esempio sotto)?

Ci sono diverse colonne in questa particolare tabella; in C # sono definiti come tali:

    [Key]
    [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Message { get; set; }
    public string Source { get; set; }
    public DateTime Generated { get; set; }
    public DateTime Written { get; set; }

Mi aspetto di eseguire una query e / o ordinare in base a Nome, Origine, Generato e Scritto. Mi aspetto che Nome e Sorgente abbiano una lunghezza di 0-50 caratteri, a volte fino a 150. Mi aspetto che questa tabella inizi abbastanza piccola (<100k righe), ma cresca in modo significativo nel tempo (> 1m righe). Ovviamente il messaggio potrebbe essere piccolo o grande e probabilmente non verrà interrogato.

Quello che voglio sapere, c'è un hit di performance per le mie colonne Nome e Sorgente che vengono definite come nvarchar(max)quando non mi aspetto che siano più grandi di 150 caratteri?

Gli elementi di dati nvarchar (max) più grandi (oltre 8000 byte circa) si riverseranno nella memoria di testo e richiederanno I / O aggiuntivi. Gli articoli più piccoli verranno archiviati in fila. Esistono opzioni che controllano questo comportamento: vedi questo articolo MSDN per maggiori dettagli.

Se memorizzato nella riga, non vi è un sovraccarico di prestazioni I / O significativo; potrebbe esserci un sovraccarico di CPU aggiuntivo sull'elaborazione del tipo di dati, ma è probabile che questo sia minore.

Tuttavia, lasciare le colonne nvarchar (max) attorno al database dove non sono necessarie è una forma piuttosto scadente. Ha un certo sovraccarico di prestazioni e spesso le dimensioni dei dati sono abbastanza utili per comprendere una tabella di dati - ad esempio, una colonna varchar larga 50 o 100 caratteri potrebbe essere una descrizione o un campo di testo libero in cui uno che è (diciamo) 10- 20 caratteri probabilmente è un codice. Sareste sorpresi di quanto significato si debba spesso dedurre da un database attraverso ipotesi come questa.

Lavorare nel data warehousing, spesso non su sistemi legacy scarsamente supportati o documentati, avere uno schema di database facile da capire è piuttosto prezioso. Se pensi al database come all'eredità dell'applicazione, cerca di essere gentile con le persone che lo erediteranno da te.

Sebbene questo non risponda alla tua domanda specifica, potrebbe precluderti la necessità di porre la domanda in primo luogo: è possibile impostare una lunghezza sulle variabili di stringa nella classe del modello C #, che farà sì che Entity Framework generi SQL che utilizza un tipo nvarchar di lunghezza fissa (ad esempio nvarchar(50)), anziché nvarchar(max).

Ad esempio, anziché:

public string Name { get; set; }

Puoi usare:

[StringLength(50)]
public string Name { get; set; }

Puoi anche forzare il tipo in modo che sia varcharinvece nvarchar, se lo desideri, come segue:

[Column(TypeName = "VARCHAR")]
[StringLength(50)]
public string Name { get; set; }

Fonte: https://stackoverflow.com/questions/7341783/entity-framework-data-annotations-set-stringlength-varchar/7341920

Indicizzare la più grande preoccupazione. Da BOL:

Colonne che sono dei tipi di dati LOB (large object) ntext, text, varchar(max), nvarchar(max), varbinary(max), xml, o imagenon possono essere specificate come colonne chiave per un indice.

Se non riesci a indicizzare correttamente, avrai query lente. E dal punto di vista dell'integrità dei dati, avere nvarchar(max)consentirà di inserire più dati errati in un campo rispetto a quando si specifica il limite.

Sì, il comportamento EF predefinito nel mapping stringa nvarchar(max)non è buono. In EF 6 puoi aggiungere la tua convenzione personalizzata per sovrascrivere questo comportamento con la tua mappatura predefinita preferita.

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Properties<string>()
        .Configure(s => s.HasMaxLength(200).HasColumnType("varchar") );

    base.OnModelCreating(modelBuilder);
}

Sostituendo OnModelCreatingcome sopra cambierà il mapping predefinito per tutte le stringhe in varchar(200).