Vaidas Žilionis Internetas, technologijos, programavimas…

Turbūt daugelis žino, kad atsarginių kopijų turėjimas yra svarbus – ypač verslo sektoriuje. Vieni iš svarbiausių duomenų yra saugojami duomenų bazėse (ji daug dinamiškesnė), tad jų atsargines kopijas reikia darytis daug dažniau nei failų sistemoje.

Duomenų bazės (mysql) galima padaryti paprastu cronjob scriptu:

mysqldump -uVartotojas -pSlaptazodis LentelesVardas | gzip > /path/to/backup/vardas-$(date +%Y-%m-%d-%H.%M.%S).gz

Tokių kopijų darymas ne visuomet yra saugus. Saugiausia atsargines kopijas saugoti nuotoliniame serveryje. Nuotolinio serveriui išlaikyti irgi reikalingi pinigai, tad jei jūsų duomenų bazė nėra didelė galima paprasčiausiai atsarginę kopiją nusiųsti el. paštu.
Tai jums padės paprastas programėlė kurią galite parsisiųsti iš backup2mail.com. Jei jūs turite paprasčiausią hostingą serveriai.lt (asmeninis/verslas) tai jus ja pasinaudoti nepavyks, kadangi yra apribojimai tam tikrom komandoms.

Kur geriausia siūsti atsargines kopijas? Kodėl gi neišnaudojus Gmail el. pašto dėžutės? Dar ir dabar turiu virš septynių gigabaitų laisvos vietos, o atsarginė kopija kuri ateina užima tik pusę megabaito.

Kiekvienas dirbantis savo srityje turi įrankius, web programuotojas ne išimtis. Kadangi esu PHP programuotojas parašysiu ką naudoju ir kokie įrankiai po ranka.

• Zend Studio – turintis daug gerių savybių PHP redaktorius… deja kainuojantis.
• Eclipse – Galingas redaktorius skirtas redaguoti įvairių progamavimo kalbų kodui su sintaksės spalvinimu, autocomplete palaikymu ir t.t. Tereikia įsidiegti papildomus pluginus ir jūs turėsite naujų savybių. Šioje programoje yra bent man geriausias matytas CVS/SVN palaikymo pricipas: sinchronizacija skirtymų – atnaujini tik tai ką tau reikia. Na PHP programuotojai gali pradėti diegti nuo PHPEclipse iškart gaus PHP palaikyma. Nemokamas
• SQLyog MySQL GUI – Community Edition – MySQL duomenų bazės programėlė. Patogu testuoti užklausas, analizuoti struktūras ir t.t. Maloniausia, kad ši versija nemokama. Mokomoj versijoje atsiranda kitų gerų toolsų, tokių kaip duomenų bazių palyginimas (skirtumai ir etc), sinchronozavimai, exportavimai/importavimai iš įvairių formatų. Nemokamas
• WinMerge – Failų skirtymų palyginima.
• The Regex Coach – reguliujų išraiškų programėlė. Palengvina regex’ų rašya
• Na turbūt į sąrašą reiktų įtraukti ir žymujį PHPMyAdmin bet PHP manualą (tiesa chm formate su paieška ir komentarais) :)

Kas būtų dar naudinga? Jūsų nuomonė…

Visai įdomus sprendimas ir idėja nebloga, nors paprasta. Patestuokite patys, kolkas supranta PHP, Mysql, Javascript, Css.

Ką gi pasirodo yra naujas paleistas projektas www.mysql.lt. Kuriame kolkas veikia tik forumas, bet žadama būti wiki ir pan. Tad manau tikslinė kategorija žmonių gali reikštis čia.

Neseniai rašiau apie problemą kai perėjus prie MySQL5 atsirado problema su UTF-8 duomenis. Taigi google užklausos nepadėjo nie kiek, tad teko pagalvoti logiškai, ir sprendimą radau.

Situacija

Duomenų bazės, lentelių, stulpelių collation yra cp1257
Duomenys išsaugoti UTF-8 formatu.
Duomenims įterpti dar nenaudojams SET NAMES, SET CHARSET

Užduotis

Sutvarkyti taip, kad būtų teisingi collcate.

Sprendimas

