Gints Plivna

Labāk jau nu pasaki ko vajag. Vēl jo vairāk tāpēc, ka name ir gan iekš category, gan names tabulas. Tātad apmēram tā: - KO īsti grib atrast - kategorijas vai nosaukumus? (ņemot vērā, ka vienai kategorijai ir vesels bars nosaukumu) - kurā laukā meklē? - ko grib redzēt (kolonas) rezultātu sarakstā (atkal atceramies, ka vienai kategorijai ir N nosaukumi)? Gints Plivna http://datubazes.wordpress.com

Manas domas par vidusskolu: Kā vienmēr šis ir no sērijas - "it depends". Un atkarīgs tas ir no konkrētā cilvēka. Jo vidusskolā tomēr iemāca daudzas un dažādas lietas, tā teikt paplašina redzesloku. Ir cilvēki, kam vispār nav jāiet skolā un, kas ir ieguvuši pietiekami lielas un plašas zināšanas, ir cilvēki, kas var iet 100 skolās un ar viņiem būs tikai sliktāk, jo nekas nav sliktāks par mācītu muļķi, ja nu vienīgi mācīts un ļoti aktīvs muļķis. Tātad, manuprāt, vidusskola ir nepieciešams posms cilvēka dzīvē, kurā viņš iegūst plašāku skatu uz pasauli, un, lai kā arī kādam nepatiktu fizikas, ķīmijas vai arī tieši otrādi literatūras un vēstures, vidusskolā to tomēr māca un vismaz daļēji apgūst. Un varbūt to tieši precīzi izmērāmā veidā nevarēs pateikt, cik tas ienes $$ tavā nākošajā profesijā, bet tomēr netieši tas ietekmē - jo zināšanu loks ietekmē gan citu personu attieksmi pret tevi, gan atsevišķās (arī ar IT saistītās) profesijās ir ļoti vēlams, lai izglītība neaprobežotos tikai ar pliku programmēšanu. Jā no vienas puses pēc vidusskolas it kā cilvēks ir ne cepts, ne vārīts un iespējams viņam būs grūtāk sameklēt saprātīgi apmaksātu darbu nekā kādu profskolu beigušam, bet, manuprāt, potenciālās iespējas viņam ir lielākas nekā profenes audzēknim. Tas ir līdzīgi kā visādiem tur dzīvnieku mazuļiem - ir tādi, kas ilgi dzīvo pie mammas (bara) un sākotnēji neko nevar un vieni neizdzīvotu, bet tomēr galu galā tās sugas parasti ir augstāk attīstītas nekā tās, kuru mazuļi jau pirmajās dienās var drasēt visiem līdzi un kuru dzīve vairāk pamatojas uz instinktiem, nekā apmācību ;) Otra lieta - ko Kaklz jau pieminēja - spēja būt pieaugušam - daudziem cilvēkiem pēc 9tās klases tādas vēl nav. Un tad vai nu ir pārāk pašpārliecināti par sevi un palaižas slinkumā (ko BTW var izdarīt arī vidusskolā, zinu tādus, kas gāja ir 1mo ģimnāziju no neRīgas un beigās atnāca atpakaļ dēļ sava slinkuma), vai vienkārši savāra ziepes. Bet nu kā jau teicu - tas ir ļoti individuāli un ļoti atkarīgs no konkrētā cilvēka, cik viņš ir patstāvīgs, uzņēmīgs, vai ir izlēmis, ka konkrētā lieta tiešām būs tā, kas viņam dzīvē patiks. Un vai ir pārdomājis, ko darīs, ja konkrētā izvēle tomēr nepatiks, nepadosies utt. Kaut gan patiesībā droši vien lielākā daļa cilvēku tai vecumā par neko tādu vispār nedomā un pats fakts, ka šāds jautājums jau ir pacelts nozīmē, ka cilvēks ir izaudzis virs vidusmēra ;)

