Søk i database - valg av datatype

[Xqtor]

Jeg skal lage en enkel 'bug-database' hvor man kan registrere ulike typer feilemldinger.

 

Hva slags datatype bør jeg velge på feltet som skal inneholde selve feilmeldingen? Dette kan fort bli mye tekst. BLOB kan lagre store mengder, men jeg er usikker på hvor enkelt det er å søke gjennom tekst i et BLOB-felt?

[endrebjo]

Du skriver ikke hvilken database du bruker, men statistisk sett vil du bruke MySQL.

I MySQL kan du bare sette fulltekst søk på CHAR, VARCHAR og TEXT. Altså ikke BLOB.

TEXT lagrer like mye som BLOB, men BLOB er 'binary-safe'.

[Xqtor]

Beklager - det er MySQL.

[blackbrrd]

hvis databasen støtter datatypen text så bruker du den, det er vel nesten ingen grunn til å bruke varchar o.l.

 

Postgres støtter også text forresten

[Manfred]

...og mssql

[blackbrrd]

... så, hva sier oracle folkene?

[Wattengård]

De sier ingenting, de er opptatt med å samle inn penger til den neste oppgraderingen...

 

-C-

[kaffenils]

hvis databasen støtter datatypen text så bruker du den, det er vel nesten ingen grunn til å bruke varchar o.l.

 

Postgres støtter også text forresten

9488525[/snapback]

 

Håper du ikke mener at alle felt som skal lagre tekst bør være av type text?

[blackbrrd]

hvis databasen støtter datatypen text så bruker du den, det er vel nesten ingen grunn til å bruke varchar o.l.

 

Postgres støtter også text forresten

9488525[/snapback]

 

Håper du ikke mener at alle felt som skal lagre tekst bør være av type text?

9491559[/snapback]

 

Tjah...

http://www.postgresql.org/docs/8.0/interac...-character.html

 

Tip: There are no performance differences between these three types*, apart from the increased storage size when using the blank-padded type. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.

 

*varchar, char, text

 

så, sjeldent det er noen god grunn til å bruke noe annet? Applikasjonen må samme hva vite hva som er maks lende på feltet...

[roac]

...og mssql

9490137[/snapback]

Bruk av text i MSSQL er fra SQL Server 2005 ikke anbefalt, det som anbefales i SQL Server 2005 og senere er varchar(max) evt nvarchar(max), avhengig av om du skal ha støtte for unicode eller ikke.

[kaffenils]

Nå kjenner ikke jeg de interne lagringsstrukturene i MySQL og PostgreSQL, men i SQL Server så lagres ntext og text i egne data pages, noe som selvfølgelig har negativ konsekvens for ytelse. Tydeligvis gjelder ikke dette for PostgreSQL.

 

Som roac sier så anbefales det å bruke nvarchar(max) eller varchar(max) i SQL Server 2005 da data lagres i radens data page hvis det er plass, ellers flyttes den til en row-overflow data page. text og ntext vil sannsynligvis forsvinne i senere utgave av SQL Server.

[roac]

Nå kjenner ikke jeg de interne lagringsstrukturene i MySQL og PostgreSQL, men i SQL Server så lagres ntext og text i egne data pages, noe som selvfølgelig har negativ konsekvens for ytelse. Tydeligvis gjelder ikke dette for PostgreSQL.

9492030[/snapback]

La meg arrestere deg der Nils Tenk deg for eksempel en database hvor du normalt ikke søker i description, men kanskje på brukernavn, maskinnavn etc. Da vil det være en stor fordel å ha description-feltet (nvarchar(max) kanskje) i egne datapages, siden du ikke trenger å lese disse når du gjør et søk. Det eneste tilfellet jeg kommer på i farten er dersom du bruker varchar(max) eller varchar(max) og sammenligner med tekstfeltet (og andre felter), da vil det kunne ha negativ innvirkning på ytelsen. Men jeg tør påstå at det i de fleste tilfeller faktisk vil ha en ytelsesmessig fordel.