PHPMyAdmin ar kitos toolsas kuris pritaikytas mysql 4.1 ar mysql 5 tikrai netinga. Nes juose jau naudojamas set names, set charset ko pasekoje duomenis tampa sugadinti. Ką gi vadinasi reikia tools’o kuris nenaudotu exportuojant jų. Išvada darom backup’ą be setnames. Paieškojęs phpclasses susiradau elemantarią klasikę padarančią duomenų bazės backupą, kaip ir tikėjausi ji nenaudoja specifinių SET NAMES, SET CHARSET. Kadangi kaikurių lentelių dydis gan didelis ir PHP pradeda keiktis kai per daug duomenų patenka į RAM, teko ją optimizuoti eksportuoti po vieną lentelę.

Paleidus skriptą ji eksportuoja duomenis teisingai. Tereikia paredaguoti struktūra nurodant teisingą collation (Šiuo atveju pakeičiant cp1257 į UTF8) pvz

CREATE TABLE `sst_duk` ( `id` int(11) NOT NULL auto_increment, `klausimas` text NOT NULL, `atsakymas` text NOT NULL, `publikuoti` int(11) NOT NULL default '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=cp1257;

pakeičiant į

CREATE TABLE `sst_duk` ( `id` int(11) NOT NULL auto_increment, `klausimas` text NOT NULL, `atsakymas` text NOT NULL, `publikuoti` int(11) NOT NULL default '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=UTF8;

žinoma ir rekomenduotina pačios lentelės collation pakeiti jau į teisingą.

Po perėjimo į MySQL 5 versiją serverio standartinis collation tapo windows-1257 (nes dauguma projektų naudoja šią koduotę). Po mažu pereinėja projektai ant UTF-8 ypač jei naudojama daugiau nei viena kalba.

Taigi turim projektą, kurį importavus duomenys saugomi UTF-8 koduotę, o nurodyti collation windows-1257. Keista bet kolkas veikia teisingai (na rušiavime turi būti problemų). Bet va ant db noriu pakeisti į UTF-8 kodavimą ir t.t. Klausimas kaip tą padaryti nepažeidžiant duomenų? Padarius DUMP per PHPmyAdmin duomenys jau ateina pažeisti. Toks vaidzdas kad reiktų kovertuoti du kartus, kad atgauti orginalų tekstą su teisingomis koduotėmis.

Turbūt kas susidūrę suprato problemą, tad kokios idėjos?

Pas mus firmoje upgreidinome servą, vienas pakeitimų MySQL 5 versija. Kolkas visų navarotų nespėjau išnaudoti, vis atlieku pritaikymus prie mysql 5 darbus. Vien upgreidinti neužtenka, reikia ir žinoti ne vieną niuansą. Keletą jų parašysiu.

Duomenų importavimas ir mysql naudojimas

Jei jūs naudojate tokią pačią koduotę kokia nustatyta pa default, problemų mažiau turėsite, bet jei prasideda vienu windows-1257 kodavimas, kitur UTF-8 prasideda niuansai.

• Jei importuojate, nepamirškite pirma pasirinkti db kuotuotę
• Rekomenduočiau pirmiau importuoti struktūra o po to duomenis. Duomenis galima importuoti po to kai matote kad stuktūra yra teisinga (su teisingais collcatais)
• Prisiminkte su nauja versija, naujom savybėms atsiranda naujų rezervuotų “žodžių”, tad visur stengitės naudoti teisingą sintaksę užklausuose. Bus saugiau :)

Select `id`, `name`, `repeat` from `tablename`

• Kai programiškai db inicijuojate nepamirškite nurodyti ir šios junties koduotės:

$db->query(‘SET NAMES UTF8’);
$db->query(‘SET CHARSET UTF8’);

Logikos pasikeitimai

Pasikeitė ir logikos užklausose. tarkim užklausa nebus teisiga, ją reiktų pakeisti su 2 joinais :).

Select d.vardas, d.pavarde, pr.pavadinimas, pad.pavadinimas as padalinys from darbuotojai as d, pareigos as pr LEFT join padalinys as pad on pad.id=d.padalinys_id where d.pareigos_id=pr.id and d.id=12

Įsivaizduokime įprastą situaciją. Ya kažkoks sąrašas pateiktas svetainėje. Jei jis bus nedidelis, jį galima paprastai atvaizduoti. Jei sąrašas gali ilgėti vadinasi prireiks puslapiavimo kurį galima lengvai padaryti.