To var tādā gadījumā, ja Tev tās vērtības foo, doo un boo jau ir bāzē kādā tabulā ar atbilstošo grupas id, vai kodu vai whatever kādu citu unikālu lauku, pēc kura tās var atlasīt. Citādi nekas nesanāks, jo neko sarežģītāku par skalāriem mainīgajiem AFAIK MySQL nesaprot, bet šīs vēlmes izklausās pēc masīvveidīgas konstrukcijas tipa kolekcijas no pārīšiem - grupas id (vai nosaukuma), vērtība. Padomāju un atcerējos, ka tādas lietas taču reizēm feikoja ar nosacīti sakodētu string mainīgo :) Vobše čerez dziļu ž to izdarīt var. Tātad man ir tabula persons: mysql> desc persons; +------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+------+-----+---------+-------+ | prs_id | int(11) | NO | PRI | NULL | | | prs_grp_id | int(11) | NO | | NULL | | | prs_name | varchar(10) | NO | | NULL | | | prs_value | varchar(100) | YES | | NULL | | +------------+--------------+------+-----+---------+-------+ 4 rows in set (0.01 sec) mysql> select * from persons; +--------+------------+----------+-----------+ | prs_id | prs_grp_id | prs_name | prs_value | +--------+------------+----------+-----------+ | 1 | 345 | Davis | NULL | | 2 | 345 | Lauris | NULL | | 3 | 765 | Maris | NULL | | 4 | 1 | Anete | NULL | +--------+------------+----------+-----------+ 4 rows in set (0.00 sec) Kā redzam visiem prs_value ir tukšs. Nu un tagad varam pieņemt, ka mums ir simbolu virkne spec formātā <grupas_id:vērtība,> Tad atliek tikai izkasīt ārā vērtību atbilstoši grupas id. Iespējams, ka to var izdarīt kaut kā īsāk, bet te nu ir mans variants :) Nu un, protams, ka šis var nestrādāt, ja vērtībā ir iekšā kols vai komats. mysql> set @str := '1:foo, 345:boo, 765:zoo,'; Query OK, 0 rows affected (0.00 sec) mysql> mysql> UPDATE persons -> SET prs_value = -> substr(@str, -> locate(concat(prs_grp_id, ':'), @str) + length(concat(prs_grp_id,':')), -> locate(',', @str, locate(concat(prs_grp_id, ':'), @str)) - locate(concat(prs_grp_id, ':'), @str) - length(concat(prs_grp_id, ':')) -> ); Query OK, 4 rows affected (0.03 sec) Rows matched: 4 Changed: 4 Warnings: 0 mysql> select * from persons; +--------+------------+----------+-----------+ | prs_id | prs_grp_id | prs_name | prs_value | +--------+------------+----------+-----------+ | 1 | 345 | Davis | boo | | 2 | 345 | Lauris | boo | | 3 | 765 | Maris | zoo | | 4 | 1 | Anete | foo | +--------+------------+----------+-----------+ 4 rows in set (0.00 sec) Gints Plivna http://datubazes.wordpress.com/ P.S. Ja tā doma darīt, tad piprms ida arī jāliek kols, jo citādi 1: un 11: priekš id = 1 atradīs abos gadījumos un iespējams nepareizi. Tb stringā jāliek :1: vai :11:.

Eeee ta kā nejūtu tomēr 100% sapratni, _kāpēc_ neder, bet drīzāk aklu pakļaušanos autoritātei :D :D :D, tad tomēr vēlreiz: - mysql_num_rows ļoti labi noder,ja vajag atlasīt datus UN PIE REIZES noskaidrot cik tad ierakstus atlasīja. - mysql_num_rows neder (funkcionāli jā, bet no ātrdarbības viedokļa galīgi nē), ja vajag noskaidrot TIKAI skaitu. Ja vajag noskaidrot TIKAI skaitu, summu, vidējo vērtību, minimālo vērtību, maksimālo vērtību, tad lietojam attiecīgi COUNT(*), SUM(izteiksme), AVG(izteiksme), MIN(izteiksme), MAX(izteiksme). @Grey_Wolf Paldies par komplimentu :) Gints Plivna http://datubazes.wordpress.com

