data type mediumtext

[renathy]

Vai juus kaadreiz izmantojat MySQL db field-am datu tipu - mediumtext - vai arii labaak izmantot varchar?

(runa iet par field-u, kuraa glabaajas teksts, piemeeram, article_content un article_title)

 

R.

[briedis]

es izmantoju vienkārši text :)

[rATRIJS]

Title (nosaukumam) vēlams būtu VARCHAR, bet content (saturam) Text. Vismaz tā daru es :)

[Kavacky]

Ir vēl arī TINYTEXT.

[Grey_Wolf]

apskaties cik buus MAksimalais simbolu ( skaits) un no taa vadoties arii izdoma kuru tipu lietot.

warchar ir 255 BAITI ( nevis simboli ). taa kaa parasti tiek saglabats UTF -8 formataa, tad jarekjinas ka dazi simboli var aiznjemt vairak par 1 Baitu ( LR skiet ka bija 2 Baiti, bet var trapiities arii kads 'Inpora' kursh var aiznjemt 4 baitus...

---

[2easy]

btw, kas tev tik apjomīgs ir jāglabā, ka nepietiek ar vnk text? varbūt bildes vai kādi upload faili? tos gan labāk liec folderī un db glabā tikai path

 

oops, neizalsīju otro rindu from renathy

article_title varchar(100)  // vai varchar(200), ja ir gaaaarš title
article_content text  // normāli būtu jāpietiek ar atliektiem galiem. un kurš tad lasītu rakstiņu, kam ir vairāk par 65k chari? :D

warchar ir 255 BAITI ( nevis simboli ). taa kaa parasti tiek saglabats UTF -8 formataa, tad jarekjinas ka dazi simboli var aiznjemt vairak par 1 Baitu

ja tabulai ir norādīts charset utf8, tad varchar garums = utf8 simbolu skaits (nevis baiti)

c valodā gan datu tips char = byte, bet mysql char ir augstāka līmeņa abstrakcija ;)

Edited December 21, 2009 by 2easy

[Grey_Wolf]

c valodā gan datu tips char = byte, bet mysql char ir augstāka līmeņa abstrakcija ;)

Nee nevienmer :(

Itkaa jaa, bet diemzel...

ir prbaudiits uz 'savas aadas'

jo pamatojums vienkarsh --> DB parasti 'rezerve' vietu prieks doaa tipa..

taa kaa Warch. ir 255 + 2 (garumam) tad UTF-8 nostradaas..

Char teiksim ir fikseets.. un panjems max atljautos Baitus ...

Un arii Viss buus atkariigs no konfiguracijas etc.. taa kaa Uz sho labaak nepaljauties..

Edited December 21, 2009 by Grey_Wolf

[renathy]

Ok. Paldies. Tad izmantoshu varchar un text.

Vienkarshi vienaa tutoriaalii uzradaas shis mediumtext bez paskaidrojumiem...

 

R.

[2easy]

Char teiksim ir fikseets.. un panjems max atljautos Baitus ...

Un arii Viss buus atkariigs no konfiguracijas etc.. taa kaa Uz sho labaak nepaljauties..

un uz mysql official reference arī nevar paļauties?

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Data Type - Storage Required

CHAR(M) - M × w bytes, 0 <= M <= 255, where w is the number of bytes required for the maximum-length character in the character set

tātad pēc mysql dokumentācijas sanāk, ka max atļautie ir simboli/chari, nevis baiti. protams, ka db pati menedžē, cik daudz vietas vajag konkrētajam char/varchar pie attiecīgā kodējuma, tādējādi noslēpjot zemāka līmeņa tehniskās nianses. tāpēc jau visādas dbms tika radītas, lai atvieglotu darbu programmētājiem

 

ok, no vārdiem pie darbiem: notestējam, vai pie char/varchar limitiem rodas kkādi gļuki, kas nesaskan ar mysql dokumentāciju:

function qs($s) {  // sagatavo stringu priekš sql query
return is_null($s) ? 'NULL' : "'" . mysql_real_escape_string($s) . "'";
}
function go($sSql) {  // mysql query ar error reportingu
$h = mysql_query($sSql) or die('<b>mysql error ' . mysql_errno() . ':</b> ' . mysql_error() . '<br /><b>query:</b> ' . substr($sSql, 0, 1000));
return $h;
}

function estr($s) {  // echo string for debug (baiti:chari:strings)
echo 's:' . strlen($s) . ':' . mb_strlen($s, 'utf-8') . ':' . $s . '<br />';
}

// testa dati/strings sastāv no utf8 'ā', 253x nullītēm un flaga '123'. šo stringu iebarošu abiem tabulas laukiem
// ja taisnība ir mysql dokumentācijai, tad vietas pietiktu pirmajiem 255 simboliem, bet atlikušie '23' tiktu notrimoti
// ja taisnība ir Vilkam, tad divbaitīgajam 'ā' vajadzētu atstāt aiz borta visus trīs '123'
$s = 'ā' . str_repeat(0, 253) . '123';
estr($s);  // s:258:257:ā0000000000...0000000000123 (baiti ir par vienu vairāk nekā chari, jo utf8 'ā' aizņem 2x baitus)

go('DROP TABLE IF EXISTS t');
go('CREATE TABLE t (c char(255), s varchar(255)) ENGINE=MyISAM CHARSET=utf8');
go('SET NAMES utf8');
go('INSERT INTO t (c, s) VALUES (' . qs($s) . ', ' . qs($s) . ')');

list($sChar, $sVarchar) = mysql_fetch_row(go('SELECT * FROM t'));
estr($sChar);  // s:256:255:ā0000000000...00000000001
estr($sVarchar);  // s:256:255:ā0000000000...00000000001
// and the winner is... mysql dokumentācija!!! congratz ;)

šo kodu notestēju uz 2 dažādiem mysql serveriem (versijas 4.1.22 un 5.0.75), un abās vietās no problem

 

Vilks, varbūt tev bez tā "pamatojuma" ir arī konkrēts piemērs (kkas ko var izpildīt un pārliecināties)? pat ja ir kkāda mysql mode/settingi, pie kuriem tā notiek, tad kādi? savādāk ar tādām frāzēm no sērijas "man vnreiz kkad kkā tā gadījās" tu tikai radi kkādus mītus

 

visticamāk, ka tas, ko Vilks reiz "pārbaudīja uz savas ādas", varēja gadīties, kad insertojamo datu kodējums atšķiras no tabulas kodējuma, piemēram, tabulai ir cp1257, bet tajā inserto utf8 datus

restaurēju šo situāciju...

go('DROP TABLE IF EXISTS t');
go('CREATE TABLE t (c char(255), s varchar(255)) ENGINE=MyISAM CHARSET=cp1257');
go('SET NAMES cp1257');
go('INSERT INTO t (c, s) VALUES (' . qs($s) . ', ' . qs($s) . ')');

list($sChar, $sVarchar) = mysql_fetch_row(go('SELECT * FROM t'));
estr($sChar);  // s:255:254:ā0000000000...0000000000
estr($sVarchar);  // s:255:254:ā0000000000...0000000000
// tgd patiešām ir notrimoti visi trīs '123', jo vienbaitu kodējumā cp1257 katrs utf8 'ā' baits tika uzskatīts par astsevišķu simbolu/charu