[kaffenils]

La meg arrestere deg der Nils Tenk deg for eksempel en database hvor du normalt ikke søker i description, men kanskje på brukernavn, maskinnavn etc. Da vil det være en stor fordel å ha description-feltet (nvarchar(max) kanskje) i egne datapages, siden du ikke trenger å lese disse når du gjør et søk. Det eneste tilfellet jeg kommer på i farten er dersom du bruker varchar(max) eller varchar(max) og sammenligner med tekstfeltet (og andre felter), da vil det kunne ha negativ innvirkning på ytelsen. Men jeg tør påstå at det i de fleste tilfeller faktisk vil ha en ytelsesmessig fordel.

9492562[/snapback]

 

Du har selvfølgelig indexert brukernavn eller maskinnavn siden dette er vanlige søkebegreper, og da spiller det ingen rolle om description er lagret i clustered index/heap sidene. De gangene du har behov for å hente description så vil du få en negativ innvirking på ytelse, og siden 0+negativ er negativ så synes jeg fortsatt jeg har rett

[roac]

Du har selvfølgelig indexert brukernavn eller maskinnavn siden dette er vanlige søkebegreper, og da spiller det ingen rolle om description er lagret i clustered index/heap sidene. De gangene du har behov for å hente description så vil du få en negativ innvirking på ytelse, og siden 0+negativ er negativ så synes jeg fortsatt jeg har rett 

9492747[/snapback]

Jeg skjønner hvor du vil. Hvis vi ignorerer effekten av at du får færre datablokker med "row data" så har du rett. Denne effekten er selvfølgelig minst merkbar for nonclustered indexes samt clustered index seek. For table scan og clustered index scan vil det dog være en klar ytelsesmessig fordel. Mao: det kan både være en fordel og en ulempe at text/ntext lagres out of row, men nå er vi vel strengt tatt en "liten bit" forbi det trådstarter lurte på føler jeg

[kaffenils]

men nå er vi vel strengt tatt en "liten bit" forbi det trådstarter lurte på føler jeg

 

Sorry trådstarter, når får vi slutte for mod kommer og tar oss :!:

God helg alle sammen!

[blackbrrd]

Ey...

 

Etter hva jeg har fått med meg så lagres text i "tabellen" helt til størrelsen blir for stor, da blir text-kolonnen lagret utenfor tabellen. Dataene blir forresten komprimert av postgres. Relativt logisk når man tenker på at det er svært dyrt å lese ting til/fra disk og tekst komprimerer ca 4:1 eller bedre...

 

[EDIT dette gjelder postgres, beklager forvirringen]

Endret 17. september 2007 av blackbrrd

[roac]

Etter hva jeg har fått med meg så lagres text i "tabellen" helt til størrelsen blir for stor, da blir text-kolonnen lagret utenfor tabellen. Dataene blir forresten komprimert av postgres. Relativt logisk når man tenker på at det er svært dyrt å lese ting til/fra disk og tekst komprimerer ca 4:1 eller bedre...

9497177[/snapback]

I SQL Server? Nope, det er ikke standardoppførsel fra SQL Server. SQL Server lagrer alle LOB data som standard i separate datapages, men du kan bruke en option som heter "text in row" for å få den funksjonaliteten, men det er som sagt ikke standard.

[kaffenils]

I SQL Server? Nope, det er ikke standardoppførsel fra SQL Server. SQL Server lagrer alle LOB data som standard i separate datapages, men du kan bruke en option som heter "text in row" for å få den funksjonaliteten, men det er som sagt ikke standard.

9508978[/snapback]

 

SQL Server 2005 lagres varchar(max), nvarchar(max) og varbinary(max) i IN_ROW_DATA pages hvis det er plass. Du må sette "large value types out of row" hvis du alltid vil lagre i LOB_DATA.

text, ntext og image lagres alltid i LOB_DATA, som du sier, med mindre "text in row" er satt til ON slik jeg har skjønt det. "text in row" vil forresten bli fjernet i fremtidige versjoner av SQL Server.