Nedaudz par jauno Apollo portālu

120 komentāri

ApolloPar Apollo portāla jauno seju jau daudzi paspēja izteikties komentāros. Neliekuļošu un atzīšos, ka to ziņu nopublicēju speciāli tik ātri, prakstiski pāris minūtes pēc paša portāla atvēršanas, lai tauta varētu izteikties par Apollo veikumu.

Jau iepriekš bija zināms, ka pēc tik lielas ažiotāžas, kāda bija izveidota ap Otru pusi, tas viss nevarēja tik mierīgi beigties. Vēl jo vairāk, aizkulisēs jau cilvēki smīkņāja par to, ka Apollo paši saviem spēkiem mēģināja uztaisīt portālu no nulles. Ja jums ir kāds pazīstams speciālists, kas nodarbojas ar šāda tipa projektu izstrādi, tad pajautājiet viņam, ko viņš domā par šo lietu – cik viegli vai grūti ir izveidot nopietnu portālu no nulles, kas paredzēts lielām slodzēm un kādi speciālisti to spēs paveikt.

Neņemšos spriest par Apollo speciālistu profesionalitāti. Redzot to visu nepilnību sarakstu, kas uzpeldēja komentāros un joprojām uzpeld tīklā, apstiprināja aizdomas, ka portāls ir tapis sasteigts. Pēdējais hīts, ko šorīt ieraudzīju komentāros bija iespēja ievietot komentāru no ārējas lapas un parakstoties ar jebkuru sev vēlamu reģistrēta lietotāja niku.

Otra puse

Protams, var teikt, ka tas ir bērnišķīgi utt. utjp., bet jebkurā gadījumā tas nav nopietni, ka tik vienkārši var apiet šo reģistrācijas sistēmu. Kāda, tad jēga no tādas reģistrācijas sistēmas?

Nedomāju, ka šajā gadījumā vajadzētu vainot tikai tos nabaga programmētājus, kas pēdējās nedēļas programmēja šo portālu. Man nez kāpēc šķiet, ka kāds tur “no augšas” izdomāja, ka Apollo vajag jaunu portālu. Tika noteikta dzer… atklāšanas diena, pasākums tika aktīvi izreklamēts un beigās atjēdzās, ka aizmirsuši vienu mazsvarīgu lietu – pats portāls vēl nemaz nav gatavs. Tad nu pēdējās nedēļās situāciju mēģināja glābt pāris programmētāji. Varbūt, ka tā nav, bet vismaz man radās tāds priekšstats…

Kā jau iepriekš izteicos, uzskatu, ka daudz progresīvāk būtu bijis, ja Apollo savā jaunajā dizainā būtu izmantojuši CSS iespējas un pilnībā aizmirstu par veco un kroplīgo HTML tabulu dizainu. Veco versiju tāpat nevarēja pārlūkot ar antīkiem pārlūkiem, piemērām, Netscape 4.x vienkārši nomira vai ielādēja tikai lapas galvu. Tad kāda jēga pēkšņi sākt atbalstīt mirušus pārlūkus, ja to lietotāju skaits ik dienas sarūk?

Es saprotu, ka daudzi no jums tagad bola acis un nesaprot par ko es te runāju. Kas tas par CSS un tādā garā. Tā kā man nav nedz laika, nedz arī vēlmes ņemties un analizēt Apollo portālu un labot kļūdas, tad to arī nedarīšu, bet par laimi līdzīgi domā arī citi cilvēki. Jāzeps ir viens no viņiem. Viņš savā blogā ir izteicis savas domas par jauno portālu. Bet tas nav viss, jo viņš ir gājis tālāk un atvēlējis laiku, lai realizētu dzīvē portāla dizaina prototipu.

Pēc maniem mērījumiem 54,3KB pretīga HTML koda pārtapa skaistā 22,7KB XHTML + 3.5KB CSS kombinācijā. Mans Apollo.lv variants nav līdz galam pabeigts, jo šodien vairs tam nevaru veltīt laiku. Pievienojot CSS, kas šobrīd iztrūkst, lai variants līdzinātos pašreizējam Apollo.lv, kopā sanāks ap 10KB CSS + 23KB XHTML, kas kopā veido 33KB mūsdienīga, elastīga un pārskatāma koda iepriekšējo 54,3KB murgu vietā.

Gandrīz uz pusi tiek ieekonomēts tikai uz pirmo lapu. Rēķiniet, ka 10KiB CSS fails tiek saglabāts pagaidu atmiņā un tas vairs netiek ielādēts no servera apmeklējot citas lapas, tad uz pārējām lapām sanāk vēl lielāka ekonomija. Es nemaz nepieminu tās priekšrocības, kas parādās izmantojot CSS elastību. Apollo varētu katru dienu mainīt jaunu dizainu, noalgojot kādu studentu, kas pāris stundas dienā paspēlētos ar stiliem. Vērtējiet paši. Lapa ielādēsies vienlīdz ātri ar jebkuru pārlūku. Vienīgi uz Netscape 4.x tā tiks attēlota vienkāršā tekstā, bet vai tas kādu uztrauc? Netscape jau ir pagājušā gadu tūkstoša pārlūks, kas pie tam vēl ir miris…

Un vēl. Tas, ka šis prototips neizskatās 1:1 kā Apollo oriģināls nenozīmē, ka uz CSS to nevar realizēt. Vienkārši tas prasa laiku, lai pieslīpētu katru pikseli, kas šajā gadījumā nevienam nav vajadzīgs.

Pēc kāda brīža mēģināšu nopublicēt vēl viena cilvēka pārdomas par šo portālu.

