| From: | Chris Angelico <rosuav(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: DEFERRABLE NOT NULL constraint |
| Date: | 2013-02-05 13:13:20 |
| Message-ID: | CAPTjJmpWamOaF1TzhRL1o4nfsuG6uFLnUv3jTH5Bo4y6+qaQ4A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Feb 5, 2013 at 11:32 PM, Alban Hertroys <haramrae(at)gmail(dot)com> wrote:
> On 5 February 2013 12:41, Andreas Joseph Krogh <andreak(at)officenet(dot)no> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bèrto ëd Sèra | 2013-02-05 13:20:35 | Re: DEFERRABLE NOT NULL constraint |
| Previous Message | Bèrto ëd Sèra | 2013-02-05 13:12:31 | Re: DEFERRABLE NOT NULL constraint |