Aleksejs

Vairāki varianti nāk prātā: 1) Aizpildīt ar biežāk izmantojamajām vispirms un pārējās ielādēt tikai pēc īpašas vajadzības... Pēc statistikas raugoties no ~350 vērtībām vispieprasītākās būs ~70 (Pareto princips) 2) Sadalīt pa vairākiem DropDowniem, kur nākošais tiek aizpildīts tikai pēc iepriekšējā izvēles -> kategorizēšana. Patiesībā - jautājums ir: kā šīs 2 sekundes sadalās? Cik ilgu laiku notiek datu atlase uz servera, cik ilgā laikā notiek pārsūtīšana no servera uz pārlūku un cik ilgā laikā notiek attēlošana/renderēšana pārlūkā. Jāskatās, kur ir lielākā aizture un ar tās samazināšanu ir jāsāk. Uz servera jāpārbauda, vai ir optimāls SQL/datu ieguves pieprasījums, pa tīklu - vai nevajag kompresēt datus, pārlūkā - vai nevar izmantot ne tik resursprasīgu renderēšanu. Īsāk sakot - jāzina vairāk par tā dropDowna saturu un izcelsmi un turpmāko izmantojumu. Varbūt var neizmantot dropdownu, bet gan ar AJAXu būvēts auto-complete būs efektīvāks.

Vaina ir tajā, ka Tu nesaproti, ko dari un nemaz necenties saprast.

Apskatīsim "iepriekšējā ieraksta" gadījumu: tātad mūs interesē vai nu nākošais mazākais id, šajā datumā, kas nepārsniedz pašreizējo: (datums = XXX AND id IN ( SELECT max(id) FROM documents AS d2 WHERE d2.datums = d1.datums AND d2.id < YY ) ) vai arī maksimāli pieejamais id lielākajam datumam, kas nepārsniedz pašreizējo: ( id IN ( SELECT MAX(id) FROM documents AS d4 WHERE datums IN (SELECT MAX(datums) FROM documents WHERE datums < XXX) ) ) Un tātad to visu apvienojot mēs iegūstam šādu SQL: SELECT name FROM documents WHERE (datums = XXX AND id IN ( SELECT max(id) FROM documents AS d2 WHERE d2.datums = d1.datums AND d2.id < YY ) ) OR ( id IN ( SELECT MAX(id) FROM documents AS d4 WHERE datums IN (SELECT MAX(datums) FROM documents WHERE datums < XXX) ) ) ORDER BY datums DESC, id DESC LIMIT 1 Protams, šāds SQLs nebūtu vajadzīgs, jakopā ar pašreizējo lapu būtu padevis līdzi arī marķieri, kas satur ciparu, kurš ieraksts pēc kārtas šajā rezultātā ir tas, kas tiek rādīts, jo tad varētu iztikt ar vienkāršu: LIMIT x+1,1 vai LIMIT x-1,1 (kur x ir pašreizējā ieraksta kārtas numurs rezultātā). Edit: Nedaudz padomāju un šķiet to pašu dara daudz vienkāršākais: SELECT name FROM documents WHERE (datums = XXX AND id < YYY) OR datums < XXX ORDER BY datums DESC, id DESC

Un kā Tev šķiet, ko tas nozīmē un kā no tā izvairīties? :)

Ja saproti angļu valodu, tad silti iesaku lēnā garā izlasīt cauri šo materiālu: http://www.sitepoint.com/article/publishing-mysql-data-web/

DELETE FROM tabula WHERE id IN (1,2,3,5,7)

Domāju, ka 1x stundā noteikti drīkst.

Ir vēl http://www.sqlbuddy.com/, ja nu phpMyAdmin dikti nepatīk.

