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 you
Jim C. Nasby jnasby at 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
Greg Stark gsstark at 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
Andrew Dunstan andrew at 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
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 in order
Rod Taylor pg at 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
