Dotaz: PhpMyAdmin - Omezení vkládaných dat

[Dušan S.]

Ahoj, jak můžu v phpmyadminu udělat omezení pro nějaký sloupec, jedná se mi o to, aby do něk šlo zapsat pouze číslo 0,1,5 a 9. Díky za pomoc

---

---

Odpovědi

[Kit]

Obávám se, že na tohle je databáze MySQL krátká. Zkusil jsem

CREATE TABLE omezeni(cislo int CHECK(cislo IN(0,1,5,9)));

Příkaz sice proběhl bez chyby, ale uložilo se každé číslo bez omezení. Když jsem zkusil totéž s databází SQLite, fungovalo to naprosto bez vady. Pokud tuto funkčnost a mnoho dalších chybějících v MySQL potřebuješ, doporučuji přejít na SQLite.

[kt]

Co datovy typ ENUM?

[Kit]

Zkusil sis to? Mně to nefunguje. Naprosto s přehledem to vkládá i čísla, která v ENUM nejsou.

[Šangala]

To by mělo fungovat, viz výpis:

mysql> select @@sql_mode;
+------------+
| @@sql_mode |
+------------+
|            | 
+------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE e ( abc ENUM('a', 'b', 'c') ) ENGINE = MyISAM;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into e(abc) VALUES('invalid');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> SHOW WARNINGS;
+---------+------+------------------------------------------+
| Level   | Code | Message                                  |
+---------+------+------------------------------------------+
| Warning | 1265 | Data truncated for column 'abc' at row 1 | 
+---------+------+------------------------------------------+
1 row in set (0.00 sec)

mysql> select * from e;
+------+
| abc  |
+------+
|      | 
+------+
1 row in set (0.00 sec)

mysql> SET @@session.sql_mode = 'STRICT_TRANS_TABLES';
Query OK, 0 rows affected (0.00 sec)

mysql> insert into e(abc) VALUES('invalid');
ERROR 1265 (01000): Data truncated for column 'abc' at row 1
mysql> select * from e;
+------+
| abc  |
+------+
|      | 
+------+
1 row in set (0.00 sec)

Ale ENUM nedoporučuji, a je otázkou jestli bude fungovat s klauzulí NOT NULL (takže k výčtu přibude i NULL).

[Kit]

ENUM s řetězci funguje, ale nefunguje s čísly.

[Šangala]

Ano, ale lze jej na čísla normálně používat a nevložíš hodnotu mimo výčet.

