PHP ir MySQL programavimas, SQL užklausos, duomenų bazės, PHP scriptai, pagalba, diskusijos, pamokos ir straipsniai.
You are not logged in. Please login or register.
PHP ir MySQL → Posts by neworld
Tai tu tik džiaukis kad bent tiek gauni. Bet iškarto įspėju, šitas valymas yra sudėtingas ir daug laiko suėdantis dalykas, nes joks pluginas tau nepasakys ar toks CSS nėra panaudoajamas suvedus blogai formos duomenis.
Bandžiau sugalvoti kokią nors padoresnę architektūrą, kad nenaudojamiems elementams būtų lengvai pašalinti nebereikalingus CSS, bet deja, nelabai pavyko.
Radau pats atsakymą:
SELECT
t2.first_name,
t2.last_name,
t1.winner,
t2.weight,
t2.wins,
t2.pic_big,
IF ('1511765885' = t1.fighter_1, t1.fighter_2, t1.fighter_1) AS friend
FROM
lw_fb_fights AS t1
JOIN
lw_fb_users AS t2 ON t2.id = IF ('1511765885' = t1.fighter_1, t1.fighter_2, t1.fighter_1)
WHERE
t1.fighter_1 = '1511765885' OR t1.fighter_2 = '1511765885'Pirmai turbūt buvau padaręs kitą klaidą ir galvojau sąlyginis JOIN neveikia, bet jis veikia puikiai
Turiu užklausą:
SELECT
t2.first_name,
t2.last_name,
t1.winner,
t2.weight,
t2.wins,
t2.pic_big,
IF ('1511765885' = t1.fighter_1, t1.fighter_2, t1.fighter_1) AS friend
FROM
lw_fb_fights AS t1
JOIN
lw_fb_users AS t2 ON t2.id = friend
WHERE
t1.fighter_1 = '1511765885' OR t1.fighter_2 = '1511765885'fighters lentoje yra du kovotojai, vienas iš jų aktualus vartotojas, o kitas priešininkas. Man reikia išrinkti info apie priešininką, kuris gali būti arba fighter_1 arba fighter_2. šioje užklausoje JOIN nemato laukeli friend. Gal kas turite įdėjų?
Absoliučiai nieko nekeičiau. Naujoje lentelėje viskas veikia :)
Išsiprendžiau tiesiog sukurdamas naują lentelę, perkeldamas duomenis. Matyt kažkas su indexais arba failo strukūra
Turiu tokią lentelę:
CREATE TABLE `buildings` (
`id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
`title` varchar(64) NOT NULL,
`point` smallint(5) unsigned NOT NULL DEFAULT '0',
`cost` int(10) unsigned NOT NULL DEFAULT '0',
`size` tinyint(1) unsigned NOT NULL DEFAULT '1',
`guest` smallint(4) unsigned NOT NULL DEFAULT '1',
`time` mediumint(8) unsigned NOT NULL DEFAULT '1',
`use` tinyint(1) NOT NULL DEFAULT '1',
`buildingTime` mediumint(8) unsigned NOT NULL DEFAULT '0',
->`type` enum('P','K','A','L','E') NOT NULL, <-----
`desc` mediumtext,
`ticket` tinyint(3) unsigned NOT NULL DEFAULT '0',
`kategorija` char(16) DEFAULT NULL,
`basePasitenkinimas` float(6,3) unsigned NOT NULL DEFAULT '50.000',
`max` smallint(2) unsigned NOT NULL DEFAULT '0',
`atsiperka` tinyint(3) unsigned NOT NULL DEFAULT '0',
`fizika` tinyint(2) unsigned NOT NULL DEFAULT '0',
`statybos` tinyint(2) unsigned NOT NULL DEFAULT '0',
`architektura` tinyint(2) unsigned NOT NULL DEFAULT '0',
`technika` tinyint(2) unsigned NOT NULL DEFAULT '0',
`nt` tinyint(2) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `type` (`type`),
KEY `kategorija` (`kategorija`)
) ENGINE=MyISAM AUTO_INCREMENT=60 DEFAULT CHARSET=utf8ir bandant paupdeitinti lentelę:
UPDATE buildings SET `type` = 'E' WHERE id = 623
gaunu klaidą:
1265 Data truncated for column 'type' at row 1
Dokumentacijoje aiškiai parašyta, jog telpa iki 65535 skirtingų elementų, o tokia klaida sutampa su klaida, kuomet bandau įvesti neapibrėžtą enum'ą.
Kas per nesamonė?
Užklausoje yra updeitinami įvairūs laukeliai, taigi nėra ko iškelti. Kur rakinimo nereikia, naudoju myisam lentutes. Tai tada teks galvoti kaip įgyvendinti APP <-> MEMORY -> innoDB struktūrą
šiuo metu sukasi ant ubuntu 10.10 ir mysql 5.1.49.
UPDATE vienintelės užklausos kuriose HDD lemputė sumirkčioja.
Užklausos pavyzdys: UPDATE buildings SET `lastTime` = '1290676129' WHERE id = 363
Dar pastebėjau, kad užklausos laikas nepriklauso nuo to, ar eilutę yra užrakinama su SELECT .... FOR UPDATE ar ne
Bus updeitinama būtent buildings eilutė. Kadangi ji yra pagrindinė, o aplikacija yra žaidimas, tai užklausų kiekio mažinti nebegaliu.
Beje, googlėje šia tema klausimų pilna, bet niekas nepaaiškino ką tai reiškia, ir kaip tai būtų galima spręsti.
Daugiau dėl pačio update, tai:
a) visada updeitinama tik pagal id, kuris yra primary
b) vienitelis indeksas yra id, kuris nesikeičia niekada (nebent yra įterpiami arba ištrinami įrašai)
c) iš esmės ryšiai neturėtų stabdyti, nes vienintelis ryšis yra pagal tą patį stulpelį id, kuris niekuomet nesikeičia.
Pats galvojau apjungti, bet nesugalvoju kaip reikėtų neskausmingai tai realizuoti programiniame kode.
Dar vienas pastebėjimas. Jeigu freeing items metu procesorius miega tas 65ms, tada nieko blogo, nes tuo metu CPU resursai tenka kitiems procesams, bet kaip tai patikrinti?
Beje, gal įžvelgsi kokį nors itin blogą nustatymą:
mysql> show variables like "%inno%";
+-----------------------------------------+------------------------+
| Variable_name | Value |
+-----------------------------------------+------------------------+
| have_innodb | YES |
| ignore_builtin_innodb | OFF |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 33554432 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_size | 268435456 |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
| innodb_doublewrite | ON |
| innodb_fast_shutdown | 1 |
| innodb_file_io_threads | 4 |
| innodb_file_per_table | OFF |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_flush_method | |
| innodb_force_recovery | 0 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 1048576 |
| innodb_log_file_size | 5242880 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_max_dirty_pages_pct | 90 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_open_files | 300 |
| innodb_rollback_on_timeout | OFF |
| innodb_stats_on_metadata | ON |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 20 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 8 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_legacy_cardinality_algorithm | ON |
+-----------------------------------------+------------------------+
37 rows in set (0.00 sec)Sveiki,
kuris laikas naudoju innoDB, tačiau pastebėjau kad joje yra lėtos update ir insert užklausos. Paėmiau profilį:
mysql> show profile for query 4;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000083 |
| checking permissions | 0.000009 |
| Opening tables | 0.000018 |
| System lock | 0.000004 |
| Table lock | 0.000005 |
| init | 0.000061 |
| Updating | 0.000094 |
| end | 0.000008 |
| query end | 0.000003 |
| freeing items | 0.065511 | <<-------
| logging slow query | 0.000011 |
| cleaning up | 0.000004 |
+----------------------+----------+
12 rows in set (0.00 sec)Pati lentelė:
CREATE TABLE `buildings` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`tid` int(10) unsigned NOT NULL,
`damage` tinyint(3) unsigned NOT NULL DEFAULT '100',
`guest` int(11) NOT NULL DEFAULT '0',
`cost` smallint(5) unsigned NOT NULL,
`builded` int(10) unsigned NOT NULL,
`on` tinyint(1) NOT NULL DEFAULT '1',
`lastTime` int(10) unsigned NOT NULL,
`x` int(11) NOT NULL,
`y` int(11) NOT NULL,
`size` tinyint(1) unsigned NOT NULL,
`static` tinyint(1) NOT NULL DEFAULT '0',
`use` tinyint(1) NOT NULL DEFAULT '1',
`type` enum('P','K','A','L') NOT NULL,
`pasitenkinimas` float unsigned NOT NULL DEFAULT '0',
`connected` tinyint(1) NOT NULL DEFAULT '0',
`hasWorkers` tinyint(1) NOT NULL DEFAULT '0',
`queue` smallint(5) unsigned NOT NULL DEFAULT '0',
`revenue` int(10) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=497 DEFAULT CHARSET=latin1Ji susieta per foregin keys su:
CREATE TABLE `zones` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`x` int(11) NOT NULL,
`y` int(11) NOT NULL,
`block` int(10) unsigned NOT NULL,
`pid` int(10) unsigned DEFAULT NULL,
`building` int(10) unsigned DEFAULT NULL,
`private` tinyint(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `coo` (`block`,`x`,`y`) USING BTREE,
KEY `pid` (`pid`),
KEY `building` (`building`),
KEY `block` (`block`),
CONSTRAINT `buildingas` FOREIGN KEY (`building`) REFERENCES `buildings` (`id`) ON DELETE SET NULL ON UPDATE CASCADE,
CONSTRAINT `parkas` FOREIGN KEY (`pid`) REFERENCES `parks` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=10435 DEFAULT CHARSET=latin1Bet kadangi tik per building.id, kuris niekada nesikeičia, tačiau pats įrašas gali būti ištrintas.
Visą reikalą stabdo tik tas free items. šitoje lentelėje yra ~1500 įrašų. Kai vykdomos update užklausos, matau kaip HDD lemputė mirkčioja. šita reiškmė nesikeičia išjungus arba įjungus kešą. Produkcinis serveris bus žymiai spartesnis (nes turės 4 SSD RAID masyvą) negu darbinis laptopas, tačiau turės atlaikyti bent 4 milijonus įrašų, ir ~20.000 update per sekundę vien tik šioje lentelėje.
Taigi gal galima kažką pamodifikuoti, kad optimizuoti šitą vietą. Turiu visišką laisvę keisti my.cnf nustatymus. Būtų gerai kad update užklausos būtų įvykdomos per trumpiau nei 1 ms (dabar yra ~65ms kurias užima vien tik tas freeing items);
Man asmeniškai atrodo taip:
1.Pradedant mokytis geriausiai susigalvoti vidutinio sudėtingumo tinklapį, kurį nori padaryti. Ne tokį, kurį darytum mokymosi tikslais, bet kuris ir šiaip manai būtų reikalingas, pateiktų įdomios informacijos ar pan. Užsiregistruoti kokiame nemokame "hostinge", kur palaiko PHP, SQL.
2.Tada skaityti knygą, kad suprastum kontekstą, esmę. Knygoje paeiliui būna viskas išdėstyta, lengva suprasti. Gerai pradžioj perskaityti įvadinius skyrius, o paskui atsiversti tuos, kurių prireiks. Beskaitant nuolat kurti / tobulinti savo tinklapį - taip susidursi su realiomis problemomis, ieškosi jų sprendimų knygoje, geriau tuos sprendimus įsidėmėsi.
3.Kai jau reikės kažkokių ypatingų, sudėtingų komandų - ieškoti informacijos internete, pvz. Google. Nepavykus rasti - paklausti forumuose.
Nieko rimto pradėti daryti tikrai neverta, nes paskui vistiek reikės perdaryti. Tiesiog kai neturi pakankamai patirties kurioje nors technologijoje, tai nesusiplanuosi normalios architektūros, ko pasekoje vistiek turėsi perrašyti, ir galbūt ne kartą.
Aš asmeniškai patarčiau mokytis programuoti, bent pora metų, pabandyti keletą kalbų (technologijų), o paskui jau griebti kažką konkretaus.
O kas tau ten patiko? (-;
Per paskutinius du metus buvo 2 darbo skelbimai (-; O prieš tai Microsoft konkursas.
bet dar prieš tai buvo įdomių straipsnių.
https://www.mokejimai.lt/mikro_mokejimu … a_SMS.html
Man asmeniškai reikėjo tik atsisiusti šitą biblioteką ir truputėlį pakeisti tikrinimo kodą. Likęs kodas veikia be problemų
centos 4 ar centos 5? Man ketvrita versija jau trečius metus be jokių lūžių sukasi
Radau klaidą. Kadangi pas mane on delete yra set null, tačiau `pid` int(10) unsigned NOT NULL, negali būti null. čia ir buvo klaida. Gal kam nors pravers mano patirtis :)
Tai kad visas serverio stabdis būna I/O, todėl kešavimas kaip tik turėtų vykti į atmintį. į diską kešuoti apsimoka nebent tik tai, kas yra labai ilgai generuojama. Vien sesijų perkėlimas į /dev/shm prideda performanco :)
Be to, manau kad kešavimas turi būti labai, todėl neįsivaizduoju, kam dar reikia lockų ir visokio kitokio mėšlo.
žiūrint koks dviratis. Nes aš labai abejoju ar verta bandyti rašyti dar vieną OS, office, skaičiuotuvo pakaitalą ir t.t. Poreikis susikurti savo dviratį dažniausiai kyla komerciniais tikslais, tuo tarpu, kai kuri savo malonumui, tai nori iš savo projekto susilaukti kuo daugiau dėmesio. Jei kursi eilinį skaičiuotuvą, tai gali būti tikras, kad jo niekas nenaudos ir abejoju ar sulauksi palaikymo. Bet jeigu kursi kažką unikalaus, kad ir skaičiuotuvas su unikaliu valdymu, tai kodėl gi ne :). Kurti dviračius mokymosi tikslais labai pravartu, nes yra galimybė palyginti savo variantą, be to, neturėdamas patirties, super duper projekto nesukursi.
Gražiai sužaidei su javascriptais :)
Tik nepastebėjau, ar galima rašyti tiesiog BBcodu? Bijau kad ant linux išvis neveiks WYSIWYG. O tokiu atveju html rašyti bus žiauriai nepatogu :)
LIetuvoje praktiskai niekas neturi perpektyvu, nes pirmiausia jei ir kazkas kazka bandys daryti kaip OpenSource, bus iskeiktas :) Dabar taip primeciau ir pagalvojau kiek % isp***votu toki projekta kaip tarkim Zend/CakePHP frameworko analogo kurima ar tarkim phpMyAdmin? Speju koks 95% tikrai Lietuvoj pirmiausia pasibaigtu manau tuo kad visi grazioj formoj parasytu kas igimta Lietuvio galvoj, o kitas dalykas niekas neprisidetu. Argi ne taip butu? Juk cia Lietuva, todel ir nera tu OpenSource projektu (o jei yra, tai zmones tyliai kuria savo sistemele su uzsaldytais nervais ir 0 reakcijos i aplinkinius), nes kai pagalvoju nuo ko prasidejo phpMyAdmin kurimas, ir taip primeciau ar butu susikures toks projektas jei viskas butu prasideje Lietuvoj. Speju 0% tikimybe.
Mano nuomone ;)
Pirmas dalykas, o kam kurti dviratį? Gal geriau prisidėti prie jau esamo projekto? Na aišku, jeigu gali sukurti kažką geresnio, tai kodėl gi ne. Ir abejoju ar Lietuviai labai jau išjuokia dėl opensource projektų. Kiek teko pastebėti, tai būtent, kad kas nors sukuria produktą, kuris nei funkcijomis, nei kokybe, nei išradingumu neprilygsta jau egzistuojantiems projektams, todėl kai kam atrodo keista, kam vargti prie nereikalingo dalyko? O apie dar neišrastų dviračių kūrimą tai tikrai esu girdėjęs palaikymą ir motyvaciją tam :)
Be to, mano nuomone, ar platinti savo produktą OS pavidalu turi spręsti pati įmonė. Tačiau neįsivaizduoju, koks tol kas kodą slėpti nuo klientų? Jeigu tiek įmonė, tiek klientas rimti žmonės (rimtos įmonės), tai jie tikrai nenorės užsiimti žaidimu.
Nesuprantu, kodėl meta klaidą 150 klaidą, ir nieko konkretesnio neparašo:
Bandau sukurti tokią lentelę:
CREATE TABLE `zones` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`x` INT NOT NULL,
`y` INT NOT NULL,
`pid` int(10) unsigned NOT NULL,
`building` int UNSIGNED NOT NULL,
PRIMARY KEY (`id`),
UNIQUE `coo`(`x`, `y`),
index `pid` (`pid`),
INDEX `building`(`building`),
CONSTRAINT `parkas` FOREIGN KEY `parkas` (`pid`)
REFERENCES `parks` (`id`)
ON DELETE SET NULL
ON UPDATE CASCADE
)
ENGINE = InnoDB;Kurios referencas yra:
CREATE TABLE `parks` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`title` varchar(32) NOT NULL,
`user` int(10) unsigned NOT NULL,
`x` int(10) unsigned NOT NULL,
`y` int(11) NOT NULL,
`money` bigint(20) unsigned NOT NULL,
`point` int(10) unsigned NOT NULL,
`created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`guest` int(10) unsigned NOT NULL DEFAULT '0',
`guestLocal` int(10) unsigned NOT NULL DEFAULT '0',
`guestRemote` int(10) unsigned NOT NULL DEFAULT '0',
`lastHit` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `title` (`title`),
UNIQUE KEY `cord` (`x`,`y`),
KEY `user` (`user`),
CONSTRAINT `new_fk_constraint` FOREIGN KEY (`user`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=36 DEFAULT CHARSET=utf8forumuose žmonės rašo, kad nesutampa foreign key ir referenco duomenų tipai. Ir dar skaičiau kažkur, kad tipo negalima sukurti lentelės, kurios referencinė lentelė jau turi kitą referencą.
Iš anksto ačiū.
O neišeina serviso nustatymuose nurodyti kad encodintų iškarto visą turinį GZIP? Bent nginx'e tai puikiai veikia.
minde wrote:zygis wrote:jega, reiks vds pasiimti. o beje cia galioja ir pratesimui?
Pratesimui negalioja. Tik naujom paslaugom.
Na dabar kiek jau tenka matyti tai pratesimui irgi galioja ta pati nuolaida. T.y. užsisakę su tam tikra nuolaidą, ją turėsite ir pratęsdami paslaugą.
Arba galima pasireguliuoti mokėjimo terminą ir nuolaidą.
PHP ir MySQL → Posts by neworld
Powered by PunBB, supported by Informer Technologies, Inc.