Tā NEVAJAG darīt! Analoģija - tā vietā, lai saskaitītu grāmatplauktā esošo grāmatu nosaukumus, kuru nosaukumi atbilst tai apakšvirknei, un vienkārši pateiktu skaitli, tu paņem lapiņu, un akurāti pieraksti pirmo derīgo nosaukumu, otro derīgo nosaukumu, utt. Tad iedod lapiņu tam, kas tev to vaicāja, un saki - skaiti pats. Ir kāda jēga no tā? Gints Plivna http://datubazes.wordpress.com

Pārāk maz info, bet ļoti vispārīgi runājot par datubāzēm (ja tur tāda apakšā vispār ir): 1) Slikti ir tad, ja lietotājs pilda da jebkādu lielu pieprasījumu, kas prasa daudz resursus (statistika, neoptimāla meklēšana utt) vai bloķē resursus - piem pievieno vai modificē ierakstus un uz to brīdi neviens cits nevar šai tabulā to darīt. 2) Slikti ir tad ja __daudzi__ lietotāji pilda mazus pieprasījumus, jo tie visi kopā summējas. 3) ĻOTI SLIKTI ir tad, ja __daudzi__ lietotāji pilda lielus pieprasījumus. Tātad pēc iespējas mazāk pieprasījumu (skaitā) un pēc iespējas mazāki pieprasījumi (pēc izpildes laika un resursu nepieciešamības). To kā reiz var minimizēt ar kešošanu, nerādot lieku info, neizvirstot ar funkcionalitāti. Pēc iespējas minimizēt arī dzenājamo datu apjomu starp DB un webserveri un webserveri un klientu. Un vēl ļoti silts ieteikums - ja tam apakšā ir kāda bāze, tad testē uz reāla (t.i. produkcijai atbilstoša) datu daudzuma. Dabū tos reālus vai saģenerē, tas jau ir sekundāri, bet īstās problēmas parādās tikai tad. Nu un, protams, stress testi - izmanto rīkus, kas veidos ntos pieprasījumus lapai un skaties, kas tur sanāk. Lai vismaz sākotnējās problēmas risini pats, nevis visu saņem no klienta, jo no klienta pretenzijas būs anyway :) Gints Plivna http://datubazes.wordpress.com

Yeahh, es jau laikam esmu redzējis dažus Tavus jautājumus, bet nu, ja tā padomā neviens nav piedzimis par koderi, tāpēc mēģināšu paskaidrot ;) Pirms visām šīm idejām ir jautājums - kāpēc datubāzi vajag taisīt dinamiski? Ja rodas uzmācīga vēlme izveidot db pārvaldīšanas rīku, tad nevajag izgudrot divriteni, bet ņem gatavu rīku, piemēram, phpMyAdmin. Ja kaut kāda cita iemesla dēļ, tad par 99,9% gadījumu Tu kaut ko dari nepareizi. Jo saprātīgi gadījumi, kad kodā veido datubāzes un datubāzu objektus vispār ir reti. Normāli ir instalācijas skripts (vai sliktākā gadījumā laikā gaitā ar roku izveidoti objekti, bet tas ir bad bad), kas uzinstalē datubāzes objektus - pašu datubāzi, ja nepieciešams, tabulas, indeksus, u.c. Un aplikācija tikai apstrādā datus jau zināmos objektos. OK var būt reti speciāli gadījumi, kad aplikācija pati var dinamiski veidot un dzēst objektus, bet tad ir jābūt kādiem speciāliem iemesliem, kāpēc nevar iztikt ar iepriekš zināmu objektu kopu. Gints Plivna http://datubazes.wordpress.com

Nekad nesaki nekad ;) Es, jo vecāks nāku, jo vairāk visādas dīvainības esmu redzējis un mazāk kategorisks uz "nekad to nelietot" palieku. Jā es personīgi šo variantu nelietotu. Bet, ja kāds spētu pamatot, kāpēc tieši šai gadījumā tas viņam derētu, un kāpēc visi pretargumenti šai gadījumā nav būtiski, tad kāpēc ne? T.i. kaut kādas dīvainības lietošanai es personīgi gribu redzēt ļoti pamatotus argumentus, ja tādi ir, tad iespējams to var izmantot. Gints Plivna http://datubazes.wordpress.com

