 | |
#231
 
| |||
| |||
|
Re: index -
07-30-2008
, 10:30 AM
|
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? |
Quote:
|
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. |
#232
| |||
| |||
|
|
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? |
Quote:
|
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. |
#233
| |||
| |||
|
|
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? |
Quote:
|
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. |
#234
| |||
| |||
|
|
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? |
Quote:
|
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. |
#235
| |||
| |||
|
|
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? |
Quote:
|
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. |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.