Re: constraint with reference to the same table

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.
>
>  
>