Vispārīgā gadījumā noteikti 1 scenārijs Par detaļām var apdomāt šādas tādas optimizācijas, lai it kā būtu vieglāk: 1) rakstīt starptabulā tikai tos ierakstus, kur lietotāji jau ir apskatījuši - ja lielākā daļa savā mūžā apskatīs tikai dažus ierakstus - nebūs jāveido bezjēgā daidz ieraksti ar 0 2) datu atlase ir zibenīga - ir takš tādas lietas kā indeksi. 3) m8t piedāvātais variants arī ir izskatīšanas vērts, bet ar šādām struktūrām vienmēr ir jābūt ļoti uzmanīgam. Explode - ir PHP specifiska lieta, ne visās programmēšanas valodās - nemaz nerunājot par SQL tas būs tik vienkārši. Otra lieta šeit ir relatīvi viegli iegūt lietotāja apskatītos ierakstus BET, lai iegūtu konkrētam ierakstam tos lietotājus, kuri to ir apskatījuši ir nevājš čakars - tā kā jāskatās pēc prasībām, ko Tev vajag un vai šāda struktūra der. Gints Plivna http://datubazes.wordpress.com

"Informācijas" kolonas nosaukums un datu tips ļoti noderētu, lai nenodarbotos ar minēšanu kādā gan formātā Tu to glabā. Gints Plivna http://datubazes.wordpress.com/

Pāris jautājumi, uz kuriem vismaz pašam sev atbildēt: 1) Tāds "sīkums", kā paredzētā DBVS? Es saprotu, ka vairumam ļaužu visas DBVS ir vienādas, tāpat kā visas mašīnas, piemēram, bet nu reāli tā nav :) Tad, kad izlem kādu DBVS ņemsi, parakā googli un konkrētās DBSV dokumentāciju un paskaties ko tā piedāvā lielu datu apstrādēi, atslēgas vārds šai gadījumā varētu būt partitioning. 2) Kā tos datus izmantos? Jo 121 miojons gada laikā ieraksti neliekas nekas īpašs, es uz savas nīkulīgās mājas kastes ne pārāk platu tabulu varu izveidot ar simts miljons ierakstiem max daždesmit minūšu laikā, svarīgi ir, ko un kā ar tiem datiem darīs pēc tam. Gints Plivna http://datubazes.wordpress.com

Njā tas noteikti būtu jāpasaka. Vai piemēram wordpress ir 1 lapa vai tik cik minēts šeit šobrīd 18 487 890? Varētu teikt, ka diezgan liela atsķirība :) Gints Plivna http://datubazes.wordpress.com

Nupat jau kā reiz Delfos sakarā ar tautas skaitīšanu kā reiz bija ļoti līdzīga tēma: http://www.delfi.lv/news/national/politics/tm-daudzas-iestades-pases-kopijas-ludz-nepamatoti-iedzivotaji-to-neapzinas.d?id=37187879 Gints Plivna http://datubazes.wordpress.com

