Oh! Nice! I really like the secondary index approach. A bit manual, but at least I can tweak it the way I want...
Thanks for the reply! Seems that I will have to read again the section about the timestamp because it might be very helpful for me. Regarding the key, for me it's a MD5 of a long string. So I will not be able to search by this key. Because using the string as the primary key, which can be as long as 2048 bytes, might be a bit to much for the table. That mean I will not be able to do any search on this table using the primary field. The main goal is mainly to have a way to insert data quicky into the table. Since I will still have to retrieve the data at some point, I have one last question regarding the filters. Let's say I have table like "FirstName", "LastName", "BirthDate", "Sexe" with everyone on the earth into this table. About 7 billions of lines. A key can be the concatenation of those 4 fields, that's fine. But let's say I want to search by sexe. I will need to build a secondary index. Still fine. Bot how can I do that? Can I insert one row for male with all the names in separate columns, and same for females? Is that doable to have hundred of millions of columns for one row? But then what should the column ID be? I can use the FirstName and LastName but they are long and it's recommended to keep that as short as possible. Basically, I'm fine with 1 to 1 relations both directions to build the indexs, but when it's 1 to n then how show that be done? JM