Autoram, cik saprotu rupji runājot vajag web-veikalu. Jā, visus interfeisa knibuļus var lasīt iekšā ar gettext/failiem/utt, jo tie laika gaitā nemainās, bet ko darīt ar preču nosaukumiem aprakstiem utt? Lūk šīs problēmas risināšana, cik saprotu, tad arī autoru interesē. Neglabāt taču preču katalogu gettext failā ;)

Klez, iedeva norādi uz apskatu/sarakstu par 9 OpenSource eKomerces risinājumiem: 9 kick ass Open source E-commerce platforms reviewed Minēti šādi risinājumi: OsCommerce ZenCart VirtueMart Magento DashCommerce - nav PHP, bet gan .NET CubeCart X-Cart - nav Bezmaksas LiteCommerce Shopify - nav PHP, bet gan RoR

Problēma ir nevis iztulkot interfeisa elementus "Produkta apraksts: " uz "Product description: ", bet gan produktus "Tējkanna zaļa 2l" uz "Teapot green 2l". :)

google translate nav nopietni. Kā piemērs - šodien pienākušais spams:

Nu, ķēpa ar insert/update ne lielāka kā jebkurā citā dalītajā variantā.

Ā, nu ja :) Kaut kā aizmirsu, ko rakstīji sākumā. ;) Vēl viena ideja... Atstājam unificētu tabulu translations, bet paredzam (galu galā mēs taču zinam, kādas būs tabulas un cik tajās būs tulkojamo lauku) maksimālo tulkojamo lauku skaitu, kāds pieejams jebkurā no tabulām (pieņemsim, ka pēc mūsu projekta analīzes esam sapratuši, ka būs ne vairāk par 5 tulkojamajiem laukiem). Un tad aplikācijas loģikā iestrādājam (ja nu kas, varam izveidot Viewus un procedūras, kas to izpilda, lai pašā PHP kodā tas nav jādefinē), ka tabulai produkti laukā lauks1 galabājas nosaukums, lauks2 glabājas apraksts, lauks3 glabājas saturs; savukārt tabulai piegadataji (nu, piemēram) laukā lauks1 glabājas adrese, lauks2 glabājas uzņēmuma nodarbošanās apraksts utt. tabula tulkojumi: tabulas_id,ieraksta_id,valodas_id lauks1, lauks2, lauks3, lauks4, lauks5. tālāk atlasi veicam tāpat kā 3 variantā un esam ieguvuši to, ka tulkojumi glabājas vienā +- unificētā tabulā. Ja nu izrādās, ka ar tiem 5 laukiem nepietiek, tad attiecīgi jāliek klāt kārtējais lauks, kura pielikšanai nevajadzētu ietekmēt neko. Vieta gan nedaudz tiek nelietderīgi izmantota, taču zinot, ka tukšs text lauks tāpat īpaši daudz neaizņem, šāda izšķērdība varētu būt attaisnojama. Skatoties no Datu uzbūves viedokļa - šis nav elegants risinājums, taču iegūta ir ātrdarbība.

Nu vēl viens veids, kas varētu būt kā kompromiss... Pieņemsim atkal, ka vajag tabulu produkti: Nemainīgās lietas: id,artikuls,ean_kods,cena Tulkojamās lietas: nosaukums,apraksts,saturs Tad varam izveidot tabulu: produkti_stat ar laukiem: id,artikuls,ean_kods,cena un attiecīgi tik daudz, cik nepieciešams tabulas: produkti_XX (kur XX=lv,ru,en,de,jp,kr,cn ...) ar laukiem: product_id,nosaukums,apraksts,saturs Tādā gadījumā atlases SQLs būs vienkāršāks un gana ātrs, nekā vienas tulkojamās tabulas gadījumā: SELECT * FROM produkti_stat LEFT JOIN produkti_lv ON produkti_stat.id = produkti_lv.product_id WHERE produkti_stat.id = 8 Plusi tādi, ka: - nav simtiem lauku un produkti_XX tiek veidoti pēc vienota šablona. - vieta uz diska tieši saistīta ar to, cik daudz iztulkots - netiek veidotas tukšās šūnas... Laikam varchar,text utt. gadījumā šis nav īpašs arguments, jo tie tāpat aizņem minimālu vietu, ja nav aizpildīti.