Nu, ja godīgi esmu gatavs piekrist, ka SQLs nav varbūt labākais risinājums šai problēmai :) BET cross join ka zināms ir Dekarta reizinājums. Tātad katrs ar katru. Ja no tā kaut ko vajag ierobežot, tad to var izdarīt gluži tāpat kā, ja laistu cauri kaut kādus ciklus ciklā vai kā citādi ģenerētu šādus variantus. Piemēram šādi: WITH v AS ( SELECT '1110' AS n union ALL SELECT '1121' union ALL SELECT '1122' union ALL SELECT '1130' union ALL SELECT '' ) SELECT DISTINCT (CASE WHEN v1.n = '' THEN '' WHEN LEN(v2.n + v3.n + v4.n + v5.n) > 0 THEN v1.n + ',' ELSE v1.n END + CASE WHEN v2.n = '' THEN '' WHEN LEN(v3.n + v4.n + v5.n) > 0 THEN v2.n + ',' ELSE v2.n END + CASE WHEN v3.n = '' THEN '' WHEN LEN(v4.n + v5.n) > 0 THEN v3.n + ',' ELSE v3.n END + CASE WHEN v4.n = '' THEN '' WHEN LEN(v5.n) > 0 THEN v4.n + ',' ELSE v4.n END + CASE WHEN v5.n = '' THEN '' ELSE v5.n END) AS t FROM v v1 CROSS JOIN v v2 CROSS JOIN v v3 CROSS JOIN v v4 CROSS JOIN v v5 WHERE v1.n <> v2.n AND v1.n <> v3.n AND v1.n <> v4.n AND v1.n <> v5.n AND (v2.n <> v3.n AND v2.n <> v4.n AND v2.n <> v5.n OR len(v2.n + v3.n + v4.n + v5.n) = 0) AND (v3.n <> v4.n AND v3.n <> v5.n OR len(v3.n + v4.n + v5.n) = 0) AND (v4.n <> v5.n OR len(v4.n + v5.n) = 0) order by t t ------------------------ 1110 1110,1121 1110,1121,1122 1110,1121,1122,1130 1110,1121,1130 1110,1121,1130,1122 1110,1122 1110,1122,1121 1110,1122,1121,1130 1110,1122,1130 1110,1122,1130,1121 1110,1130 1110,1130,1121 1110,1130,1121,1122 1110,1130,1122 1110,1130,1122,1121 1121 Nezinu, vai tas ir tas ko vajag, jo īsti jau tā skaidri neaprakstīji, kas tas ir, bet nu pielabojot WHERE klauzas teorētiski noteikti var dabūt to, kas nepieciešams. Vai tas ir arī praktiski labs risinājums - nu tas jau ir cits jautājums ;) Galu galā mēs zinām, ka SQLā mierīgi var zīmēt arī pulksteni, piemēram Gints Plivna http://datubazes.wordpress.com

Diezgan patizli izskatās, bet kaut kas uz to pusi ir: WITH v AS ( SELECT '1110' AS n union ALL SELECT '1121' union ALL SELECT '1122' union ALL SELECT '1130' union ALL SELECT '' ) SELECT DISTINCT (CASE WHEN v1.n = '' THEN '' WHEN LEN(v2.n + v3.n + v4.n + v5.n) > 0 THEN v1.n + ',' ELSE v1.n END + CASE WHEN v2.n = '' THEN '' WHEN LEN(v3.n + v4.n + v5.n) > 0 THEN v2.n + ',' ELSE v2.n END + CASE WHEN v3.n = '' THEN '' WHEN LEN(v4.n + v5.n) > 0 THEN v3.n + ',' ELSE v3.n END + CASE WHEN v4.n = '' THEN '' WHEN LEN(v5.n) > 0 THEN v4.n + ',' ELSE v4.n END + CASE WHEN v5.n = '' THEN '' ELSE v5.n END) AS t FROM v v1 CROSS JOIN v v2 CROSS JOIN v v3 CROSS JOIN v v4 CROSS JOIN v v5 order by t Gints Plivna http://datubazes.wordpress.com

Nu uzskati, ka NULL arī ir mainīgais.

Pieliec vēl NULL (tipa tukšā vērtība šai gadījumā) un paņem cross join. Nupat te jau bija ļoti līdzīga tēma, kurai izrādās pats vien esi autors :) Gints Plivna http://datubazes.wordpress.com

