Is uniqid() way to long for fast database access?

[JackRockerfeller]

Hi,

I'm programming a website called boomblu and it uses uniqid() with a prefix and more_entropy set to true for almost every widget and pages. In brief, every page has it's "uniqid" and when we load a page, we SELECT every widgets WHERE pageId = '$thePageWeWant'.

When I started the project, I was feeling pretty ambitious about my site so I did not want to run off of Ids for the content. But now I realize that Youtube addresses millions of videos only with a 11 character string. However, now I realize that this choice could slow down my site while making the database unnecessarily bigger.

Should I change uniqid() right now to a smaller random string? Or would it take an enormous amount of data to slow my site down so I shouldn't worry about it?

[egami]

regardless of what your string is, your table obviously has a "key". Why not use that "Key" since the table already uses it to index. They are unique, and will grow as big is BIGINT can be. (that's big.)

[egami]

ie.
The max size of an unsigned integer in MySQL is 4,294,967,295
The max size of an unsigned BIGINT is 18,446,744,073,709,551,615

I'm fairly certain that unless you're Google, Microsoft, Oracle etc.. that the amount of rows you have will never reach BIGINT capabilities.



Enjoy.