0

I'm developing one system, where Badges will be created with a QRCode for each User, and I need to read that QRCode and show specific information to the user on the public screen.

QRCode reading is a little 'tricky'. When I did something like this, I was using MySQL with enumerated Ids (1, 100, 2304, 9990)... Witch is only about 5 characters.

However, MongoDB keys (DB that I'm using now) consists of a biggg key such as 52d35bf26bda8a5c8f8a22a8 witch has MANY characters.

What is the problem with that: QRCode becomes larger (more data, bigger the size), and becomes harder to read it fast on the WebCam (even in HD).

So, here is my idea: Use part of the Id, So that: 52d35bf26bda8a5c8f8a22a8 becomes perhaps 52d35bf26bd.

The question is really simple: Can I safely use the partial ID Key, without having re-occurrences? The maximum elements I will have, will be about 1000 order.

The question has has nothing to do with QRCode, but it explains the reason why I'm doing it.

Ivan Seidel
  • 2,394
  • 5
  • 32
  • 49
  • No... clipping the ObjectId and using it as an unique identifier is a bad idea. It might be better hashing it to the size you desire (collisions still possible). You can read how the ObjectId is constructed here: http://docs.mongodb.org/manual/reference/object-id/ – joao Feb 14 '14 at 19:40
  • @joao , looks like ObjectID ends with a 3byte counter, witch starts random, but it's not conflictable. Am I right? – Ivan Seidel Feb 14 '14 at 19:50
  • If you have more than 1 document inserted in the same second, machine, and process they will collide if you remove that. This is a pretty risky situation because having more than 1 insert in 1 second is pretty easy to achieve... – joao Feb 14 '14 at 19:57
  • Ah, I just understood what you meant... Yes, it's a counter so every time it should be incremented or something like that. Only the initial value is random. – joao Feb 14 '14 at 20:01
  • Yes @joao ^^ If I don't exeed 24bits of documents, should be safe, right? oO – Ivan Seidel Feb 14 '14 at 20:02
  • possible duplicate of [mongodb part of objectid most likely to be unique](http://stackoverflow.com/questions/21498479/mongodb-part-of-objectid-most-likely-to-be-unique) – WiredPrairie Feb 14 '14 at 20:04
  • 1
    @IvanSeidel there will only be conflicts if you have more than 24bits (16777216) of documents inside the same second. That is highly improbable :) – joao Feb 14 '14 at 20:08
  • If you have only 1 machine and mongo process running you can remove the 3-byte machine identifier and the 2-byte process id from the ObjectId. You can check @WiredPrairie 's answer to a similar question which is pretty good. Nevertheless, if you follow this approach and later want to scale you'll be in trouble. – joao Feb 14 '14 at 20:12
  • I will only use one machine for the Web, witch is the only place where things gets 'created' actually. So, no problem... – Ivan Seidel Feb 14 '14 at 20:18

3 Answers3

0

ObjectId is a 12-byte BSON type, constructed using:

a 4-byte value representing the seconds since the Unix epoch, a 3-byte machine identifier, a 2-byte process id, and a 3-byte counter, starting with a random value.

Once known that, it depends on the part of the objectId you choose and how many time will pass between the insertions.

Regards

CesarTrigo
  • 423
  • 1
  • 3
  • 10
0

Regardless of whether it's safe or not, the size difference between the QR codes isn't that great.

Using the full string will get you an image like: Big QR

Using half the characters produces a code like: Small QR

I would suggest that even the cheapest smartphone would be able to scan the larger of the two images - it's not very complex at all.

Terence Eden
  • 14,034
  • 3
  • 48
  • 89
  • Yes it is, because it's not a smartphone on a person hand that will be reading it. It will be a webcam, and people badges will be within a considerable distance, shaking, bended and reflecting lights... I have been doing this for over a year now, and this is what I can tell about it... The smaller the better. – Ivan Seidel Feb 15 '14 at 19:43
0

Yes, you can safely compress a long hexadecimal string into a higher base to get fewer characters while retaining the same value.

Example:

Hex: 52d35bf26bda8a5c8f8a22a8

Base64: UtNb8mvailyPiiKo

The same idea can be taken further by using binary or even Chinese pictograph characters instead of base64.

This concept can be tested using a Numeral Base Converter Tool.

Eddie
  • 1,428
  • 14
  • 24