No visa tā sviesta, ko tu sacerēji, par dažām lietām, kas attiecas vairāk vai mazāk par tēmu: Tu neticēsi, bet piemēram matemātikā ir loģiskas lietas, ko cilvēki ir atklājuši pirms n tūkstošiem gadu un tās vēl joprojām ir loģiskas. Arī datorzinātnēs pamatlietas nav mainījušās neatkarīgi no tā, ka katra nākošā krutā programmēšanas vide sola visu apgriezt kājām gaisā un sākt dzīvo no jauna. Tev acīmredzot vēl mazliet jāpaug un jāiegūst mazliet pieredze, lai saprastu, ka ar tevi nav sākusies civilizācija uz zemes, vai vismaz jauna ēra :) Runājot par datubāzēm ļoooti daudzas pamatlietas, kas bija pirms 10 un 20 gadiem nav mainījušās. Un visdrīzāk, ka nemainīsies arī tuvākajā nākotnē. Yeahhh nu pēc tā jau vien var spriest par tavām zināšanām par DB ;) LIMITs, kas BTW ir MySQL specifiska konstrukcija, loģiski ierobežo atgriežamo datu kopu. Fetch ir pavisam cita lieta, tā ir fiziskā operācija, kas vispārīgā gadījumā nolasa N ierakstus no kursora. Pie tam šo N parasti var konfigurēt, jo optimālā vērtība varētu būt atkarīga no konkrētās programmatūras un pielietojuma. Kā redzams no tā buga, ko minēju augstāk, tad MySQL ar to ir problēmas, jo izskatās, ka noklusēti nolasa visu reizē un nav īpašu iespēju to konfigurēt. Labi, trolli, nu jau būšu pietiekami daudz veltījis tev savu uzmanību. Kad izaugsi, pieņemsies prātā, sapratīsi, ka civilizācija nav sākusies līdz ar tevi, tad arī parunāsim ;) Gints Plivna http://datubazes.wordpress.com

Es teiktu, ka tas noteikti būtu elastīgāk, jo neierobežo maksimālo kategoriju dziļumu. Tiesa gan praksē var rasties zināmas problēmas anyway, jo MySQLam tādu īstu rekursīvo vaicājumu nav, ir jāizlīdzas vai nu ar vaicājumu fiksētā dziļumā vai arī jāizmanto speciālas DB konstrukcijas. Praksē tādām kategorijām jau nu gan parasti arī dziļums ir ierobežots uz kādām 4-5 max, vairāk šķiet normāli neesmu redzējis. No otras puses, ja šeit oriģinālā jautājuma autoram ar 2 līmeņiem pilnībā pietiek un viss jau uzkodēts atbilstoši tam, tad droši vien nav vērts šaut ar lielgabalu pa zvirbuļiem un sarežģīt lieki sev dzīvi :) Gints Plivna http://datubazes.wordpress.com

Man gan liekas, ka weblapai analoģija drīzāk ir ar publisko namu, kurā noklusēti visi drīkst nākt iekšā, tai skaitā roboti. Ja tu nolem, ka tas ir nevis publiskais nams, bet dzīvoklis, tad pieliec tam atslēgu (piem, lietotāja vārds/parole), kuru iedod tikai izredzētiem. Ja tu nolem, ka publiskais nams ir domāts cilvēkiem, nevis robotiem, tad pieraksti to augšminēto rindiņu un viņi ir pietiekami pieklājīgi un pat tikai izlasot zīmīti uz durvīm nenāk iekšā, kaut gan durvis ir vaļā :) Gints Plivna http://datubazes.wordpress.com

