Re: index
- From: "Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx>
- Date: Wed, 30 Jul 2008 11:30:02 -0400
"David BL" <davidbl@xxxxxxxxxxxx> wrote in message
news:c87f64b2-ceb3-4134-b3ca-93fa7c117359@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[snip]
It may be useful to look at an analogy in C++. Consider a bijection
between two integer attributes named x and y coded as follows:
class Bijection
{
public:
void insert(int x,int y) {xtoy[x]=y; ytox[y]=x;}
int getx(int y) {return ytox[y];}
int gety(int x) {return xtoy[x];}
private:
map<int,int> xtoy;
map<int,int> ytox;
};
As a systems programmer I have used this technique in various forms on
a number of occasions. I see a class instance as analogous to a
single ?table?, and the two maps as ?clustered indexes?. Each is
redundant with respect to the other. Both are needed for performance.
I think I see what you're driving at, even though your example is
broken:
Bijection b; int i, j, k, l;
b.insert(4, 3); b.insert(4, 5); b.insert(4, 7);
i = b.getx(3); // returns 4
j = b.getx(5); // returns 4
k = b.getx(7); // returns 4
l = b.gety(4); // returns 7
Yes of course I didn't bother worrying about repeats. However whether
one needs to test for that explicitly depends on the application. For
example in the past I have needed a transient bijection between GUID
and memory pointer and I could *assume* uniqueness of both in the
design.
Your example is illuminating--aside from the fact that it doesn't
operate as
its name suggests. I don't think it's thread safe: x ==
b.getx[b.gety[x]]
could sometimes return false. That highlights one of the pitfalls of
duplicating content.
Most classes in most OO programs are not threadsafe because they do
not need to be threadsafe. Imagine the performance hit if every
variable of every data type was protected with a mutex!
Don't scoff at that Bijection class. It is like a Lamborghini when
used in an appropriate context. Why use a general purpose off road
vehicle when you know you're only driving on the highway?
I wouldn't dream of it.
But the bottom line is that what is a clustered index in the
implementation
implied by the original poster's question differs from what you consider
to
be a clustered index.
Perhaps.
.
- References:
- index
- From: aarklon
- Re: index
- From: Bob Badour
- Re: index
- From: Brian Selzer
- Re: index
- From: David BL
- Re: index
- From: Brian Selzer
- Re: index
- From: David BL
- Re: index
- From: Brian Selzer
- Re: index
- From: David BL
- Re: index
- From: Brian Selzer
- Re: index
- From: David BL
- Re: index
- From: Brian Selzer
- Re: index
- From: David BL
- Re: index
- From: Brian Selzer
- Re: index
- From: David BL
- index