| Autor | Zpráva | ||
|---|---|---|---|
| Oje Profil |
#1 · Zasláno: 9. 12. 2014, 21:39:05
Zdravím. Dávám dohromady databázi pro web, u níž předpokládám (no spíš bych si přál) mezinárodní využití, resp. bude vytvořena v angličtině. Nejsem si zcela jistý, jaké zvolit kódování, aby mě potkalo co nejméně problémů. Kódování moc nerozumím, bohužel.
Co se mi podařilo vyčíst, mělo by se používat při tvorbě nových tabulek "utf8_general_ci" a pak při každém připojení k databázi "mysql_query("SET CHARACTER SET utf8"). Nejsem si jistý, jesti se jedno s druhým pouze nepřekrývá. Pomůže právě tohle kódování předejít nefunkčnosti některých jindy funkčních příkazů? V jedné fázi tvorby jsem použil na zkoušku utf8_czech_ci, ale stejně jsem se dostal při testování do problému ve chvíli, kdy jsem databázi tabulku pojmenoval názvem obsahujícím "č" - tabulku později dotaz nenašel, v phpmyadmin se název tabulky zobrazoval se znakem "è" místo "č". Snad je možné se podobným zádrhelům vyhnout. Předem děkuji za pomoc a názory. |
||
| Joker Profil |
#2 · Zasláno: 9. 12. 2014, 23:00:09
Oje:
„Nejsem si zcela jistý, jaké zvolit kódování, aby mě potkalo co nejméně problémů.“ Univerzální rada je: UTF-8, pokud není důvod volit nějaké jiné. Jinak lepší než SET CHARACTER SET je SET NAMES. A samozřejmě texty posílané do databáze musejí reálně být v tom kódování (resp. po připojení se má udělat SET NAMES kódování použité pro odeslání dat).
To COLLATE kódování není až tak podstatné. „jsem databázi tabulku pojmenoval názvem obsahujícím "č"“ Tomu bych se asi raději vyhnul a tabulky pojmenovával bez diakritiky. |
||
| Oje Profil |
#3 · Zasláno: 9. 12. 2014, 23:31:37
Joker:
děkuju za odpověď. Tomu bych se asi raději vyhnul a tabulky pojmenovával bez diakritiky. jde o to, že se bojím, co si tam vyplní uživatelé. Samozřejmě tabulka jde pojmenovat jinak než uživatel, ale beztak hodnoty od uživatelů budou nějak do databaze vstupovat a potřebuji s jejich hodnotami pracovat. Univerzální rada je: UTF-8, pokud není důvod volit nějaké jiné. Měl jsem ještě na mysli, jestli utf8 unicode nebo utf8 general. Na základě načteného bych řekl spíše unicode. za předpokladu, že je lepší užívat utf8_unicode_ci, zeptal bych se, jestli náhodou nevíš/nevíte, jak udělat v php kód, který toto kódování nastaví. můj kód: mysql_query("CREATE TABLE `".$userreg."`(
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY(id),
title VARCHAR(30),
rating_estimate INT NOT NULL) DEFAULT CHARSET=utf8")nastaví právě utf8_general_ci... (v kódu je vidět také neštastné pojmenování nové tabulky po uživateli) ještě jednou děkuju za reakce :) |
||
| Keeehi Profil |
#4 · Zasláno: 10. 12. 2014, 01:52:13
Oje:
Ono půjde hlavně o to, že při správném návrhu databáze ji není potřeba měnit. Registrace uživatele? Vytvoříme nový záznam v tabulce "user" (INSERT INTO user ...) a né že hned budeme vytvářet novou tabulku pojmenovanou třeba uzivatel_pepa (CREATE TABLE uzivatel_pepa) Jinak řečeno, všechny tabulky si naklikej v phpmyadmin jak potřebuješ a c php používaj jen dotazy "SELECT, INSERT, UPDATE a DELETE". Tím pádem máš strukturu databáze plně pod svou kontrolou (názvy tabulek a soupců -> nepoužívej diakritiku). A potom v datech od uživatelů už iakritika nevadí, s tím si databáze určitě umí poradit. A nezapomeň všechny uživatelské vstupy ošetřit. mysql_real_escape_string pro řetězce, přetypování (int) pro čísla atp. |
||
| Joker Profil |
#5 · Zasláno: 10. 12. 2014, 09:17:06
Oje:
„jde o to, že se bojím, co si tam vyplní uživatelé.“ Jestli to je aplikace pro návrh či správu databází, měla by umět různá kódování. V opačném případě není důvod, aby běžná činnost aplikace vedla ke vzniku nových tabulek a už vůbec ne, aby ty tabulky pojmenovával uživatel. Běžná činnost aplikace nemá měnit její vlastní datový model. |
||
| Oje Profil |
#6 · Zasláno: 10. 12. 2014, 23:35:15
Joker:
děkuju, o tom ošetření vstupů jsem nevěděl. Moje vize je složitější a bude obsahovat množství dat (cca 4rozměrné), u kterých se mi zdálo praktické, aby pro každého uživatele vznikla vlastní tabulka. Jestliže je to neštastné řešení, zkusím se vydat jinudy. |
||
| Karel N. Profil |
#7 · Zasláno: 10. 12. 2014, 23:44:50
Oje: nejen nešťastné, jedná se o vyloženě špatné řešení. Představ si, že budeš potřebovat přidat nový sloupec, budeš ho přidávat u všech desítek uživatelů do tabulky ručně? Dalším důvodem jsou zbytečně vysoké nároky na výkon pro databázi na udržení velkého množství tabulek. Obecně platí zásady, že v databázi nevytáříš více tabulek se stejnými sloupci.
|
||
| Joker Profil |
#8 · Zasláno: 11. 12. 2014, 08:49:48
Oje:
Tak už představa, že si aplikace za běhu bude měnit svůj vlastní datový model, by intuitivně měla zavánět problémy. Hlavní technický problém bude, že relační databáze na takový přístup nejsou stavěné a nepočítají s ním. Nemají třeba možnost jednoduše a rychle na základě nějakých podmínek vybírat a třídit tabulky z databáze nebo sloupce v tabulce. Kdyby každý uživatel měl svou tabulku, jak by se třeba udělala tak jednoduchá operace jako: Vyber všechny uživatele seřazené abecedně podle jména? |
||
| Oje Profil |
#9 · Zasláno: 12. 12. 2014, 20:45:55
Joker:
ok, budu to mít na paměti. No já v téhle konkrétní databázi mám i tabulku s uživateli. V databázích mám ještě hodně co dohánět a určitě je pravda, že lze vytvářet databázi tak, aby se neměnil počet tabulek, dík. |
||
|
Časová prodleva: 9 let
|
|||
0