@F3llony Tev nu gan ir verbālā caureja, vai tad viena vīna pudele atstāj tādas sekas jebšu tev tā vienmēr? ;) Un nevajag lietas uztvert tik dziļi personīgi, es jau tevi nevaru atlaist :D OK tagad pie lietas. Precizēju, kas ir ļoti ļoti slikti. Un tas ir, ja tā vietā, lai atlasītu datus no 2 tabulām, izmantojot visparastāko savienojumu, vispirms ciklā atlasa ierakstus no vienas tabulas un tad katram ierakstam no pirmās iekšējā ciklā atlasa no otras. Patiesību sakot viss pārējais jau vairs nav būtiski. Ja persona par savienojumiem nav informēta, tad vēl ir cerība, jo, protams, neviens nav piedzimis ar SQL zināšanām jau šūpulī. Taču, ja persona to zina, bet nelieto ar tekstu "datu bāze ir paredzēta datu glabāšanai, ne apstrādei", tad man tikai atliek izstāstīt analoģiju no ikdienas dzīves. Pieņemsim, ka no veikala ir jāpārnes 3 kg cukura, 2 piena pudeles un 10 sērkociņu kastītes. Kā rīkojas vairums cilvēku, kuriem nemaz nav nepieciešams būt ar aizstāvētu doktora grādu raķešzinātnēs? Aiziet uz veikalu, izstaigā to, sameklē vajadzīgo, samaksā kasē, samet maisiņā un dodas mājās. Kā rīkojas cilvēki, kas neatzīst šādu pieeju? Viņi iet uz veikalu, aiziet pie cukura plauktiņa, atrod paciņu, ieliek groziņā, samaksā kasē un nes mājās. Tad iet vēlreiz, dara visas tās pašas darbības un atnes nākošo. Tad vēl 1 reizi. Tad iet un atnes vienu piena pudeli. Tad nākošo utt līdz viss vajadzīgais mājās. Iespējams, ka veikalā (aka MySQL) šo savādnieku jau pazīst un, lai viņa dzīve nepārvērstos ellē, tomēr samet visas cukura paciņas kulītē uzreiz (aka atlasa visus ierakstus buferī, kā te minēja) kā izskatās pēc mysql_query un mysql_unbuffered_query, tad viņš tā dara, jā. Dikti loģiski jau tas īsti nemaz nav, jo mazliet gudrākām DB parasti no programmēšanas vides var uzstādīt parametru cik ierakstus ar vienu fetchu atlasīt, jo pie lielākiem ierakstu daudzumiem visu vienā piegājienā iekopēt atmiņā ir diezgan killerisks pasākums, kā izskatās par to pat kāds ir pamanījies MySQL bugu iesniegt. Šeit diemžēl ir tas pats. Protams, ka kaut kādā lapiņā, ko kāds atvērs pāris reizes dienā, tas it kā ir nebūtiski. Bet problēma ir tā, ka šāds izstrādātājs ar šādām zināšanām nekad nevarēs izdarīt neko vairāk, vai arī izdarīs to ļoti slikti. Un darot slikti un nepareizi mazas lietas, darīs slikti un nepareizi arī lielas. Gints Plivna http://datubazes.wordpress.com

Šai kodā ir vismaz 2 lietas no tām 7, par ko reiz rakstīju, kursori (BTW vēl trakāk cikls ciklā jeb kursors kursorā) un visu kolonu atlasīšana, kaut gan reāli nepieciešamas tik 2. Vismaz par to pirmo es teiktu, ka jebkurā kaut cik normālā projektā koderim būtu jādod maksimums 1 brīdinājums un iespēja pierādīt sevi, pēc otrās reizes sakot ardievas, jo pēc tam ieguldāmais darbs koda labošanā visdrīzāk stingri pārsniegs ieguvumu no konkrētā programmētāja. Gints Plivna http://datubazes.wordpress.com

BTW tur ir arī par velti RDBMS koncepti un ANSI SQL pamatu tests, kā jau rakstīju pirms kāda brīža :) Gints Plivna http://datubazes.wordpress.com/

Man patīk un es lietoju (un BTW tas tiek uzskatīts par labu praksi) - lietot tabulu un kolonu nosaukumus, kas nav rezervētie vārdi, tādējādi man nav jālieto ne apostrofi, ne pēdiņas (Oraclē) ne arī kādā citā veidā jāmuhļījās un jācīnās ar paša radīto problēmu sekām. Un tas attiecas arī uz citiem cilvēkiem, kas nāks pēc manis un turpinās uzturēt manis izveidoto kodu. Līdzīgu tēmu jau es reiz apskatīju rakstā Par objektu (ne)nosaukumiem. Gints Plivna http://datubazes.wordpress.com

Jā tikai kāpēc radīt sev problēmas, lai vēlāk tās drosmīgi pārvarētu??? Nav kaut kādas mazohisma tendences? ;) Gints Plivna http://datubazes.wordpress.com