++ Zberteoc for the link to the comparison. w.r.t. using triggers/procedures. If a database is getting updated by multiple applications then using triggers/procedures to move duplicated business rules into the database starts to make some sense-- even more so if you don't have good control over all the applications that are doing the updating.
On Sep 5, 6:25 am, Joshua Russo <josh.r.ru...@gmail.com> wrote: > Great site! thanks > > With my SQL experience, your comment about database coding seems to ring > true. The database is a much different environment, with > different paradigms, than a standard application environment. When you > really need database coding you know it (kind of like meta programming). > > So far from my experience has been, the times I found we needed database > programming were pretty simply speed related, so difficult to distinguish > from application logic. What types of situations do others find useful for > stored procedures and triggers? > > On Sat, Sep 5, 2009 at 9:57 AM, Zberteoc <zbert...@gmail.com> wrote: > > > This is a common mistake almost all non SQL developers make thinking > > in procedural/programming language terms in regards wit SQL and > > database coding. If you're asking me there is nothing cool in the > > feature of creating stored procedures in other than the SQL language. > > MS-SQL introduced that with 2005 version, CLR integration, but I is > > hardly used for one very simple reason it is NOT really necessary. SQL > > code needs to be understood first and only then look elsewhere. > > Anyways, in terms of comparison PgSQL vs MySQL here is a very detailed > > wiki: > > >http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL > > > I have never used PgSQL but i wouldn't hesitate to use it if I needed > > it. All DBMS these days are robust and mature enough to be able to > > rely on them. It comes in the end to what you prefer, how comfortable > > you feel and ease of use, rather than how many terrabytes they can > > deal with as the features lists are more and more the same for all of > > them. Support and online community is also very important, probably > > the most if you're novice in both, and here MySQL prevails as it is > > far more popular. > > > Cheers. > > > On Sep 4, 10:46 pm, Joshua Russo <josh.r.ru...@gmail.com> wrote: > > > Wow, that's a cool trick to be able to implement stored procedures in > > > different languages. I might actually use them more if I could do > > everything > > > in the same language as the application. > > > I only looked quickly through the PostgreSQL docs for subqueries. Thanks > > for > > > the heads up. > > > > As far as the Gis functionality goes, I could see a database like that > > > needing some serious horse power if it became popular. Any thoughts on > > how > > > that would reconcile with the weakness in replication? I suppose most Gis > > > systems are more for out put than input so the slow replication might not > > > really matter that much. > > > > On Sat, Sep 5, 2009 at 1:17 AM, Siemster <gregory.si...@pca.state.mn.us > > >wrote: > > > > > PostgreSQL does support subqueries in the from clause, however iirc, > > > > the subquerys require an alias. > > > > > If you decide to do geo then the PostGis addon to Postgres is very > > > > nice. > > > > > Another nice capability in PostgreSQL is that you can use different > > > > languages for writing your stored procedures (should you wish to use > > > > them). Some of the available languages (in addition to PL/pgSQL) are > > > > Perl, Python, Tcl, PHP, Ruby, R, Scheme, and Java. > > > > > Whether you choose to use Postgres or not, I'd recommend at least > > > > looking at it. There is even a live cd (which I have not tried) at > > > >http://www.postgresql.org/download/whichlets you try PostgreSQL out > > > > without having to install it. > > > > > On Sep 4, 7:38 pm, Joshua Russo <josh.r.ru...@gmail.com> wrote: > > > > > On Fri, Sep 4, 2009 at 11:07 PM, Tim Chase > > > > > <django.us...@tim.thechases.com>wrote: > > > > > > > > I personally don't have any experience with PostgreSQL and I'm > > > > generally > > > > > > > working in a mixed MS and Linux environment. I'm interested to > > hear > > > > > > peoples > > > > > > > views on the pluses and minuses of the two different systems. I'm > > a > > > > bit > > > > > > of a > > > > > > > query geek too. How does that play in? I know in MySQL there are > > > > > > limitations > > > > > > > on where you can use subqueries. Is that true with PostgreSQL? > > (Ya I > > > > > > could > > > > > > > just look that one up but it's just an example.) > > > > > > > I did a writeup of MySQL vs. PostgreSQL a while back: > > >http://www.mail-archive.com/django-users@googlegroups.com/msg70188.html > > > > > > > Most of the issues still stand -- though I understand MySQL now > > > > > > has native(ish) support for Geo information (check the GeoDjango > > > > > > code to see if it supports the MySQL Geo implementation -- last I > > > > > > checked the source it was Oracle & PostgreSQL only). > > > > > > > To answer your direct question, PostgreSQL has long-standing > > > > > > support for all kinds of crazy sub-queries. MySQL has added most > > > > > > of those abilities over time. This used to be a deal-breaker for > > > > > > me, making Postgres the clear winner. Now they're about even. > > > > > > > Lastly, my closing arguments in that link still stand -- if you > > > > > > don't have a pressing need to choose one or the other, code & > > > > > > test for both. > > > > > > Good point on geo side side of things. > > > > > > One place I have found subqueries very useful is in the From. > > > > Functionally > > > > > identical to a view but you don't need to clutter the database with > > > > rarely > > > > > used views. That and you can use variables. If you really wanted to > > get > > > > > fancy you can even nest them. It can save a lot on application logic > > and > > > > > produce some interesting reports. I don't believe either of our > > friends > > > > here > > > > > support them though. That is one feature I would love to see. > > > > > > I tend to agree with your closing arguments. I try to stay away from > > any > > > > > DBMS unique functionality. I very rarely even find much of a need for > > > > > triggers and/or stored procedures. (But they can come in > > exceptionally > > > > handy > > > > > when turning 10s of 1000s of rows of un-normalized data, into close > > to a > > > > > million rows of normalized. Done in a matter of minutes!) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