Tarkim seniau buvo tarkim prekių kainų sąrašas nepuslapiuotas. Jis patogus buvo dėlto, kad iš prekės aprašymo galima lengvai nušokti į to sąrašo tam tikrą vietą. Galima ir pasinaudoti anhoru:

 <a href=”su:su:/linkas.php#preke12″>šok čia</a>

Galima ne tik nušokti, bet ir pažymėti :)

<a href=”su:su:/linkas.php?zymek=12#preke12″>šok čia</a>

Viskas gražu ir t.t. Didėjant kiekiui neaoptimalu viską pateikti vienoje vietoje, tikrai naudinga ir puslapiuoti. Va ir iškilo klausimas: Turiu sąlygas kaip atrenkamas sąrašas, žinau rikiavimo sąlygas, o kaip sužinoti kur bus pagal tuos parametrus įrašas kurio id=12. Jis gali būti ir pradžioje ir gale. Taigi va ir kankinausi ieškodamas sprendimo. Taigi sužinojus vietą (eiliškumą) galima lengvai surasti ir puslapį kuriame bus. O kaip tai praktiškai įgyvendinti?

Vienas variantas. Tempiam į PHP visą lentelę, ir ieškom (sukam ciklą) kur tas įrašas bus. Žinoma surasim, gal ir patogu, bet!. Dideliam kiekiui duomenų reiks viską tempti, tai vadinasi ilgiau užtruks, be to duomenys parsiųsti bus talpinami į RAM, taigi didėjant duomenų kiekiui bei lankytojų kiekiui gali atsirasti situacija “Ramo trūksta”. Tad vadinasi sprendimas blogas.

Gal yra galimybė tai atlikti kažkaip kitaip? Logiškiausia paduoti gudrią užklausą ir taip sužinojus vietą, jau tempti tik duos duomenis kurie reikalingi. Paeksperimentavęs radau vieną iš galimų sprendimų:

set @a:=0;<br />select @a as nr, r.id from&nbsp;LENTELE as r<br />where @a:=IF((r.id=19),(@a+1),(@a+1)) having r.id=19 order by id

Kodėl tokia įdomi sąlyga @a:=IF((r.id=19),(@a+1),(@a+1))  nežinau net pats, realiai reikia @a+1 tiktai, o be IF neveikia :(

Ką gi gavu numeriuką reikiamą, viskas gražu, na beveik gražu. Truputį lėtoks sprendimas, net nežinau ar jis tinkamas ant didelių lentelių.  va norėtusi kažkokio optimalesnio varianto.

Gal kokių idėjų pasiūlytumėte?

2005-05-16 papildymas:

Šiektie pasikapstęs ir pan gavau ir tokį sprendimą

set @i=0;
CREATE TEMPORARY TABLE `findrownumber` Select (@i:=@i+1) as rownumber, `id`, `title` FROM table where `active`=1 order by `title` asc;
SELECT * FROM `findrownumber` WHERE `id` = 23

Ant kiek jis geras spręskite patys :)

Šiandien kažkaip užsižaidžiau su labai paprasta užduotimi, kuriai reikia išrinkti unikalius vardus, ir tam tikra kryptimi surikiuoti. Lentelė yra didelė, pateiksiu tik minimalų pavyzdį.

taigi. reikia man išrinkti unikalius vardus tokiu pricipu (gaila bet neveikia)

SELECT DISTINCT type,lan,page FROM lentele order by nr

taigi ka as noriu gauti, 1 eiliskuma ziurint pagal tipa small, big, good, no. Problema yra ta kad gaunu unikalius, bet ne tokiu rikiavimo požymiu. Toks vaizdas kad DISTINCT jei randa uzdeda ant viršaus, taigi aš small gausiu paskutinėje vietoje o reikia kad būtu pirmoje.

Gal kas turite idėjų?

Gaila bet duomenų bazėje nėra “tipo” rikiavimo požymio, aš su mielu noru pasidaryčiau, jis gali kisti….ty big atsirasti numeriu 1. Taigi tą duomenų bazę valdau ne aš… 

Paprastai atvaizduojant viskas gražiai gaunasi, lengvai small idedu 1 vietoj… bet norint turėti unikalius, pagal tą patį rikiavimo požymį jau atsiranda problema….

Svajojau, svajojau ir prisisvajojau. Dar viena puiki gimtadienio dovana. Reiks adminui liepti kad updatintu mysql iki 4.1

Valio!!