Victor,
>> May be it's better to name indexes a bit more clearer? No impact on overall
>> performance, but you'll ease your life, if you project will grow to hundreds
>> of tables and thousands of indicies.
Very true.
Instead of: b_pn_b_id_idx,
I think better would be: busines_person_b_id_idx
Thanks
Rudi.
Victor Yegorov wrote:
* Rudi Starcevic <rudi@oasis.net.au> [15.05.2003 04:46]:
Stephen,
New:
CREATE TABLE business_person
(
b_id integer REFERENCES business ON UPDATE CASCADE ON DELETE CASCADE NOT
NULL,
pn_id integer REFERENCES person ON UPDATE CASCADE ON DELETE CASCADE NOT NULL
PRIMARY KEY(b_id,pn_id);
);
CREATE INDEX b_pn_b_id_idx ON business_person (b_id);
CREATE INDEX b_pn_pn_id_idx ON business_person (pn_id);
May be it's better to name indexes a bit more clearer? No impact on overall
performance, but you'll ease your life, if you project will grow to hundreds
of tables and thousands of indicies.
As I'd like to sometime's look up business's, sometime's look up people and
sometimes
look up both I think I should keep the Index's.
If your lookups are part of business logic, than it's ok. Also, if your
system generates reports using several table joins that may speed up the
things.
Otherwise, for curiosity cases, it's better to wait some time for the result
of one-time queries.
