0
101 Apr 11, 2007 at 16:28

I am writing a conversion formula to conversion from 10-digital unique id to 8 digital id and verse vice.

Can somebody advise me where to find the solution.

#### 12 Replies

0
101 Apr 11, 2007 at 20:22

What do you mean by n-digital ?

Assuming that by this you mean converting a number with n digits to a number with m digits, given n > m, while maintaining uniqueness, I’m afraid this is not possible, since there are more unique numbers that can be formed with n digits than can be formed with m digits.

If you may lose uniqueness in the conversion process, have a look at the various hashing methods. The easiest solution probably would be modulo operations, which essentially cut off the highest-significant digits.

If you mean something else, please provide some more details on what you would like to do.

Cheers,
- Wernaeh

0
101 Apr 11, 2007 at 21:39

Or do you maybe mean base 10 (decimal) to base 8 (octal)? (just a guess)

0
101 Apr 12, 2007 at 03:29

Thanks for roel and Wernaeh replies.

There is a database using 10-digital length as a unqiue identifier for records. However, it requirs to link (as a key) with other old object which only allows 8-digital length identifier. I need to maintain the uniquenss both in 10-digital & 8-digital data.

I think roel’s suggestion base 10 (decimal) to base 8 (octal) will work. Please advise where to find the conversion formula.

0
102 Apr 12, 2007 at 06:22

Do you mean 10 digits, 10 bits, base-ten or something else entirely? “10-digital length” is nonsensical. Try reading these articles and rephrasing your question.

EDIT: This one may be handy if Wernaeh’s interpretation of your question is correct: http://en.wikipedia.org/wiki/Hash_function

0
101 Apr 12, 2007 at 10:02

Thanks for roel and Wernaeh replies.

There is a database using 10-digital length as a unqiue identifier for records. However, it requirs to link (as a key) with other old object which only allows 8-digital length identifier. I need to maintain the uniquenss both in 10-digital & 8-digital data.

I think roel’s suggestion base 10 (decimal) to base 8 (octal) will work. Please advise where to find the conversion formula.

No, I don’t think this will work. Essentially, regardless of the actual representation of your data, and regardless of the base used, the number of unique entries is determined by the length - in digits - of the unique identifier.

I think the easiest solution to your problem would be to reserve a range for old objects, and add all new objects to other ranges.

Say, your digits are numbered as 0000000000 up to 1111111111 (assuming by digital, you also infer a binary system, but the same scheme easily extends to other systems). Then, reserve a certain prefix for old objects, for example, the prefix 00. All old objects (i.e. old IDs 00000000 to 11111111) are then stored as 0000000000 up to 0011111111. All new objects then use the remaining range from 0100000000 up to 1111111111, i.e. have a prefix that is not 00.

Hope this helps.

Cheers,
- Wernaeh

0
101 Apr 13, 2007 at 15:01

If the condition allow us to treated 8-digital id as 8 alpha-numerical length id and the 10-digital id can be treated as 10 numerical length id, is it possible to work out the conversion.

I recall in the old days, we used DOS operation system which only allows 8.3 character length for a filename. Whist a file created in NTFS file system which has filename longer than 8.3 character can be viewed in DOS operation system in 8.3 format. Can this method be used in the above situation.

0
101 Apr 14, 2007 at 00:39

If the condition allow us to treated 8-digital id as 8 alpha-numerical length id and the 10-digital id can be treated as 10 numerical length id, is it possible to work out the conversion.

If you take e.g. a hex system (base 16) then the biggest number you could display with 8 digits is FFFFFFFF witch is 4294967295 in a decimal system.

So if you define a base using all caracters from the alphabet you would get a base of 36 (0 - Z). Then the biggest number you could display with 8 digits becomes ZZZZZZZZ. This should be bigger than what you could represent in a decimal system with 10 digits (9999999999).

If I didn’t misunderstand your problem, I would say this works. You should be able to do it.

0
101 Apr 14, 2007 at 00:51

Thanks for moe.

You have solved the problem.

0
102 Apr 18, 2007 at 04:09

:lol: I’m completely confused. What just happened in this thread? :wallbash:

0
165 Apr 18, 2007 at 04:33

My guess is the poster had a database with 10-digit numeric IDs and another with 8-character alphanumeric IDs…it seems that representing 10-(decimal)digit numbers using 8-digit base 36 values lets him keep the two in sync.

0
118 Apr 18, 2007 at 05:18

Or alternatively someone is confused, makes a solution that seems to work, but breaks totally couple years down the line. =)

0
101 Apr 18, 2007 at 12:23

Earlier in this thread it has been established that you can not put a bigger number into a smaller one if the bigger number is more than the system with smaller values can handle. I think the problem was to convert the 10 digit into an 8 digit number. Since he usese alpha-numeric values for the 8 digit number he can represent a bigger value in the 8 digits than he can in the 10 digit numeric value.

As long as nelsonyam1935 is aware that the biggest number he can use is the biggest value from the one system, witch is capable to hold the smaller biggest value, he should be fine. (That was a confusing sentence :) ).

He mentioned that the newer Database is using the 10 digit numeric value. Therfore he should be pretty safe, as you can assume you rather get new values from the new database and convert it into the old one. Hence, you convert the 10 digits decimal into a 8 digit with base 36. (smaller into bigger). However, you are right, without a check not to use an invalid number, he might run into a problem down the road.

Also, I mentioned I was not sure I got the problem right ;) It was just a suggestion…

I’m going by the thread title here: conversion of 10-digital id to 8-digital id
Only one directional conversion not backwards :)

Edit:
I felt like I need to be more specific.
If you assume the new database delivers the new values you never get one bigger than 9999999999. So the backwards conversion from the old db into the new one will only be for sync reasons. You could assume that this number already fits into a decimal system. Even so the 8 digital alpha-numeric value theoretically could hold a bigger number.
One directional conversion for the new values and two directional conversion for sysc-ing the two db’s.