Covering an entire table with an index?

#21

On 12/4/2011 8:44 AM, Doug Miller wrote:

Quote:

On 12/3/2011 11:43 PM, Jerry Stuckle wrote:

And by changing the primary key as you suggest, you have removed the
restriction that the first column be unique. It is now possible to
create items like I showed.

Your suggestion can totally screw up his database.

Nonsense. It might make it easier for *him* to screw it up -- but I
think there's plenty of room to make the argument that it's screwed up
already.

I don't see anything wrong with his current implementation. And the
purpose of a primary key or unique constraint is to prevent things like
your "suggestion" allows.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

#22

On 12/4/2011 9:32 AM, Jerry Stuckle wrote:

Quote:

On 12/4/2011 8:44 AM, Doug Miller wrote:
On 12/3/2011 11:43 PM, Jerry Stuckle wrote:

And by changing the primary key as you suggest, you have removed the
restriction that the first column be unique. It is now possible to
create items like I showed.

Your suggestion can totally screw up his database.

Nonsense. It might make it easier for *him* to screw it up -- but I
think there's plenty of room to make the argument that it's screwed up
already.

I don't see anything wrong with his current implementation. And the
purpose of a primary key or unique constraint is to prevent things like
your "suggestion" allows.

You don't see anything wrong with a table with four columns, a, b, c,

and d, with primary key (a) *and* an index on (a, b, c, d) ??

Wow.

#23

On 12/4/2011 9:32 PM, Doug Miller wrote:

Quote:

On 12/4/2011 9:32 AM, Jerry Stuckle wrote:
On 12/4/2011 8:44 AM, Doug Miller wrote:
On 12/3/2011 11:43 PM, Jerry Stuckle wrote:

And by changing the primary key as you suggest, you have removed the
restriction that the first column be unique. It is now possible to
create items like I showed.

Your suggestion can totally screw up his database.

Nonsense. It might make it easier for *him* to screw it up -- but I
think there's plenty of room to make the argument that it's screwed up
already.

I don't see anything wrong with his current implementation. And the
purpose of a primary key or unique constraint is to prevent things like
your "suggestion" allows.

You don't see anything wrong with a table with four columns, a, b, c,
and d, with primary key (a) *and* an index on (a, b, c, d) ??

Wow.

Nope, nothing wrong with the *table*. I question the need for the
*index*, but that's something entirely different.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

#24

On 12/4/2011 9:35 PM, Jerry Stuckle wrote:

Quote:

On 12/4/2011 9:32 PM, Doug Miller wrote:
On 12/4/2011 9:32 AM, Jerry Stuckle wrote:
On 12/4/2011 8:44 AM, Doug Miller wrote:
On 12/3/2011 11:43 PM, Jerry Stuckle wrote:

And by changing the primary key as you suggest, you have removed the
restriction that the first column be unique. It is now possible to
create items like I showed.

Your suggestion can totally screw up his database.

Nonsense. It might make it easier for *him* to screw it up -- but I
think there's plenty of room to make the argument that it's screwed up
already.

I don't see anything wrong with his current implementation. And the
purpose of a primary key or unique constraint is to prevent things like
your "suggestion" allows.

You don't see anything wrong with a table with four columns, a, b, c,
and d, with primary key (a) *and* an index on (a, b, c, d) ??

Wow.

Nope, nothing wrong with the *table*. I question the need for the
*index*, but that's something entirely different.

I guess on your planet the index isn't part of the implementation...

#25

On 12/4/2011 9:46 PM, Doug Miller wrote:

Quote:

On 12/4/2011 9:35 PM, Jerry Stuckle wrote:
On 12/4/2011 9:32 PM, Doug Miller wrote:
On 12/4/2011 9:32 AM, Jerry Stuckle wrote:
On 12/4/2011 8:44 AM, Doug Miller wrote:
On 12/3/2011 11:43 PM, Jerry Stuckle wrote:

And by changing the primary key as you suggest, you have removed the
restriction that the first column be unique. It is now possible to
create items like I showed.

Your suggestion can totally screw up his database.

Nonsense. It might make it easier for *him* to screw it up -- but I
think there's plenty of room to make the argument that it's screwed up
already.

I don't see anything wrong with his current implementation. And the
purpose of a primary key or unique constraint is to prevent things like
your "suggestion" allows.

You don't see anything wrong with a table with four columns, a, b, c,
and d, with primary key (a) *and* an index on (a, b, c, d) ??

Wow.

Nope, nothing wrong with the *table*. I question the need for the
*index*, but that's something entirely different.

I guess on your planet the index isn't part of the implementation...

It's not necessarily part of the TABLE design. The presence or absence
of a non-unique index has no bearing on the code used to access the
table or operation. The ONLY think it will affect is performance.

But you really don't seen to understand database design.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

#26

On Sun, 04 Dec 2011 21:46:30 -0500, Doug Miller wrote:

Quote:

On 12/4/2011 9:35 PM, Jerry Stuckle wrote:

Nope, nothing wrong with the *table*. I question the need for the
*index*, but that's something entirely different.

I guess on your planet the index isn't part of the implementation...

The application and interaction with the database will be exactly the
same with or without indexes. The PERFORMANCE will be different, but
that will be different with many other things that are not part of the
design either, such as what engine is used, how much RAM the host has,
and how fast the connection between the DB host and the application
is. Maybe indexes are part of the implementation in a strictly literal
sense, but they're not (IMHO) part of the structure/design.

--
84. I will not have captives of one sex guarded by members of the
opposite sex.
--Peter Anspach's list of things to do as an Evil Overlord

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Covering an entire table with an index?

comp.databases.mysql comp.databases.mysql

Re: Covering an entire table with an index? - 12-04-2011 , 08:32 AM

Re: Covering an entire table with an index? - 12-04-2011 , 08:32 PM

Re: Covering an entire table with an index? - 12-04-2011 , 08:35 PM

Re: Covering an entire table with an index? - 12-04-2011 , 08:46 PM

Re: Covering an entire table with an index? - 12-04-2011 , 09:02 PM

Re: Covering an entire table with an index? - 12-04-2011 , 09:42 PM