|
|
 | MySQL og UNIQUE på TEXT
Fra : Jens Thomsen |
Dato : 15-10-07 21:49 |
|
Æv - Jeg har brug for en kolonne, der kan klare mere end 255 tegn
(hexadecimal streng), som jeg kan gøre unik.
MySQL mener åbenbart anderledes:
1170 - BLOB/TEXT column 'Dims' used in key specification without a key
length
Og jeg har ikke kunnet finde ud af at give nogle af TEXT-varianterne en
længde.
Hvad gør man så? 
| |
 Philip Nunnegaard (15-10-2007)
| Kommentar
Fra : Philip Nunnegaard |
Dato : 15-10-07 22:24 |
|
> Og jeg har ikke kunnet finde ud af at give nogle af TEXT-varianterne en
> længde.
Felttypen TEXT skal ikke have nogen længde eller andre attributter hæftet på
sig og kan klare ret mange tegn.
Ved ikke lige *hvor* mange tegn, men vi er ude i noget, der kan rumme hele
artikler - altså flere tusinde tegn - muligvis 10240- eller 20480 tegn???
| |
Peter Brodersen (15-10-2007)
| Kommentar
Fra : Peter Brodersen |
Dato : 15-10-07 23:49 |
|
On Mon, 15 Oct 2007 22:49:06 +0200, "Jens Thomsen" <jt@nej.nej> wrote:
>Æv - Jeg har brug for en kolonne, der kan klare mere end 255 tegn
>(hexadecimal streng), som jeg kan gøre unik.
Den hurtige løsning er at gemme en hash, fx en md5-sum af feltets
indhold og så tjekke op imod den - altså lade md5-sum-feltet være
UNIQUE.
>MySQL mener åbenbart anderledes:
>
>1170 - BLOB/TEXT column 'Dims' used in key specification without a key
>length
>
>Og jeg har ikke kunnet finde ud af at give nogle af TEXT-varianterne en
>længde.
Det er ved oprettelsen af indexet, du skal angive, hvor mange tegn,
det skal være på. Det samme er tilfældet, hvis det er VARCHAR.
Det er dog lidt noget rod, idet UNIQUE-constrainten så ikke tjekkes
for tegn ud over det angivede.
--
- Peter Brodersen
Kendt fra Internet
| |
Thorbjørn Ravn Ander~ (16-10-2007)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 16-10-07 07:01 |
|
Peter Brodersen <usenet2007@ter.dk> writes:
> Den hurtige løsning er at gemme en hash, fx en md5-sum af feltets
> indhold og så tjekke op imod den - altså lade md5-sum-feltet være
> UNIQUE.
Flere indhold mapper til samme md5 værdi, så der er en risiko for
kollisioner. Fidusen ved md5 er at det er ret svært at hitte et
indhold med en given md5 værdi.
--
Thorbjørn Ravn Andersen
| |
 Peter Brodersen (16-10-2007)
| Kommentar
Fra : Peter Brodersen |
Dato : 16-10-07 14:53 |
|
On 16 Oct 2007 08:00:56 +0200, nospam0000@gmail.com (Thorbjørn Ravn
Andersen) wrote:
>Flere indhold mapper til samme md5 værdi, så der er en risiko for
>kollisioner. Fidusen ved md5 er at det er ret svært at hitte et
>indhold med en given md5 værdi.
Yep, den risiko er der altid ved en hash. Men det er en risiko, man
accepterer i så mange andre sammenhænge.
Spørgsmålet er derudover, om der er tale om konstrueret indhold, hvor
man kan skabe falske matches og få noget ud af det.
--
- Peter Brodersen
Kendt fra Internet
| |
Thorbjørn Ravn Ander~ (16-10-2007)
| Kommentar
Fra : Thorbjørn Ravn Ander~ |
Dato : 16-10-07 22:06 |
|
Peter Brodersen <usenet2007@ter.dk> writes:
> Yep, den risiko er der altid ved en hash. Men det er en risiko, man
> accepterer i så mange andre sammenhænge.
Det er bare ikke superfikst hvis det SKAL være en unik værdi. Det
udskyder bare problemet...
--
Thorbjørn Ravn Andersen
| |
Jens Thomsen (16-10-2007)
| Kommentar
Fra : Jens Thomsen |
Dato : 16-10-07 10:09 |
|
> Det er ved oprettelsen af indexet, du skal angive, hvor mange tegn,
> det skal være på. Det samme er tilfældet, hvis det er VARCHAR.
Ah perfekt!
Det virker.
> Det er dog lidt noget rod, idet UNIQUE-constrainten så ikke tjekkes
> for tegn ud over det angivede.
Er det ikke bare at sætte index-længden høj nok?
Eller ofter man for meget performance?
Jeg har sat den til 500, og i praksis *tror* jeg ikke der kommer nogen over
300.
| |
|
|