Jump to content
php.lv forumi

Vaitaad tiesam?


Mikijs

Recommended Posts

  • Replies 31
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

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./"

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by andrisp
Link to comment
Share on other sites

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 by Grey_Wolf
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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..

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites


×
×
  • Create New...