Tev ir visas iespējas uzrakstīt šādu analīzi - feci quod potui faciant meliora potentes ;) Šo tēmu uzsāku ar domu, ka šeit varētu mest iekšā norādes tieši uz šādām atrastajām/izveidotajām analītiskajām publikācijām.

Manā pieredzē pagaidām nav bijusi nepieciešamība lietot kādu frameworku, jo viss ko esmu taisījis ir ļoti vienkāršs pēc savas būtības, kam īsti neatmaksājas izmantot frameworku. Taču interese par šo lietu ir un ik pa brīdim pasekoju līdzi to attīstībai.

Nu, visumā glabājot vienā tabulā to visu ir ātruma ieguvums (pieņemsim, ka jāatlasa 4 lauki: id, nosaukums, apraksts, saturs), jo: SELECT id, nosaukums_lv AS nosaukums, apraksts_lv AS apraksts, saturs_lv AS saturs FROM produkti WHERE id = 8 manuprāt izpildās ātrāk nekā: SELECT p.id AS id, t1.translation AS nosaukums, t2.translation AS apraksts, t3.translation AS saturs FROM produkti AS p LEFT JOIN tulkojumi AS t1 ON p.id = t1.id LEFT JOIN tulkojumi AS t2 ON p.id = t2.id LEFT JOIN tulkojumi AS t3 ON p.id = t3.id WHERE p.id = 8 AND t1.tabulas_id = 7 AND t2.tabulas_id = 7 AND t3.tabulas_id = 7 AND t1.lang = 1 AND t2.lang = 1 AND t3.lang = 1 t1.lauka_id = 1 AND t2.lauka_id = 2 AND t3.lauka_id = 3 Piezīmes: Pieņemsim, ka produktu tabulai ir tabulas_id = 7, latviešu valodai lang = 1 un attiecīgi laukiem - nosaukums, apraksts, saturs - ir id: "1,2,3". Līdz ar to jāizvērtē, kādas lietas ir svarīgākas.

16 PHP Frameworks To Consider For Your Next Project Pirmās rindkopas tulkojums: Ir ļoti īsi apskatīti: Agavi Akelos CakePHP CodeIgniter eZ Components Fuse Horde Kohana PHP on Trax PHPOpenBiz Qcubed Seagull Symphpony WACT Zend ZooP

Vēl apskaties, vai nav kaut kas no šiem iemesliem: http://php.lv/f/index.php?showtopic=10684&view=findpost&p=85173

Nav normāls nosaukums!

Nu, kā vēlies... 1. Uzraksti izsmeļošāku nosaukumu!

1. Uzraksti izsmeļošāku nosaukumu! 2. Kļūdas paziņojumā ir atbilde uz Tavu jautājumu. Hostētājs ir aizliedzis funkcijas shell_exec() izmantošanu drošības apsvērumu dēļ. Kontaktējies ar hostētāju, lai atļauj Pārraksti skriptu, lai nebūtu vajadzība pēc shell_exec() Maini pret tādu hostētāju, kas ļauj

Lūk ir PHP sadaļa: http://php.lv/f/forum/17-php/

Bet tev tač jau ir saformēts korekts CSV... Vienkārši ar fwrite raksti pa rindai iekšā. Vai arī ar implode tās apvieno, kā atdalītāju ieliekot \n Bez tam... masīvā tev viss atdalīts ar semikoliem, bet splito Tu pēc komata, tādēļ arī fputcsv katru reizi saņem masīvu no 1 elementa, kuru tad arī paklausīgi ieliek pēdiņās. Bet tik vienkāršus datus varēji arī ar explode funkciju pārtaisīt par masīvu.