mysql> select @@sql_mode;
+---------------------+
| @@sql_mode          |
+---------------------+
| STRICT_TRANS_TABLES | 
+---------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE e ( abc ENUM('1', '2', '3') ) ENGINE = MyISAM;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into e(abc) VALUES(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into e(abc) VALUES(9);
ERROR 1265 (01000): Data truncated for column 'abc' at row 1
mysql> select * from e;
+------+
| abc  |
+------+
| 1    | 
+------+
1 row in set (0.00 sec)

mysql> select abc*7 AS col from e;
+------+
| col  |
+------+
|    7 | 
+------+
1 row in set (0.00 sec)
mysql> 

[Kit]

OK, tak si zkus tohle:

CREATE TABLE e ( abc ENUM('0', '1', '5', '9') ) ENGINE = MyISAM;
INSERT INTO e(abc) VALUES(1);
INSERT INTO e(abc) VALUES(3);
SELECT * FROM e;

Mně to vypisuje hovadiny.

[Šangala]

Aha no jo, tak sorry, chová se to na čísla perfektně, to mě baví …
Chová se to tak, že pokud zadáš číslo, a není platné, tak se to bere jako index a pokud je v rozhsahu tak se to vloží.

0 → '0' (dle hodnoty)
1 → '1' (dle hodnoty)
2 → '1' (dle indexu)
3 → '5' (dle indexu)
4 → '9' (dle indexu)
9 → '9' (dle hodnoty)

jiná čísla nejsou platná - to se vyplatí, ne?!

[Šangala]

…ještě 5-ka (dle hodnoty)…

[Kit]

Jenom zírám, kam až nás zavedl nefunkční CHECK. A to jsme ještě neprolezli variantu s triggery...

K čemu je vlastně taková DB dobrá, když musíme základní vlastnosti flikovat? Velmi často vidím její použití jako KVS. Na to opravdu SQL nepotřebujeme.

[Šangala]

To si musí každý zvážit sám, je to jednoduché rychlé SQL úložiště.
Pokud někdo chce udělat DB aplikaci s maximální integritou a logikou v DB, stejně se nevyhne triggerům funkcím a to už je CHECK jen taková třešnička. Sám jsem nepracoval/nevytvářel DB jak někteří, kteří musí „co select to VIEW, a co operace to funkce“ (což byla sranda dřív na některých DBE, pokud funkce neměli pojmenované parametry, jen pořadí a bylo jich tam třeba 12).
Ale dělal jsem něco, kde mi přišel jako ohromný nápad používat CREATE DOMAIN (Firebird) na kde co - už to dělat nebudu .
Běžnou aplikaci, z mého pohledu dostatečnou integritou a logikou, s použitím triggerů a několika funkcí, lze v MySQL naprosto normálně udělat.
Ale jinak pro mě má MySQL nezastupitelnou úlohu, protože umí nativně unsigned typy a různé typy INT-ů, pro někoho je to prkotina, jak už n-krát zaznělo, ale pokud je DB o 1/3 až 1/2 menší, tak se vleze do paměti (nebo tam toho aspoň zůstane víc).
Na MySQL jsem v minulosti provozoval normálně aplikaci na stroji (s velmi málo paměti), na který Oracle nešel nainstalovat, a PostgreSQL jsem rozumně nerozchodil (číst z disku a swapovat nešlo dohromady).

[Kit]

Podle mne je MySQL primitivní pomalé úložiště. Za jednoduché rychlé SQL úložiště považuji např. SQLite, které si místo pro různé typy INTů alokuje dynamicky od 1 Bytu a na web se hodí mnohem lépe.

[Šangala]

<joke>To je ten DBE, který využívá Evolution a musím ho lidem každou chvíli spravovat bo se totálně rozjedou index-i?</joke>
(Nevím kde je chyba, ale děje se to při nedostatku místa na disku a to dojde proto, že při mazání DB potřebuje 2-6× více místa pro smazání, než jsou index-i mazaných dat, jako hláška na win při mazání souboru „Pro danou operaci není dostatek místa na disku, uvolněte místo smazáním jednoho nebo více souborů“)

[Kit]

Ano, to bude asi on. Zřejmě autoři Evolution nezvládli jeho použití, možná mají chybu v datovém modelu. Mně se nerozsype ani při přeplnění disku. Zkušenosti s chováním SQLite na Windows nemám.

Příkaz VACUUM spotřebuje 3x víc místa, ale to by při podobné operaci udělaly všechny databáze. Při mazání DB není potřeba žádné místo navíc, prostě se smaže soubor.

[Šangala]

To nebylo hláška z SQLLite na Windows, ale z obecného mazání souboru při plném disku přes Explorera…
SQLite & Evolution:
Uživatel nemaže DB ale maže záznamy a vysype koš, a je možné, že se provádí VACUUM, každopádně výsledkem je, že uživatel nedostane žádné info o chybě, a při otvírání pošty pod hlavičkou něčeho má úplně něco jiného a nebo to tam vůbec není (i když pošta na disku normálně je) - důvodem tohoto chování, je nedokončená DB operace, totálně rozhašené index-i ukazující kamkoliv, jenom ne tam kam by měli (a místo na disku opět je, protože i když se operace nedokončí, místo alokované touto operací se uvolní).
Buď vývojáři ignorují návratový kód operace a pak i chybu integrity při opětovném otvírání db, nebo to dbe neohlásí a v druhém případě o tom ani neví, protože normálně funguje - jen jinak…

[Kit]

Databáze SQLite má licenci Public Domain. Autoři Evolution z ní mohli vyházet vše, co z jejich pohledu snižuje výkon, včetně některých bezpečnostních mechanismů. Možná ani nepoužili transakce či triggery, které SQLite normálně podporuje.

Při přeplnění disku se SQLite běžně chová tak, že operaci neprovede a ohlásí chybu ve formě stavového kódu. Pokud ho aplikace ignoruje, je to její problém.

Otázkou je, jestli chyba integrity je na úrovni databáze nebo na úrovni Evolution. Myslím si, že to spíš bude to druhé a důvodem bude špatný datový model a nepoužívání transakcí.

[Dušan S.]

Já jsem to tak kdysi měl, čili předpokládám, že to umí, dokonce pokud jsem vkládal data pomoci phpmyadmina tak jsem nemohl ani zadat hodnotu, musel jsem vybrat hodnotu ze selectobxu - což bylo fajn..

[Kit]

S phpMyAdminem nemám téměř žádné zkušenosti, může dělat některá integritní omezení na aplikační úrovni. MySQL sice integritní omezení přijme (neohlásí chybu), ale z vysoka se na ně >/dev/null

[Filip Jirsák]

Nezáleží to na typu úložiště? InnoDB by to mohlo umět...

[Kit]

Zkusil jsem to, výsledek úplně stejně tragický. Přitom podporu InnoDB mám funkční. MySQL 5.1.57.

Kromě toho podpora InnoDB není na webhostingu příliš často k vidění.

[Filip Jirsák]

No jo:

The CHECK clause is parsed but ignored by all storage engines.

Nemůžu si pomoc, MySQL si svou pověst zaslouží...

[Šangala]

Obecně: v MySQL omezení vstupu můžete udělat jen s použitím triggeru (třeba BEFORE INSERT).