t;[EMAIL PROTECTED]>
Cc: "PFC" <[EMAIL PROTECTED]>; "Michael Glaesemann" <[EMAIL PROTECTED]>;
"Rodrigo Sakai" <[EMAIL PROTECTED]>;
Sent: Wednesday, April 12, 2006 5:59 PM
Subject: Re: [PERFORM] FOREIGN KEYS vs PERFORMANCE
> On Wed, Apr 12, 2
Jim C. Nasby wrote:
No, I don't agree with this. Too many people waste time designing for
"what if..." scenarios that never happen. You don't want to be dumb and
design something that locks out a foreseeable and likely future need, but
referential integrity doesn't meet this criterion. There
On Wed, Apr 12, 2006 at 10:36:28AM -0700, Craig A. James wrote:
> Jim C. Nasby wrote:
> >>1. You have only one application that modifies the data. (Otherwise, you
> >>have to duplicate the rules across many applications, leading to a
> >>code-maintenance nightmare).
> >
> >You forgot something:
Jim C. Nasby wrote:
1. You have only one application that modifies the data. (Otherwise, you
have to duplicate the rules across many applications, leading to a
code-maintenance nightmare).
You forgot something:
1a: You know that there will never, ever, ever, ever, be any other
application th
On Wed, Apr 12, 2006 at 07:45:17AM -0700, Craig A. James wrote:
> All good advice, but... there are no absolutes in this world.
> Application-enforced referential integrity makes sense if (and probably
> ONLY if):
>
> 1. You have only one application that modifies the data. (Otherwise, you
>
On Wed, Apr 12, 2006 at 09:22:52AM +0200, PFC wrote:
>
> >> I think this is an old question, but I want to know if it really is
> >>well worth to not create some foreign keys an deal with the referential
> >>integrity at application-level?
>
> Trust me : do it in the application an
On Wed, 2006-04-12 at 09:49, Rodrigo Sakai wrote:
> Thanks for all help!! But my problem is with performance, I agree with all
> of you, the RI must be maintained by the database, because a bunch of
> reasons that everyone knows!
> But, I'm dealing with a very huge database that servers more th
What kinds of operations are made slow by foreign key checks ? Is it :
- Simple checks on INSERT ?
- Simple checks on UPDATE ?
- Cascaded deletes ?
- Cascaded updates ?
- Locks ?
- Something else ?
Foreign keys are to ensure that the value
On Apr 12, 2006, at 23:49 , Rodrigo Sakai wrote:
Thanks for all help!! But my problem is with performance, I agree
with all
of you, the RI must be maintained by the database, because a bunch of
reasons that everyone knows!
You've gotten a variety of good advice from a number of people. Fo
On 4/11/06, Rodrigo Sakai <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I think this is an old question, but I want to know if it really is well
> worth to not create some foreign keys an deal with the referential integrity
> at application-level?
> Specifically, the system we are developing is
ginal Message -
From: "Markus Schaber" <[EMAIL PROTECTED]>
To:
Cc: "Rodrigo Sakai" <[EMAIL PROTECTED]>
Sent: Wednesday, April 12, 2006 10:18 AM
Subject: Re: [PERFORM] FOREIGN KEYS vs PERFORMANCE
> Hi, Michael,
> Hi, Rodrigo,
>
> Michael Glaesemann w
I think this is an old question, but I want to know if it really
is well worth to not create some foreign keys an deal with the
referential integrity at application-level?
Trust me : do it in the application and you'll enter a world of
hurt. I'm doing it with some mysql apps, and
Hi, Michael,
Hi, Rodrigo,
Michael Glaesemann wrote:
> If I had to choose between one or the other, I'd leave all referential
> integrity in the database and deal with the errors thrown when
> referential integrity is violated in the application. PostgreSQL is
> designed to handle these kinds o
I think this is an old question, but I want to know if it really is
well worth to not create some foreign keys an deal with the referential
integrity at application-level?
Trust me : do it in the application and you'll enter a world of hurt. I'm
doing it with some mysql apps, and i
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, Apr 12, 2006 at 08:06:17AM +0900, Michael Glaesemann wrote:
>> ... Anything you code in
>> your application is more likely to contain bugs or miss corner cases
>> that would allow referential integrity to be violated. PostgreSQL has
>> been
On Wed, Apr 12, 2006 at 08:06:17AM +0900, Michael Glaesemann wrote:
>
> On Apr 12, 2006, at 4:13 , Rodrigo Sakai wrote:
>
> > I think this is an old question, but I want to know if it really
> >is well worth to not create some foreign keys an deal with the
> >referential integrity at applica
On Apr 12, 2006, at 4:13 , Rodrigo Sakai wrote:
I think this is an old question, but I want to know if it really
is well worth to not create some foreign keys an deal with the
referential integrity at application-level?
If I had to choose between one or the other, I'd leave all
ref
On Tue, 2006-04-11 at 14:13, Rodrigo Sakai wrote:
> Hi,
>
> I think this is an old question, but I want to know if it really is
> well worth to not create some foreign keys an deal with the
> referential integrity at application-level?
> Specifically, the system we are developing is a s
Hi,
I think this is an old question, but I want
to know if it really is well worth to not create some foreign
keys an deal with the referential integrity at
application-level?
Specifically, the system we are developing
is a server/cliente architecture that the server is the datab
19 matches
Mail list logo