120 thoughts on “Nedaudz par jauno Apollo portālu”

  1. aabele

    iisteniibaa ir veerts aizsuutiit linku uz sho lapu kaadam no Apollo bosiem – man liekas ka kaads no apollo tehniskaas daljas lidotu 🙂

    Atbildēt ↓
  4. coolynx

    Budzis: nezinu, kas bija domaats ar “gatavu produktu”, bet precizeeshu, ka xhtml ir tas pats html ar paaris nianseem, bet to atteelos vienliidz labi visi shobriid apgroziibaa esoshie paarluuki. probleemas antikvariaatam rodas tieshi ar css atbalstu. visaadi citaadi nav starpiibas vai tiek izmantots html, vai xhtml.

    Atbildēt ↓
  5. K

    Nav jau obligaati visiem jadzied un jaataisa lapas kaa aol.com 🙂 Aol tachu gigants 😉 Klientu vien paari pa 30,000,000 🙂
    Tad jau butu uzreiz labaak redirekteet uz aol.com un miers 🙂

    Atbildēt ↓
  6. juris

    nezinu vai buutu korekti vainot koderus, ja vini parasti dara to ko viniem liek, ja vinam liek uztaisiit komentus 2 dienaas nu vinc nemaas un taisa (protams ir lietas kas nav padariitas ;)) bet IT vadiiba saka tas OK, nu ko juus koderu vietaa dariitu (ietu pa maktiim straadaatu vai vakaraa iedzertu alinju??)
    domaaju ka koderi paarsvaraa ir taadi pashi kaa citur bet tam LTK ir taads paradums visu sataisiit taa ne iipashi labu ar glukiem…

    Atbildēt ↓
  9. coolynx

    juuzeris: kaut ko varbuut arii zinu. man bija taa iespeeja pabuut otras puses atklaashanaa un parunaat ar cilveekiem, kas netieshi piedaliijaas projekta izstraadee. taa kaa kaut kas no visa teiktaa arii var atbilst patiesibai un nav gluzhi mans izdomu auglis 🙂

    Atbildēt ↓
  11. aabele

    starp citu coolynx vai tu gaidi kameer kaads tavas lapas dizainu taisiis uz xhtml ko? Sheit nu galiigi nevajadzeeja buut nekaadaam probleemaam

    Atbildēt ↓
  12. jnk

    hmm, palasot jaazepa lapu, liekas ka vieniigais ar ko var izcelties portaals, ir tehnologjijas, uz kuru baazes tas ir radiits. manupraat tomeer tas ir SATURS, kas interesee 95% no NORMAALIEM cilveekiem, nevis trakos datorfriikus (pac esmu viens no tiem). luuk, shie 95% nezin pat kas ir html, kur nu veel xhtml vai css.
    P.S. tas ir mans personiskais viedoklis, un sagaidu datorfriiku uzbraucienus

    Atbildēt ↓
  13. Djuke

    to jnk: ne tikai saturs interesee, vienkaarshos datorlietotaajus interesee arii satura pasniegshanas kvalitaate…
    piemeeram, es kaukaa reiz draudzenei pavaicaaju, kapee vinja neskataas apollo, un vinja teica ka nepatiikot dizains (viss uz kreiso pusi sagaazies) un nepatiikot arii (ljoti) aatrums… taa vietaa vinja izveelas tvnet… jo arii tur ir saturs…
    nu nezkaadam tad superduper saturam jaabuut lai es buutu ar mieru gaidiit to laiku kas man jaagaida tagad skirstot apollo…

    Atbildēt ↓
  14. AndrisXXX

    jnk: Bet vai tad tie “NORMAALIE cilveeki” nepriecaatos, ja apollo portaals ielaadeetos raitaak, mazaak gljukotu un buutu vizuaali pievilciigaaks – taadejaadi paliidzot labaak uztvert saturu?

    Atbildēt ↓
  15. aabele

    nee nu mashiina var protams izcelties ar jaudiigu motoru, bet var arii vienkaarshi plastmasas spoileri aizmuguree pielikt :)(

    Atbildēt ↓
  16. jnk

    hmm, neesu meegjinaajis uz leenaaka piesleeguma, varbuut tieshaam bremzee?
    bet ja par dizainu sauc to, ka viss ir uz “kreiso pusi sagaazies” … hmhm…

    Atbildēt ↓
  17. Kaklz

    jnk: te jau runa bija par pasha apollo ieguvumiem – visas iespeejas gan samazinaat servera slodzi, gan arii trafiku, kas taada apjoma portaalam vareetu buut visai svariigi.

    Atbildēt ↓
  19. bush

    cik jums visiem gruuti. zheel juusu. a es eju uz apollo, lasu, priecaajos un man ir labi. bet juus te kuupat aiz savaam fetishisma izpausmeem. buu.

    Atbildēt ↓
  20. aabele

    nu protams bush kaa vienmeer topaa. MS 6.0 labaakais paarluuks u.t.t. Klausies vai tik tu gaisho misionaaru draudzee neesi iestaajies ko? tuuliit veel saaks staastiit ka pederasti arii ir cilveeki…

    Atbildēt ↓
  22. Droom

    Man ka pilnigam lamerim ir gluzi pie kajas vai tur html vai notepad vai vel kas cits. Apollo ir labs info zinja, bet BESI ara ar lenumu, ipasi, ja gribas kadu jaunumu palasit no PALM. 2 min. lade vienu un to pashu un beigas piemet to ko velejos. Shausmigi cereju, ka viss bus atraks, bet neka. Zel! Dizains, hmm, pie visa pierod, tikai gaumes jautajiens. Secinajums – kada jega bija ko mainit, ja palicis ir tas viss vel lenaks un vel jokaina registracija?!

    Atbildēt ↓
  23. e-remit

    Vispār jau lapas otrapuse.lv, kamēr vēl skaitītājs gāja, bija atkomentēts vits datums. Laikam atklāšana pa kādu mēnesi bija atlikta.

    Atbildēt ↓
  25. Grrr

    ok, tas nav pat par TABLE/CSS vai ko citu, bet mani konkrēti besī lieta, kas ir ne tikai apollo:
    http://journal.bad.lv/talkread.bml?journal=grrr&itemid=32117

    Atbildēt ↓
  26. xxx2

    Es vēl varu piebilst ka ātrums ir ļoti, ļoti svarīgs…
    Uz lēna pieslēguma nevar sagadīt, kamēr tas apollo atvērsies…..

    Atbildēt ↓
  27. endrju

    Nez kāpēc ‘noisex’ vienmēr komentē tikai tad, kad ir kaut kas labs par *.apollo.lv vai neizzināts, bet kad apollo tiek gānīts, tad komentāru nav… hmm.

    Atbildēt ↓
  28. Pow

    cien. jaazeps laikam ir cilveeks omtimizators. nez kaa veel nepierakstiija, ka veel baitus vareetu ietaupiit nelietojot CR un LF, bet visu lapas kodu sarakstot vienaa rindinjaa 🙂
    ne jau tie paaris KB dod lapai to ielaadeeshanaas BOOSTu. domaaju ka trubas jamiem ir plashas un baitus izgruust var daudz. vienkaarshi serveriishi ir leeni un to lapu gjenereejot ar php (/whatever) un db querijiem tie resursi arii tiek panjemti. vareeja tak ielietot keshoshanu, jeb kaa tagad moderni saka akseleratoru.

    Atbildēt ↓
  31. daysleeper

    tak nedrikst ljaut shitaa mocities portalam. butu apvienojushi visus kopaa lielakos 🙂 rofl . Nja – shodien MDSL riktigi gljuko – no rita bija down 10kb un augshaa gaja ar 72 🙂 tad arzemes nevareja sataustit un bija ari galigi diskonekti. fui LTK.

    Atbildēt ↓
  32. Di Benz

    Nja dzelzjiem jamiem bija toch zheel naudas. :((
    Buutu labaak paartija pikji ieguldiijushi jamos, nu vai arii labu briidi ar optimizeeshanu padarbojushies.
    Bet nu life sucks – un man godiigi sakot po. Ne es lasu ne kaa.
    Ak jaa kaut kaada keshoshana jamiem tomeer ir itkaa iesleegta.

    Atbildēt ↓
  33. ZBH

    2 Di Benz : driizaak labaak jau optimizeesanai peso vaig dot. un laik. a to parast preteejaa gadiijumaa dzelz par to pas peso situaacij neglaabj.
    btw, kaad viniem vareet buut noslodz piikj stundaas? un uz kaads hw tas viss griezs?

    Atbildēt ↓
  34. ZBH

    btw, vai portaal praksee logfail tiek rakstiit uz tiem pasiem fiziskajiem diskiem, no kuriem tiek vaakt dat (ne jau obligaat SQL baazs, bet nu vis tie css un php)?

    Atbildēt ↓
  35. ui

    spriezhot pec UDSL probkam, pik stundas ir no rita un vakaros
    itka jau “optimali” skaitijaas htdocs diskam ielikt opciju, lai neraksta failiem access taimu, lai read operacijas butu parsvara

    Atbildēt ↓
  36. Budzis

    Nu nekas iipashs jaunais apollp nav ne dizaina, ne satura zinjaa. Dizains ir gaumes lieta, bet saturaa ipashi audzis arii nav ;/

    Atbildēt ↓
  37. Jakie

    Man patīk tagadējais Apollo, līdz šim lasīju tikai TVNET, tagad atrodu noderīgas lietas arī apollo portālā. Cik noprotu tās tur ir bijušas visu laiku, taču tagad kļuva skatāmākas un man tas patīk. laiks Delfiem mainīties, jo noturēt pirmo pozīciju šādā konkurencē nebūs viegli – laiks iet, lasītājs (šajā gadījumā es) kļūst prasīgāks.

    Atbildēt ↓
  38. Mis_Alise

    Njemot veeraa to, kaads bija traadi riidi ap to visu, atverot to nabaga apollo, mani paarnjeema taac kaa “un tas ir viss?” staavoklis…

    Atbildēt ↓
  46. :))

    Grupa OTRA PUSE pçkðòi atteicâs spçlçt ðîgada “Bildçs”, jo (pçc paða solista Normunda Pauniòa domâm) tur uzstâdîtâ aparatûra nespçj nodroðinât vajadzîgo skaòas tehnisko kvalitâti- lîdz ar to paði jutîðoties vainîgi…
    Pie visa vainiiga aparatuura arii shoreiz… :))))

    Atbildēt ↓
  47. zb

    hmm, lasot visus shos komentaarus neviljus rodas jautaajums: un ko tad pashi shie visi hipermudrie ir uztaisiijushi? varbuut iemetiet kaadus linkus, lai redzam (gribas saliidzinaat ar tiem “sliktajiem” projektiem – oto.lv utml)

    Atbildēt ↓
  48. gach

    apollo toch ir malachi ielogojoties @e-apollo notiek redirekts uz http://80.232.168.213:8100… varbut vel vareeja 1337 portu uzlikt … sezhot aiz firewall kur valja tikai well known porti pie emaila netikt 🙁

    Atbildēt ↓
  49. StarRider

    2 Noisex: acceleratori nepalielinaas lapas iepluudi tavaa datoraa caur tavu 14,4kbaud modemu. Tie tikai samazinaas latenci (aizturi), kas rodas, apstraadaajot tavu query uz servera.
    2 Ev’ry1: kaapeec gan jamie izmanto mysql? skaidrs, ka jaalieto postgre

    Atbildēt ↓
  51. DW

    IMHO MySQL ir manaami aatraaks par PostgreSQL. Aatrumu MySQL ieguust “naherizeejot” visas super-duper fiichas, kuras “eed laiku”.

    Atbildēt ↓
  53. coolynx

    vakar tieshi sanaca palasiit phpbuilder.com saliidzinaats mysql un postgresql. tiesa tas ir 2000 gads. neko jaunu tur nevareeja uzzinaat, tikai paarliecinaajos kaarteejo reizi, ka mysql ir aatraaks un nestabilaaks uz lielaam slodzeem, bet postgresql ir stabilaaks ar lielaakaam iespeejaam un paredzeets nopietnaakiem projektiem, bet arii leenaaks.
    varbuut kaadam ir kaads jaunaaks saliidzinaajums pa rokai?

    Atbildēt ↓
  54. Lupus

    par PostgreSQL un MySQL principā salīdzināji pareizi, tikai no 2000 gada PostgreSQL uz vietas nav stāvējis un tagad ir dikti uzlabojies. Galvenais kas būtu jāņem vērā ir tas ka PostgreSQL ļauj vairāk lietas paveikt uz paša db servera, tādejādi ietaupot trubas laiku. A ja godīgi – gaumes lieta. Ātrumos jau liela atšķirība nav, atšķiras tikai speciālistu pieejamība un stabilitāte.

    Atbildēt ↓
  55. v00d00

    1) komentus citus lasījis es neir, so sorre ja iznāk atkārtot augstāk teikto..
    2) Main point – cik zinu apollo viens no vadošajiem programmeriem bijis laacz, so publiski gribētos pažēlot viņu + gribētos pateikt ka vot tā lūk gadās kad kauko dara bez darba plāna….

    Atbildēt ↓
  56. v00d00

    Ā, vēlviena lieta ir tā ka arī teksti jaunajam portālam darakstīti toč nav + paredzēts jamo cik zināms bija laist tikai kaukad pirmdienā (cik atceros jamo palaida jau 5dien..)

    Atbildēt ↓
  57. Djuke

    no viena foruma
    If 98% is sucking data – MySQL is the best solution – Has transaction logs
    to replay backup databases.
    MySQL – 1400% not a typo 1400% – faster than Oracle.
    If you want a solution for general data entry, integrity, more generalised
    system, transaction support and a little more robust system – PostgreSQL is
    the best solution.
    nu manupraat portaaliem jau tieshi ir tas 98% un mysql ir tieshi tam piemeerots…

    Atbildēt ↓
  58. coolynx

    v00d00: otras puses atklaashanas pasaakumaa laacz man paraadiija to cilveeku, kas bija vadoshais programmeetaajs. nedomaaju, ka vinjsh man buutu samelojis…

    Atbildēt ↓
  59. Delerium

    Interesanti, vai tikai MySQL izmantošana nav par iemeslu tam, ka vienā lapā vienam un tam pašam rakstam rāda dažādu komentāru skaitu? Vienā gadījumā links ir zem virsraksta Lasītākie raksti un blakus komentāru skaits rādās kā [51], bet zem virsraksta Viedoklis tam pašam rakstam komentāru skaits ir [50] …
    Viņi laikam sinhronizē ierakstus dažādā tabulās ar roku vai ar kādu batch jobu, jo nevar vai negrib realizēt normālas relācijas (kuras jau portāliem nevajagot, vai ne???) …
    P.S. Ok, pēc 5 minūtēm laikam sinhronizācija ir beigusies, jo komentāru skaits ir vienāds 🙂 Pirms tam ar refresh spaidīšanu nekas nemainījā.

    Atbildēt ↓
  61. Delerium

    to Djuke:
    Ja reiz gribi pamatot savu domu ar faktiem, tad norādi arī linku, kur ņēmi informāciju. “No vien foruma” pasaka tikai to, ka tas tiklab varētu būt anonīmo onanētāju forums kā normāls profesionāļu forums.
    Tāpat vajadzētu arī piebilst, pateicoties kam MySQL un kādās operācijās ir tik ātrs.

    Atbildēt ↓
  63. Djuke

    Delerium: aber luudzu
    http://archives.postgresql.org/pgsql-novice/2002-01/msg00021.p hp
    es gan neiebraucu Tavaa fishka par tiem forumiem, varbuut arii esi onaneetaaju forumos redzeejis apspriezham teemas par mysql un postgresu – es pa taadiem nemeedzu staigaat
    a kapee aatrs – tapee ka nav fiechu. jo universaalaaka sisteema ar vairak fiechaam, jo leenaak straadaa (pienjemot ka programmieri vienaadi kvalitatiivi straadaa). mysqls ir optimizeets tieshi prieks daudzi selektiem un maz insertiem updeitiem… kas manupraat ir portaala gadiijums

    Atbildēt ↓
  65. Delerium

    Djuke, kamēr nenorādi, kurā forumā ņēmi info, ir grūti spriest par to, cik objektīva ir informācija. Microsoft forumos droši vien ir info, ka Access ir daudz labāks par MySQL.
    Tas, ka MySQL ir optimizēts priekš daudziem selectiem, pilnībā piekrītu – ja normālā DBVS’ā (kaut vai Postgres’ā) daudzas lietas var izselektēt ar vienu select, tad MySQL bieži vien tam vajag 3 select’us un vēl 5 PHP koda rindiņas 🙂 Tas arī ir par iemeslu tam, ka web izstrādātāji reti kad māk uzrakstīt normālus select’us – iecienītā DBVS saprot tikai primitīvus pieprasījumus.

    Atbildēt ↓
  66. Kaklz

    Delerium, pilniigi pieljauju, ka tevis aprakstiitais gljuks ar viena raksta komentaaru skaita atshkjiriibaam ir izskaidrojams ar keshoshanu – atsevishkjaam lapas daljaam ir atshkjiriigs keshoshanas laiks .. teiksim lasiitaako rakstu modulis vareetu tikt keshots biezhaak/retaak nekaa paareejais .. un viss .. par relaacijaam domaaju, ka vari arii nesatraukties.

    Atbildēt ↓
  67. Djuke

    tas ka veb developeri nemaak rakstiit selektus tas ir tiesa (nu protams ne visi taadi).
    bet nu ko tad vajag portaalam… ko var posgresaa un nevar mysql un kas buutu tik nepiecieshams portaalam… var tachu atselekteet no vairaakaam tableem, sajoinot kopaa peec kaada lauka, indexus uzlikt var… ko tad iipashi vairaak vajag.
    nevareeshu iedot linku, bet varu teikt ka tajaa pashaa postgres lapaa reiz lasiiju, ka mysql principaa ir ljot labs ja vajag uzskaitiit smilshu graudinjus pludmalee – sak lieliem datu daudzumiem, bet nekaadas superduper fiechas

    Atbildēt ↓
  68. Delerium

    Kaklz, es jau arī nesatraucos, tikai pieminu 🙂 Bet interesanti, kādēļ netiek kešotas galvenās lapas kā viens vesels ?

    Atbildēt ↓
  69. Djuke

    Delerium: mosh taadeelj ka biezhi mainaas. jo jaaatselektee dazhi jaunaakie ieraksti no katras kategorijas – biezhaak mainaas….

    Atbildēt ↓
  70. Delerium

    Djuke, tur jau tā lieta – smilšu graudiņu skaitīšanai MySQL ir diezgan labs, jo rezultātā būs viena tabula, no kuras tik vien vajadzēs kā iegūt galīgo skaitu. Un patiesībā arī tas nebūs svarīgi. Kam gan rūpēs, ja pazudīs un nebūs atjaunojami ieraksti par 12 smilšu graudiņiem? Domāju, ka nevienam.

    Atbildēt ↓
  71. Djuke

    Delerium: nu var jau arii straadaat ar vairaakam tabulaam sasienot peec kaada ida kopaa… nav jau tik traki ar to mysqlu. un kaapee lai ieraksti pazustu…
    un pat ja arii pazudiis kaadi ieraksti – kursh tad to pamaniis tajaa “forshajaa” apollo dizainaa 😀
    starp citu aatrdarbiiba taa tiiri neko peedeejaas dienaas

    Atbildēt ↓
  73. Djuke

    Esmu nedaudz strādājis ar MySQL un reizi pa reizei arī palīdzu izdomāt kādu selektu priekš MySQl, bet gandrīz vienmēr nākas secināt, ka, piemēram, Oracle DB to selectu var uztaisīt vienkāršāk.
    Bet par to rindiņu pazušanu – visādi gadās. Ikdienā mana atbildība ir uzturēt ap 20 dažāda izmēra bāzes (no pāris GB līdz daudz daudz GB) un es zinu, ka ja kas notiks (sabojāsies fails power failures vai citu iemeslu dēļ, lietotāji izdzēsīs ne to utt.), es vienmēr atgūšu visus datus, es vienmēr varēšu atgriezt visu bāzi atpakaļ laikā utt. Lietojot MySQL es nebūtu tik pārliecināts …

    Atbildēt ↓
  74. Delerium

    Sorry, iepriekšējasi posts ir mans, nevis Djuke … :”)
    Cannot establish database connection ! – laikam aukstais backups tiek taisīts :))

    Atbildēt ↓
  75. Djuke

    Delerium: mosh es neesmu saskaaries ar taadaam situaacijaam… viss jau var buut.
    kautkan es nedomaaju ka apollo gadiijumaa buutu baigaas drausmas ja arii kaads ieraksts pazustu, nav jau banka (backupus gan tomeer vajag).
    P.S. starp citu mans favoriits db lietaas ir firebirds (nejaukt ar mjazilaam u. c.)… mazs, funkcionaals un labi straadaa… un protams bezmaksas

    Atbildēt ↓
  76. Delerium

    Firebird nav sanācis lietot, bet tas principā ir atvasinājies no InterBase, ko ir sanācis lietot. Domājams, ka Firebird varētu būt viens no produktiem, ko arī es izvēlētos lietot, ja vajadzētu uzticamu, funkcionālu un bezmaksas DBVS.

    Atbildēt ↓
  77. hQuse

    gluzhi liidziigi ir ar forum cinema. atklaats ir, cilveeki pastaigaajas, bet nedakraasotas vietas, shpakteleejumi, vadu gali visapkaart, kur tik vien paskataas. arii fasaadi veeljoprojaam remontee… no seerijas – viena tante teica – taa eeka ir tik sasteigta, ka pashi celtnieki tur neveeleetos uztureeties

    Atbildēt ↓
  80. Grrr

    >> http://archives.postgresql.org/pgsql-novice/2002-01/msg00021.ph p
    Sorry veči, ne pg, ne mysql, nedz arī oracle pa gadu nav stāvējuši uz vietas.
    Reāli patlaban īpašu salīdzinājumu jaunākajām versijām nav. Vienīgais, ko varu pieminēt par Pg ir tas, ka ātrdarbība viņam ir krasi uzlabojusies sākot no 7.x versijas (~ gadu apakaļ). Tas, ko varu pajautāt mysql cienītājiem:
    – subqueries?
    – foreign keys?
    – (nu, storētās procedūras es nejautāju, zinu ka nav)
    Runājot par portālu — nevajag pribedņatsa. Protams, tā nav internetbankas aplikācija, bet portāliem arī gluži neizmanto vienu tabulu.
    Vietās, kur uz vienu lietotāja operāciju ir jāveic vairākas db operācijas, ir pilnībā loģiski šo secību (un vispār loģiku) pārvietot uz db backendu (storētās procedūras).
    Foreign keys ir lieta, kas visai palīdz pirmkārt enforcēt un otrkārt atvieglot datu uzturēšanu kārtībā (loģikas līmenī). Lai mazāk tērētu laiku uz cilvēku kļūdām.
    Sub-queries… — domāju tās jau nu mysql parādīsies noteikti, ja vēl nav parādījušās, jo kā mysql lietotāji bez tām ir dzīvojuši līdz šim? Ar kreiso kāju kasot labo ausi, lūk kā.
    Protams, var uztaisīt gandrīz jebko lietojot gandrīz jebko. Taču kāpēc?
    3 ātri piemēri – tie ir apzināti vienkāršoti — piezīme tiem, kas bļaus, ka tādu nieku dēļ jau nu var arī šīs lietas netaisīt:
    TABLE comments
    (id integer,
    author integer,
    text varchar);

    TABLE authors
    (id integer,
    name varchar,
    email varchar,
    passwd varchar);

    Piemērs #1:
    Ievietot komentāru, dotajam userim, ja parole ir pareiza (pg sintakse nav 100% ievērota, vienkāršības dēļ):
    Pg:
    CREATE FUNCTION post_comment(uname,upass,utext) RETURNS integer
    AS
    DECLARE
    user integer;
    BEGIN
    SELECT id INTO user FROM authors WHERE UPPER(name)=UPPER(uname) AND UPPER(pass)=UPPER(upass);

    IF user IS NULL THEN
    RETURN 0; — failed, return some code
    END IF;

    INSERT INTO comments (author,text) VALUES (user,utext);
    RETURN 1;
    END;

    Piemērs #2:
    Nodzēšot useru, nodzēst arī visus viņa komentārus:
    Pg: pie comments tabulas izveides rakstam:
    …
    author integer REFERENCES authors(id) ON DELETE CASCADE,
    …
    veicot DELETE FROM authors, commentos (un citur, kur šāds pats FK definēts) visi attiecīgā usera commenti izdzēsīsies.

    Piemērs #3:
    atrast postus kuru autors ir “guguce”:
    Pg:
    SELECT * FROM comments WHERE author =(SELECT id FROM authors WHERE name = ‘guguce’);

    Atbildēt ↓
  81. Kirils

    nu, khekhe…
    es te nedirshos par to, ka oto vai apollo ir laams proj. man vienkaarshi pofig =]
    bet kaac tur prasija iemest linkus uz pashataisiitiem proj. nu ta njemiet ar:
    http://ps.id.lv/mobile/news.php (njemiet veeraa, ka griezhas uz 386 ar 8 ram)
    http://company.id.lv
    http://es.r1g.edu.lv/inhistg.php – par shito… uzmetiet kaac raxtinju par to, ka latnec chakaree klientus, shajaa grafikaa var redzeet par peedeejaam 24h statistiku. cik procentos gadijumu ir izdevies piesleegties latnetam no muusu routera, pljeee! cik juusupraat vajadzeetu buut, a? nu nedaudz zem 100 buutu norma…

    Atbildēt ↓
  82. ui

    Grr, mozh piemēru #3 ieksh MySQL varam kautka shadi:
    SELECT author, text FROM comments AS c, authors AS a WHERE a.id=c.id AND a.name = ‘guguce’;
    sanak pat nedaudz iisaka rinda, ja Pg piemera lietojam nevis “SELECT *” bet konkreti uzradam, kurus stabus gribam un kada seciba 🙂

    Atbildēt ↓
  83. Fricis

    Nesaprotu kapec tauta straukusies par apollo.lv atrdarbibu un kavalitati.
    Varbut mans viedoklis kadam ari nepatiks, bet pods.lv ir vismaz 10 reizes lenaks un krietni glukainaks par apollo.lv.

    Atbildēt ↓
  85. coolynx

    Fricis: ir leenaaks deelj piesleeguma, jo man aarzemes piegrieztas un tev no vaacijas vareetu arii 10 un pat vairaak reizes leenaak veerties 🙁
    es zinu, ka man uz podu no aarzemeem uz 100mbit/s trubas naak tikai kaadi 128kbit/s. taa ka pieljauju, ka no poda vareetu buut tas pats aatrums.

    Atbildēt ↓
  86. purge

    viss, apollo.lv nav vairs man defaultaa zinju saite, piegriezaas pilniigi un galiigii !!!
    Tagd vispaar jaagaida uz atveershanos nez cik ilgi – un arii zinjas ir nepaarskataamas. Tvnets vismaz atveras momentaa…
    Negaidiiju gan, ka taa sachakarees normaalu portaalu 🙁

    Atbildēt ↓
  87. _-=/D|z|y=-_

    Frici – es seezhu uz Dial-Up`a (28,8 kbit/s, dazhreiz 31,2 kbit/s un Pods man pilnībā atveras 23 sekunžu laikā (tikko notestēju), kamēr Apollo atveras 56 sekunžu laikaa. Tā ka par Poda lēnumu vari aizmirst, vismaz no mazjaudiigo i-neta piesleeguma viedoklja. Uzlabotais Apollo (http://www.42901.lv/src/apollo/manapuse2.html) atveeraas 43 sekunžu laikā. Nu, ko tagad teiksi? Laikus es noteicu ar Operu

    Atbildēt ↓
  88. NewAge

    bljaa nesaprotu, jo juus te chiixtat, es shodien notesteeju ar 3 veidu piesleegumiem Apollo aatrumu (Telia CaTV, Apollo Ultra, un dial-up) un bljaa nekaadas lielaas atshkjiriibas no tvnet un delfi nejutu, taa nehuj te bljaut bljaushanas peec.

    Atbildēt ↓
  89. Delerium

    to ui:
    Tavs komentārs par Grrr 3. piemēru ir baigi labs. Man pašam bija slinkums ko teikt, bet Grrr vienkārši ir izvēlējies vienu no sliktākajiem select’iem, ko vispār šajā gadījumā var uzrakstīt. Kaut arī pg nav mans jājamzirdziņš, varu saderēt, ka pg darbojas arī līdzīgs piemērs kā Tavs un gan jau tas ir krietni ātrāks uz lielāka datu apjoma kā author = (select id … ) konstrukcija.

    Atbildēt ↓
  90. ZBH

    PostgreSQL cieniitajiem – vai beidzot iraid pazudus senaa nelaim, ka paretam (nu, ne biezhaak kaa reiz meenesii 🙂 baazs miil iekorupteeties?

    Atbildēt ↓
  92. vdl

    ZBH: man postgres griezhas pailgu laiku un korupcija kaukaa naff noveerojama ;D apjoms gan naff milziigs bet nju anyway nemanu gljukus

    Atbildēt ↓
  93. Grrr

    >>> PostgreSQL cieniitajiem – vai beidzot iraid pazudus senaa nelaim, ka paretam (nu, ne biezhaak kaa reiz meenesii 🙂 baazs miil iekorupteeties?
    Shi “senaa nelaime” (kuru pats gan nekad neesmu redzejis dzivee, kaut ari ar pg nodarbojos kadus gadus 6), iraid pazudusi kopsh versijas 6.5.3, ja nemaldos. Which was kind of 2 years ago.
    P.S. Par piemeeru #3 — piekritu, vareja ari atbilstoshaku – rakstiju steigaa.
    Tipiskaaks piemers varetu but, piemeram, SELECT something FROM table WHERE field1 > avg(field1).
    Bez subquerijiem var teoretiski dzivot (kaa mysql to ir pieradijis), tachu vai ir kada nepiecieshamiba? Godigi sakot, ja man jautatu, kadu iemeslu pec lai es lietotu mysql, vienigais ko es varu izdomat ir — ir it kaa daudz cilveku, kas to izmanto.

    Atbildēt ↓
  94. she`ka

    euuzz… paskataties http://www.apollo.lv/portal/themes/84
    zinajat ka tur ir links uz pods.lv ? 🙂 Tur kur ir dienas jautaajums un zemaak ir “Atradumi internetaa” – Diskusija par jauno portāla Apollo.lv dizainu lapā
    kads jau bija pamaniijis?

    Atbildēt ↓
  95. Delerium

    Tas ir slimi – es ātrāk varu atvilkt 100MB failu no ārzemēm (piem, technet.oracle.com), nekā atvērt mani interesējošu rakstu apollo portālā 😀

    Atbildēt ↓
  99. karuuzo

    Kaads vispaar ir redzeejis to tresho pusi? Vai nu man browseris liiks, vai pacietiibas nav, bet vairaak kaa “Loading…” es taa arii neko neesmu redzeejis.
    m

    Atbildēt ↓
  102. vimba

    Labs variants bij ar manu e-mailu.
    Meegjinaaju ieiet peec ilgiem laikiem savaa xxx@e-apollo.lv adresiitee. Nesanaaca, kaut gan ljoti labi atceros paroli. Domaaju buus paspeejushi izdzeest, patiirijushi vecaas kastiites. Ja taa, tad atkal jaaaizsit vecaa vieta! Regjistreejamies, logins, paroliite (izveeleejos veco – taa prikola peec), veelreiz paroliite, OK. Logojamies iekshaa – Sveiks jaunais lietotaaj xxx ! Jums ir 149 jaunas veestules ! Opaa. . . Spams . . .
    Sanaak kas – kastiiti izdzeesa, vecos mailus nee. Taa luuk veiksmiigi atguvu vecos labos mailus atpakalj. END.

    Atbildēt ↓
  104. xxx2

    Ja jau runa aizgaja par sql serveriem, par firebird (interbases clonu) varu tikai tos labākos vārdus teikt… Tomēr arī tam ir savi trūkumi, lielākais – vājas user pieejas tiesību piegriešanas iespējas. Tā ka likt interbasi uz šārētiem serveriem….. Bet nedomāju ka apollo izmanto sharēto serveri….
    Un ja kas no ātrdarbības viedokļa
    SELECT * FROM comments WHERE author =(SELECT id FROM authors WHERE name = ‘guguce’); ir pilnīgi nepareiza konstrukcija…. ja daudzi ieraksti – bremze nemērīga
    jālieto
    SELECT author, text FROM comments AS c, authors AS a WHERE a.id=c.id AND a.name = ‘guguce’
    bet vispareizāk
    SELECT author, text FROM comments as c
    left join authors as a on (a.id=c.id)
    WHERE a.name = ‘guguce’
    Tas nu tā – sikums 🙂

    Atbildēt ↓
  107. Delerium

    Grrr, cerams, ka Tu labāk saproti par ko Tu runā. Bet man nav skaidrs, kā var salīdzināt index scan ar join ? Tās ir divas dažādas lietas – index scan nozīmē, ka kaut kādā veidā (ir dažādi index scan veidi) pēc index tiek atlasīti dati. Join nozīmē, ka atlasītie dati tiek sajoinoti vienā datu kopā. Nemāku labāk izstāstīt 🙂

    Atbildēt ↓
  108. Grrr

    Salīdzinam index scanu ar joinu tā, ka konkrētie selekti var izmantot vai nu vienu vai otru (vai protams combo).
    Piemēram, ļoti līdzīgs piemērs no reālas tabulas (slinkums bija konkrētos piemērus vēl creatot):
    explain select GM.uid from group_members GM,groups G where G.gid = GM.gid AND G.name=’abc’;
    QUERY PLAN
    ——
    Hash Join (cost=0.00..0.01 rows=1 width=12)
    Hash Cond: (“outer”.gid = “inner”.gid)
    -> Seq Scan on group_members gm (cost=0.00..0.00 rows=1 width=8)
    -> Hash (cost=0.00..0.00 rows=1 width=4)
    -> Seq Scan on groups g (cost=0.00..0.00 rows=1 width=4)
    Filter: (name = ‘abc’::character varying)
    Tas pats query ar subselectiem dod:
    explain select GM.uid from group_members GM where GM.gid = (SELECT gid FROM groups WHERE name=’abc’);
    QUERY PLAN
    ——
    Seq Scan on group_members gm (cost=0.00..0.00 rows=1 width=4)
    Filter: (gid = $0)
    InitPlan
    -> Seq Scan on groups (cost=0.00..0.00 rows=1 width=4)
    Filter: (name = ‘abc’::character varying)
    Neesmu ļoti dziļš spečuks par optimizāciju, palabo mani ja kļūdos, bet pie joina sanāk vairāk operāciju, un costs kopā izskatās arī varētu būt lielāks.
    (Ja te būtu indexi uz konkrētajiem laukiem, tad protams arī būtu Seq scan vietā Index scan.)

    Atbildēt ↓
  109. Anonīmais

    Var jau arii shitaa 😉 . Cik saprotu, gan ne uz MySql.
    SELECT * FROM comments a,
    (SELECT id FROM authors WHERE name = ‘guguce’) b
    WHERE a.id = b.id
    Vai
    SELECT author, text FROM comments as c
    join authors as a on (a.id=c.id AND a.name = ‘guguce’)
    Kaadi veel varianti ? 😉

    Atbildēt ↓
  110. Delerium

    Izmantosim coolynx pacietību un turpināsim offtopic 😀
    Grrr:
    Konkrētais piemērs jau neko neizsaka. Katrā atsevišķā gadījumā labākais variants var atsķirties, bet runa ir par to, ka “principā JOINi tomēr ir ēdelīgākas operācijas nekā index scani”, jo JOIN un INDEX SCAN ir principiāli atsķirīgas lietas. Tas ir tā pat kā salīdzināt SCAN ar SORT. Ja Tev vajadzēs rezultātu sakārtot, Tu taču no kārtošana neatteiksies tādēļ, ka “maksa” par to ir lielāka kā par JOIN …
    Vēl viens piemērs iz dzīves: 2 + 2 = 2 * 2 (rezultāts ir viens), bet nevar teikt, ka saskaitīšana ir labāka vai sliktāka par reizināšanu, tas vienkārši ir savādāk.

    Atbildēt ↓
  111. Grrr

    Shie abi varianti reali SQL limeni neatskiras no parasta Joina.
    Tas pats
    seq scan + hash + seq scan + hash join
    prestataa
    seq scan + seq scan
    ar subqueries.

    Atbildēt ↓
  112. Grrr

    Delerium — jaa shai zinjaa tev ir taisniba. Daleji.
    Jautajums ir vai ja JOIN ir edeligaks par SCAN un ir operacija ko darit ar SCAN, vai tas nav labak, nekaa izmantot JOIN? Un vai nav jauki ka shada opcija ir? 🙂

    Atbildēt ↓
  113. Grrr

    Anyway, manuprat tas viss radas tapec, ka kaads apgalvoja ka subquery ir lenaks par joinu. Which needn’t be the case at all. In fact, it may be the other way around more often, in my experience.

    Atbildēt ↓
  114. coolynx

    Delerium: man patiesiibaa ir ljoti interesanti palasiit juusu spriedeleejumus par optimaalaakiem kverijiem, jo es pats no taa visa ljoti minimaali ko jeedzu. tb selektu uztaisiit maaku, bet nezinu vai tas ir pareizs un aatrs vai nee. nav man pieredzes ar db. gribu padarboties ar postgresu, jo reaalaa situaacijaa mysql nedraudzeejas ar utf-8, ja neskaita jaunaakaas versijas, kur tas tiek implementeets, savukaart to vajag jau tagad un uzreiz nevis veel meeneshus un varbuut pat gadus testeet uz savas aadas…

    Atbildēt ↓
  115. Delerium

    Grrr:
    Ja runa iet par mazām tabulām, tad full table scan ir labs variants un tad neatmaksājas pat scan’ēt pēc indexa.
    Šajā gadījumā subquery nav atkarīga no parent query, tās rezultātu iegūst vienu reizi un viss, bet, ja subquery atlasa datus vadoties pēc parent vērtības, tad join sāk kļūt stipri pievilcīgāks. Piemēram:
    select GM.uid from group_members GM where GM.gid = (SELECT gid FROM groups WHERE GM.cits_id = groups.id);
    šajā gadījumā scan’ēšana parādīsies cikliski un būs stipri sliktāk par join, kas būs jāveic vienu reizi.
    Ja vienmēr būtu iespējams pateikt, ka viena operācija izpildīsies ātrāk par otru, tad tas jau būtu iebūvēts DBVS un nevajadzētu lauzīt galvu par tuning’u, bet viss atkarīgs gan no tā, cik lielas ir tabulas, gan cik daudz datu atlasa, ko ar viņiem pēc tam dara utt. Līdzīgi ir ar indexiem – vispārīgā gadījumā tie ir vairāk noderīgi, nekā nederīgi, bet ja pēc indexa atlasa lielāko daļu tabulas, tad tas ir gandrīz 2 reizes sliktāk kā full table scan.
    Vēlreiz atkārtošu, ka VISPĀRINĀT NEKO NEDRĪKST. Katrā gadījumā, kad ir doma, ka query varētu strādāt ātrāk – jaskatās execution plan.

    Atbildēt ↓
  116. Delerium

    coolynx:
    Mazā DB ar dažiem tūkstošiem ierakstu nav problēmas bez īpašas iedziļināšanās teorijā pārbaudīt pāris query variantus praktiski un saprast, kurš ir ātrāks. Lielās DB, kur dati ir gigabaitiem, neviens negribēs gaidīt lai noskaidrotu, vai query izpildās 12 vai 14 stundas, tādēļ jāskatās pieprasījumu izpildes plāni. Bet lai tos saprastu un zinātu, kā ietekmēt ir diezgan padziļināti jāapgūst vispārīgie tuninga principi un arī konkrētās DBVS specifika. Un jāeksperimentē 🙂
    Rezultātā ir tā, ka optimālu query nevar noskatīt vai piemeklēt

    Atbildēt ↓
  117. karuuzo

    Patiesiibaa striids ir ne pa teemu, jo, ja paskataas SELECT peec kontexta, tad redzam, ka name ir vairaak vai mazaak unikaala veertiiba (ja tie ir regjistreetie lietotaaji, tad jaabuut unikaalai) un katram name atbilst tikai viens id. No taa iztiet ka SUBQUERY atgriezj tikai vienu veertiibu, kas tiek izmantota kaa konstante (protams ka vajag uzlikt UNIQUE INDEX uz name) un:
    SELECT * FROM comments WHERE author = xx
    straadaas daudz aatraak kaa:
    SELECT * FROM comments c, authors a WHERE c.author = a.id AND A.name = ‘guguce’)
    arii pie lieliem apjomiem.
    Tas taa, paardomas par teemu :))
    m
    PS. Es gan labaak paarzinu Informix un Oracle, sintakse atbilstosha.

    Atbildēt ↓
  118. Delerium

    karuuzo, Tev jau ir taisnība, bet parasti jau aplikācijās nevar iebūvēt kādu konkrētu ID, jāizmanto dinamiski pieprasījumi.
    Es arī pārzinu Oracle (OCP DBA), bet par pg un mysql zinu salīdzinoši maz.

    Atbildēt ↓
  119. Grrr

    Piekrītu jums abiem, Delerium un karuuzo, taču atgādinu, ka:
    1) šo piemēru jau atzinu par netipisku subquery izmantošanas nepieciešamībai, tā vietā piedāvāju realizēt kaut ko kas dara šādu (SQL nepareizu) query:
    SELECT something FROM table WHERE field1 > AVG(field1)
    2) visa tālākā ņemšanās ap mocīto subquery no mana viedokļa bija par to, ka lūk subquery:
    “Un ja kas no ātrdarbības viedokļa
    SELECT * FROM comments WHERE author =(SELECT id FROM authors WHERE name = ‘guguce’); ir pilnīgi nepareiza konstrukcija…. ja daudzi ieraksti – bremze nemērīga ”
    Kas manuprāt ir galīgi no gaisa pagrābts, un kur atkal piekrītu Deleriumam par to, ka nevar vispārināt.

    Atbildēt ↓
  120. ???????

    Vairs apollo izcūkot nevar? Un, ja vēl var, tad man kaut kas ar raksta id nesanāk…
    Varbūt vari pateikt kā kaut ko lidzīgu var Delfos salikt?

    Atbildēt ↓

Ieraksti komentāru

Tava e-pasta adrese netiks publicēta. Obligātie lauki ir atzīmēti kā *