|
Home > Archive > SQL Anywhere Feedback > January 2006 > Combined PK/FK index
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Combined PK/FK index
|
|
| Breck Carter [TeamSybase] 2006-01-23, 8:23 pm |
| If a child table has the same columns in both the primary key and a
foreign key, please create only one index, not two as is currently
done.
This situation can arise in cases where a single entity is split into
a parent and one or more child tables with a 1:1 relationship between
the parent and each child.
One reason might be to move infrequently-referenced columns,
especially long strings and blobs, out of a frequently-referenced
parent table down into a separate child table. By cramming more rows
into a single page, queries on the parent table may run faster.
As far as I can tell, really is no good reason to have two indexes.
Breck
--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| anil k goel 2006-01-23, 8:23 pm |
| The following, and more as far as keys and indexes go, coming soon (in
Jasper).
-anil
"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
message news:mbeat1l9uhgannd
c4sjn9qlb8bh6vpr8id@
4ax.com...
> If a child table has the same columns in both the primary key and a
> foreign key, please create only one index, not two as is currently
> done.
>
> This situation can arise in cases where a single entity is split into
> a parent and one or more child tables with a 1:1 relationship between
> the parent and each child.
>
> One reason might be to move infrequently-referenced columns,
> especially long strings and blobs, out of a frequently-referenced
> parent table down into a separate child table. By cramming more rows
> into a single page, queries on the parent table may run faster.
>
> As far as I can tell, really is no good reason to have two indexes.
>
> Breck
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book:
> http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com
|
|
|
|
|