5 DB spørgsmål til eksperterne

Som jeg husker det saa ner det VARCHAR 8000 og NVARCHAR 4000.

Mange tabeller kan ihvertfald ikke betale sig.

De oplagte loesninger maa vaere:
  * et felt NVARCHAR(4000) og bed folk fatte sig i korthed !
  * et felt NTEXT and that is it
  * to felter - et NVARCHAR(4000) og et NTEXT som kun bruges til tegn 4001- for meget
    lange tekster

#1 duer nok ikke.

#2 er simplest og vil derfor normalt kunne anbefales.

#3 vil nok performe lidt bedre, hvis de fleste tekster er under 4000 tegn.

Hej Arne!

1. Hvad er det nu NTEXT står for? og hvad er grænsen på denne type?

2. Jeg bruger aspnet_Users tabellen - brugernes UserId findes også i alle andre tabeller som et felt, som har relation til brugeren. Vil det så hjælpe på performance at oprette "relationships" imellem tabellen aspnet_Users's felt "UserId" og alle de tabeller som reelt har en relation til tabellen?

3. Her tænkte jeg på at beskytte selve databasen imod ondsindet angreb.

Jeg er nu langt fra enig med at mange tabeller ikke kan betale sig, jeg mener netop at ved at distribuere sine data lidt ud vil man opnå flere fordele, dels på sikkerheden, men også på performance. Med sikkerheden tænker jeg på backup/ restore og performance ved opslag i flere tabeller evt. horisontal partitionering på SQL2005.

Det er selvfølgelig noget sværere at styre flere tabeller, men jeg vil mene skalérbarheden vil overskygge dette, men igen.. det kommer helt an på behovet.

En mulighed kunne være at oprette ntextfelter har kan have ligeså store indlæg som muligt og oprette fulltextindexering(FTI) på indholdet. Jeg formoder du gerne vil have svartider der sparker røv og så er FTI altså vejen frem. Hvis du skulle lave en nogenlunde fleksibel søgning via normale where clauses, ville du typisk skrive:
select * from table where '%søgeord%' og det er netop den wildcard i begge ender der dræber databasen (index tages ikke i brug på sådan en svend) og hvis du så ovenikøbet også vil lave en søgning der hedder "pesto and pizza" altså med AND, så skal du til at bygge din where-clause yderligere op.. GABBBB og vi ender i det nye år med sådan en forespørgsel *GG*

Ja du har fat i sagen der med primary-foreign keys, god indexering på den slags felter vil forbedre performance. Du kigger på indexeringen af disse efter du har lavet dit tabeldesign og ligesom kender de joins der anvendes. oftest er primary keys allerede clustered så der får du lidt forærende.. (lang snak og et helt andet emne og ja man kan gøre mange andre ting for at opnå god performance)

Du skal altid lave dine joins korrekt, en tommelfingerregel siger at hvis du bruger distinct over på dine joins er dine joins kandidater til yderligere gennemgang og normalisering/ denormalisering - den slags finder du ud af under datamodelleringen (husk at starte med det konceptuelle først)

Du skal forlange af dit hostingselskab at sikkerheden skal være i top og ligeledes kende til deres ansvar og erstatningspligt hvis noget går i stykker. Husk også at kende til backup-frekvensen osv.

Jeg tror ikke der findes noget værktøj til SP's, en SP indeholder jo ofte specifik businesslogic, næh... det er kun de simpleste select, insert, update, delete der kan autogenereres - bare klø på, når du sidder og skriver SP's lærer du også designet at kende og kommer helt sikkert i tanke om andre måder at designe det på :)

Det der tool der... det er svært hvis der ikke er trust imellem domænerne, du kunne evt. bede hostingselskabet om at få lagt backuppen på dit domæne og så selv ftp'e den til et sikkert sted!

Og de andre spørgsmål der..
nvarchar-felter kan du højst gemme 4000 chars i, varchar 8000 (ca. tal)

At du indexerer aspnet_users tabellen er totalt ligegyldigt, ihvertfald hvis du har under tjaa... jeg vil gætte på 50.000 users, måske 100.000 svært lige at sige, men i små tabeller vil queryoptimizeren oftest vælge tablescan fordi et index måske vil være langsommmere at slå op i.

NTEXT max 1 milliard tegn

Hvis dit hosting firma er bare en lille smule kompetente, så er der lukket rimeligt godt
af for direkte adgang til databasen.

Og så er største trussel huller i web applikationen. Et code review af den er formentligt
det der giver mest sikkerhed for indsatsen.

okay gutter! I skal have mange tak for de mange ord - håber at eksperten også bruger NTEXT ;)

Læg begge et svar! Så får Arne 50 points og Janus 100 points...

btw...det findes ikke nogen skudsikker måde at skjule postback data på vel...ja altså for brugeren ikke for selve browseren :) Altså en måde at deaktivere "View source code"?

E bruger MySQL.

Formentlig TEXT - 64 KB, MEDIUMTEXT - 24 MB eller LONGTEXT - 2 GB.

Du kan ikke skjule noget der bliver sendt ud til browseren.

janus: Er ntext en forudsætning for at kunne køre FTI?

text/ntext er vist på vej YT
http://www.sql-server-helper.com/faq/sql-server-2005-varchar-max-p01.aspx

neoman: Kiggde lidt i TSQL-dokumentationen (for 2005). Dit link siger at VARCHAR(MAX), NVARCHAR(MAX) og VARBINARY(MAX) vil erstatte TEXT, NTEXT and IMAGE. I min dokumentation er de "ny" typer alle nogle skravlede nogle, der kun kan indeholde hhv. 8000, 4000 og 8000 bytes - men det er der måske ændret på med "max"?

Skriver man virkelig "add test varbinary(max)"? Det skal nok sætte nogle SQL managere tilbage at man pludselig skal tillade bogstaver i et talfelt.

http://msdn2.microsoft.com/en-us/library/ms176089.aspx siger dette:
varchar [ ( n | max ) ]

    Variable-length, non-Unicode character data. n can be a value from 1 through 8,000. max indicates that the maximum storage size is 2^31-1 bytes. The storage size is the actual length of data entered + 2 bytes. The data entered can be 0 characters in length.

(N)VARCHAR(MAX) er saa vidt jeg ved reelt en (N)TEXT d.v.s. samme funktionalitet
bare med et nyt navn

Hvis databasen skal være større end 1 TB kan jeg godt se noget pointe i partitionering.

Men til mindre databaser vil den opsplitning give dårligere performance.

Og selvom man vil partitionere, så tror jeg ikke at det er den rigtige måde at splitte
op på.

og et svar fra mig

Og et svar fra mig...

Glad for jeg kunne hjælpe :)