Em Qui, 2006-01-19 às 22:29 +0100, Martijn van Oosterhout escreveu:
> Possibly nowhere. But when you send invoices to customers, any details
> on there *are* immutable. Sure, in your database you don't care if
> things change, but then they don't match reality anymore do they?
Then what yo
Em Qui, 2006-01-19 às 09:54 +0900, Michael Glaesemann escreveu:
> On Jan 19, 2006, at 9:31 , Leandro Guimarães Faria Corcete Dutra wrote:
>
> If these are things
> you're interested in (and it certainly appears you are), why not
> contribute?
'Cause unfo
Em Qua, 2006-01-18 às 17:22 -0600, Jim C. Nasby escreveu:
> >
> > Forgive me my ignorance, but are ints inherently faster to compare than
> >strings, or is it just an implementation detail? Ideally, if this is so
> >a fully data-independent system would create a hash behind the back of
> >user
Andrew Dunstan dunslane.net> writes:
> If people would like to play, I have created a little kit to help in
> creating first class enum types in a few seconds.
Isn't what we actually want possreps?
---(end of broadcast)---
TIP 6: explain analyze
Greg Stark mit.edu> writes:
> I hate knee-jerk reactions too, but just think of all the pain of people
> dealing with databases where they used Social Security numbers for primary
> keys. I would never use an attribute that represents some real-world datum as
> a primary key any more.
I am not f
Jim C. Nasby pervasive.com> writes:
> a) the optimizer does a really poor job on multi-column index statistics
So it should be fixed?
And there are a *lot* of singular, natural keys.
> b) If each parent record will have many children, the space savings from
> using a surrogate key can be quit
Rod Taylor rbt.ca> writes:
> The basic idea is that most of us break out schemas by creating fake
> primary keys for the purpose of obtaining performance because using the
> proper primary key (single or multiple columns) is often very slow.
This is one thing I simply can't understand.
If you s
