On Tue, Feb 5, 2013 at 11:32 PM, Alban Hertroys <haramrae@xxxxxxxxx> wrote: > On 5 February 2013 12:41, Andreas Joseph Krogh <andreak@xxxxxxxxxxxx> wrote: >> >> There are lots of things you can do, but when it's the ORM which does it >> you have limited control, and that's the way it should to be (me as >> application-developer having to worry less about such details). > > In that case it's your ORM that needs fixing, not the database. Agreed. One of the differences between MySQL and PostgreSQL is that the latter gives you a database with rules, while the former is a place for an application to store data. This last couple of weeks I've been working with a really sloppily-built application (and a very popular one too, so I won't name names), and it fits MySQL perfectly... What I'd much rather do is build real rules that may not EVER be violated. While I can see the value in deferring foreign key constraints (circular references - never used 'em though), I don't see any reason to create a record with a NULL and then replace that NULL before committing. Sort out program logic first; then look to the database. Making people's lives easier in the short term is NOT the greatest goal of a database. Consistent data will make the admins' lives far easier in the long term. I do not ever want to have to deal with BTrieve file corruption in my life. ChrisA -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
