MySQL a unikátní sloupce

[Marie]

Ahoj.
Umí MySQL nastavit unikátní i něco jiného, nebo umí pouze samostatný jeden sloupec? Dík. M.

[Reklama]

[gll]

https://dev.mysql.com/doc/refman/5.7/en/multiple-column-indexes.html

[Marie]

No, mě se spíš jedná o to, aby nešel zapsat duplicitní řádek, aby v mysql nešlo uložit něco jako

Kód: [Vybrat]

id name val
1  aaa   10
2  aaa   10
3  aaa   10
ale může tam být

Kód: [Vybrat]

1  aaa   10
2  aaa   20
3  aaa   30nebo i

Kód: [Vybrat]

1  aaa   10
2  bbb   10
3  ccc   10

[Kit]

Kód: [Vybrat]

CREATE TABLE t1 (
    id SERIAL,
    name DATE NOT NULL,
    val INT NOT NULL,
    UNIQUE KEY (name, val)
);

[Filip Jirsák]

To není dotaz na MySQL, ale na základy relačních databází.

Ta odpověď od gll je správně a unikátním indexem nad sloupci name a val docílíte přesně toho, co popisujete.

[Reklama]

[Marie]

Děkuji. 

[Kit]

To není dotaz na MySQL, ale na základy relačních databází.

Ta odpověď od gll je správně a unikátním indexem nad sloupci name a val docílíte přesně toho, co popisujete.

V odkazu, který poslal gll, není nic o unikátních indexech. Přesto mu to nemám za zlé.

Otázka byla položena správně. Dva jsme odpověděli, třetí si zatrolil.

[gll]

Index a key jsou v mysql synonyma.

[Kit]

Index a key jsou v mysql synonyma.

Index nemusí být unikátní. Požadavek však byl na unikátní dvojici, na což se místo B-tree používá hash. Používá snad MySQL v obou případech B-tree?

[gll]

máš pravdu, není to tam. Odkaz jsem nečetl, vzal jsem první výsledek z googlu.

[Filip Jirsák]

V odkazu, který poslal gll, není nic o unikátních indexech. Přesto mu to nemám za zlé.

Vždyť jsem psal, že jeho odpověď je správně. Podle dotazu Marie už o unikátních indexech něco zaslechla, ale nevěděla, že je možné vytvořit index nad více sloupci.

Otázka byla položena správně.

Otázka byla položena správně, to jsem nezpochybňoval – ale svědčí o tom, že Marie nezná ani základy relačních databází. Na tom není vůbec nic špatného, každý někdy začínal – ale tyhle znalosti se nedají získat dotazováním se na diskusních fórech. Je potřeba nejprve získat nějaké základní penzum znalostí a hlavně celkový přehled – a teprve pak se něco dozvím, když se budu ptát na konkrétní detaily.

Omlouvám se, pokud má první odpověď zněla příliš příkře. Byla to dobře míněná rada, že to není dotaz na nějaký implementační detail MySQL, ale že pokud chce Marie jakkoli pracovat s databází, bude potřebovat naučit se základy relačních databází.

Dva jsme odpověděli, třetí si zatrolil.

První, kdo tu trolí, jste vy.

[Kit]

Dva jsme odpověděli, třetí si zatrolil.

První, kdo tu trolí, jste vy.

Netrolil jsem, ale odpověděl na dotaz. Tak se laskavě koukni do zrcadla. Žádnou relevantní odpověď jsi nenapsal, jen trolíš.

[Filip Jirsák]

Žádnou relevantní odpověď jsi nenapsal, jen trolíš.

Podle odpovědi se Marie domnívala, že nedostala odpověď na svou otázku. Takže ujištění, že je to správná odpověď na její otázku, bylo na místě.

Netrolil jsem, ale odpověděl na dotaz.

Nejprve jste odpověděl na dotaz, a v dalších komentářích jste začal trolit – a vymýšlet si. U MySQL jsou v CREATE TABLE klíčová slova KEY a INDEX prakticky synonyma (rozdíl je jenom v tom, že KEY někdy může znamenat PRIMARY KEY). KEY a INDEX neovlivňují typ indexu. B-Tree samozřejmě umožňuje unikátní index, a InnoDB a MyISAM ani jiný typ indexu, než B-Tree, nepodporuje. Hash indexy podporují jen MEMORY a NDB. Doporučuji přečíst si o příkazech CREATE TABLE a CREATE INDEX v referenční příručce MySQL, tyto informace tam najdete.

Mimochodem, odpověď na vaši sugestivní otázku:

Používá snad MySQL v obou případech B-tree?

tedy zní: ano (alespoň pro InnoDB a MyISAM, nevím, jaký je default index pro MEMORY a NDB).