On Dec 20, 2010, at 2:44 PM, Ricardo Aráoz wrote:
>>> No, of course not. But why would I not want to do a join?
>> Joins are slow.
>
> As compared to what? How does Postgres keep the info behind the scenes?
> And if it does not use Joins then it must use some other method that
> will slow you down on input or update or delete or join. After all,
> there are no free rides, otherwise everybody would be getting one.
This is Database Design 101.
Single-table reads are the fastest. Fully-indexed joins are slower,
followed by paritally-indexed joins, followed by unindexed joins.
Full normalization maximizes the number of joins required to retrieve
the data, and is generally avoided for more reasonable levels of normalization.
If you have a table with info on people, do you create separate FirstName,
MiddleName and LastName tables, and then only store the index to each part of
someone's name in the Person table? Or do you make a FirstName, etc., column,
and accept the fact that there will be multiple entries for some names (which
is a no-no for normalization)?
I don't know PostgreSQL's internals, but I've never come across a
database system in which a single-table read was not significantly faster than
a join.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
