andrisp Posted February 22, 2008 Report Posted February 22, 2008 Tik kāds tam sakars ar te runāto.. :)
Mikijs Posted February 22, 2008 Author Report Posted February 22, 2008 daudz nestasti es but domat ka pgsql sux , jo mysql ir pardomataks un visiem labak saprotams, jo es piemeram atnacu stradat ka programmetajs ar mysql zinasanam un te peksni man kkur vajadzigs pgsql ir gruti iebraukt vinja un tur psc :D kas tas par stulbumu nevis "auto_incriitments" bet kkadas fufelis "sequence./"
Mikijs Posted February 22, 2008 Author Report Posted February 22, 2008 :D no adrisp shitadu tekstu :D nebutu gaidijis :D domaju ka tulit bus gars teksts "Mikijs!!!!! Ko tu tur muldi :D"
GedroX Posted February 22, 2008 Report Posted February 22, 2008 Es nesaku, ka MySQL sux. Es saku, ka pašlaik, ja man būtu jāuzsāk kāds nopietnāks projekts un būtu izvēle starp abiem, es izvēlētos pgsql. Maza projekta gadījumā varētu arī mysql. Mikijs ----> es sākumā par pgsql biju tādās pašās domās. Rnājot par auto_increment -- pgsql vari uzdot tipu SERIAL (vai BIGSERIAL, ja nopietnāka tabula) un sequence tiks izveidota automātiski.
Mikijs Posted February 22, 2008 Author Report Posted February 22, 2008 To, ka MySQL sux, un PgSQL rullz. Mes gaidam tavu komentu
andrisp Posted February 22, 2008 Report Posted February 22, 2008 (edited) Es nesaku, ka MySQL sux. Es saku, ka pašlaik, ja man būtu jāuzsāk kāds nopietnāks projekts un būtu izvēle starp abiem, es izvēlētos pgsql. Maza projekta gadījumā varētu arī mysql. Nu bet kāds tam sakars ar standartu izmantošanu/neizmantošan SQL kodā ?? Mes gaidam tavu komentu Mikijs, domāju, ka bubu to domāja ironiski. Edited February 22, 2008 by andrisp
GedroX Posted February 22, 2008 Report Posted February 22, 2008 Kāds sakars? Tas sākās ar tavu teikumu "Iespējams, arī tu.". :P ..un beidzas ar šo punktu ---->.
Grey_Wolf Posted February 22, 2008 Report Posted February 22, 2008 (edited) kas tas par stulbumu nevis "auto_incriitments" bet kkadas fufelis "sequence./" sekvencei ir virkne prieksrocibu ... zinasi kaads ID tiks izmantots... lidzarto daudzos gadijumos tas atvieglo dzivi ... piedevam ka jau GedroX mineja to var vienkarshi automatizet... --- Ja runa ir par to kadu DB izmantot tad tas jau dazreiz ir vienkarshi gaumes / iespeju jautajums... parsvaraa 99% gadijumu tas ir pilniba vienalga..... --- par migresanu --> nepiekritishu ka 100% ieverojot standartus parnesot DB buus mazak darba jo: kad pienak Vajadziba migret uz citu DB tad arii dati ir japarnes un ir citas nelaimes... piedevam ja projekts sasniedzis tadu stadiju ka Nopietni japsver par DB mainju --> tad arii Sen jau buus paradijusas dota projekta nepilnibas --> secinajums vieglak izveidot Jaunu "modernaku" strukturu utt.... --- taka bezjedzigi kautko minet par to ka tas atvieglos dziivi.... Edited February 22, 2008 by Grey_Wolf
andrisp Posted February 22, 2008 Report Posted February 22, 2008 Tas mans PS. attiecās uz visām DB sistēmām. Kaut vai ja runājam par tām pašām pgsql sekvencēm, tad te http://www.postgresql.org/docs/8.1/static/...tesequence.html redzam, ka ir lietas, ko standartiem atbilstošā veidā nemaz nav iespējams izdarīt. (Skatīt pašā apakšā). Tu arī tā neatbildēji, kāpēc tik svarīgi ir pieturēties pie SQL standartiem.
Roze Posted February 22, 2008 Report Posted February 22, 2008 10 gadu laikā ķēpājoties ar visādiem risinājumiem (iekš java/php/c/python utt) gan enterprise gan small ar visādām iespējamām DBVS (aka oracle, mysql, db2, ms sql, pgsql utt) neesmu sastapis nevienu projektu kur: a) produkta/risinājuma darbības laikā ir radusies nepieciešāmība migrēt uz citu DB vidi b) ja šāda nepieciešamība tomēr ir radusies - parasti tas ir beidzies arī ar paša aplikācijas koda maiņu vai atteikšanos no tā vispār. Līdz ar to risinājumi, kuri piedāvā multi-db-backendu atbalstu visbiežāk aprobežojas tikai ar visādiem weblogiem/cms, jo enterprise tooļi parasti izvirza ļoti konkrētas prasības pret vidi (gan pret dbvs, gan hardwari utt). Uzskatu par diezgan muļķigu domu rakstot savus produktus sākt domāt par 10 DBVS produktiem. Pirms darba sākuma ir jāizvēlas viens visvairāk piemērotais un tad arī jāizmanto maksimāli visas tās iespējas.. Rakstīt generic kodu ir varbūt labi, bet tas nekad nebūs ātrākais. Kāpēc piemēram neizmantot LIMIT ja tāds ir pieejams? Kāpēc veidot 3 subselectus.. (ir gan protams redzēts kods kurā atkarībā no izmantotās db mainās SQL.. bet nut). Ja SQLite piedāvā inmemory DB pa taisno bez servera, kāpēc to neizmantot? Utt utt Nedaudz arī jāpasmīn par tiem DBVS, kas domāti "nopietnajiem" projektiem.. Lielākoties jau visiem ir identiskas iespējas viss atšķiras tikai faktā, ka vismaz līdz šim "nopietnajiem" DB produktiem līdzi nāk arī nopietni DBA (kas arī visu izšķir), jo sakarā ar to ka (piem Oracle gadijumā) produkts kā tāds maksā zināmas naudiņas un konkrētā DB admina sertifikāta iegūšana nav lēts prieks (līdz ar to faktiski atkrīt iespēja mirstīgam jūzerim/pokemonam to iekurbulēt) - un galā tas izskatās ļoti nopietni ;) Nezinu kā ar PgSQL (tur gan ir daži "forkoti" enterprise produkti, kas piedāvā apmācību/supportu), bet es pieņemu ka šajā sfērā Sun ar MySQL ar kaut ko izmainīs..
bubu Posted February 22, 2008 Report Posted February 22, 2008 es but domat ka pgsql sux , jo mysql ir pardomataks un visiem labak saprotams, jo es piemeram atnacu stradat ka programmetajs ar mysql zinasanam un te peksni man kkur vajadzigs pgsql ir gruti iebraukt vinja un tur psc :D kas tas par stulbumu nevis "auto_incriitments" bet kkadas fufelis "sequence./" Gribētos redzēt, ko tu teiktu, kad tevi pieliktu pie Oracle :)
IM24LV Posted February 22, 2008 Report Posted February 22, 2008 mhmm, es, duraks, domaaju ka mysql ir labakais :D bet redz ka eksperti saka ka taa nemaz nav. tad veel izraadiisies ka php arii nav tas labaakais :D njaa :(
Grey_Wolf Posted February 22, 2008 Report Posted February 22, 2008 IM24LV--> Nav labaku un sliktaku Risinajumu ... Ir tikai Piemeroti un nepiemeroti risinajumi....
Recommended Posts