• 0

c# Short URL from GUID


Question

Hello gang,

 

I am working on a new project for a site and I would like to implement short urls.  Historically I have used GUIDs as table ids so that replication is not an issue.  So, now I'm looking at creating a short url for these values, the thing is a shortened guid is not that short (vs a shortened Int) Before getting too far down a path, I thought I'd ask if anyone had any thoughts.

 

Thanks

Link to comment
https://www.neowin.net/forum/topic/1203663-c-short-url-from-guid/
Share on other sites

16 answers to this question

Recommended Posts

  • 0

Just generate strings of whatever size you consider to be short, made up of numbers, uppercase letters and lowercase letters, and associated them with your ID field.

 

[short_url_assoc_table]

table_id : GUID

short_url : string

  • 0
  On 06/03/2014 at 20:00, firey said:

What is it you are trying to do?

Like you have something say:

guasd3 = www.google.ca

-3idjqis = www.neowin.net

or?  

I guess I don't understand what you are trying to do exactly.

 

 

I need to use GUIDs as the table ident fields for the issue of replication.  If I use numeric values for the identity, which is easy to convert to a short URL by using Base64 (quite a number of examples around the net for doing this)  however if I use numeric I'm going to have collisions when multiple machines are making new records.  When I have looked at making a short url from a guid, the value is shorter than the GUID, but still longer than the average short GUID.

 

  On 06/03/2014 at 20:32, virtorio said:

Just generate strings of whatever size you consider to be short, made up of numbers, uppercase letters and lowercase letters, and associated them with your ID field.

 

[short_url_assoc_table]

table_id : GUID

short_url : string

 

Interesting idea, but this could be an issue with replication.  I am also concerned about multiple identity fields (waste of time, space, etc)   Thanks though

  • 0
  On 06/03/2014 at 21:16, James Rose said:

 

 

Interesting idea, but this could be an issue with replication.  I am also concerned about multiple identity fields (waste of time, space, etc)   Thanks though

 

What exactly is being replicated?

 

 

  On 06/03/2014 at 21:16, James Rose said:

I need to use GUIDs as the table ident fields for the issue of replication.  If I use numeric values for the identity, which is easy to convert to a short URL by using Base64 (quite a number of examples around the net for doing this)  however if I use numeric I'm going to have collisions when multiple machines are making new records.  When I have looked at making a short url from a guid, the value is shorter than the GUID, but still longer than the average short GUID.

What am I missing here? This shouldn't be an issue with a relational database. You don't tell your database what the ID of a row is, you let the database decide when it inserts the row(s).

  • 0

Im not sure where replication is happening.  Also why do you have to use guids for the identity, why not just use an incrementing number, and hash it's value or something to get the url you want to use?  Also, the database should be able to handle the ID itself.. and there should never be an issue of too many inserts causing problems.

  • Like 1
  • 0

Okay gang,

 

Replication of tables between multiple servers cannot use numeric values as, for example in SQL Server the Identity value is incrimented by 1 (and yes, you can change this value, but it wouldn't help when the app needs to scale)  Imagine two servers, each one adding new values to a table; "Customers" One each server they would both get identity #1 for the first record, when the two servers attempt to merge (ever hour, every minute, whenever) there would be a collision since there would be two records with the same identity value.  Using GUIDs for the key field avoids this issue as it is, almost, impossible to have the same guid twice.

 

 

Thanks Asik, however the "guidAsString" variable is still too long to be a short url.

  • 0

Looks like I found the answer.

                //Guid guid = Guid.NewGuid();
                string sGUID = "a33d4a21-7d95-41f7-859e-bf02b2fda650"
                string hashCode = String.Format("{0:X}", sGUID.GetHashCode());
                Console.WriteLine(hashCode);

This makes a nice small url, can anyone think of why this should not be used?

  • 0

^you shouldn't use it for the reasons listed here (about uniqueness guarantees and differences between versions): http://stackoverflow.com/questions/7458139/net-is-type-gethashcode-guaranteed-to-be-unique

 

Hash the GUID using SHA1 and truncate it or something like that. That's probably the best you are going to do. (perhaps you will have to truncate it to much, forcing a too high of probability for collision -- you should check the probability).

 

EDIT: Oh also, if you encode the result of hashing in a higher base, you reduce the amount of information loss during truncation.

  • 0
  On 06/03/2014 at 22:13, snaphat (Myles Landwehr) said:

^you shouldn't use it for the reasons listed here (about uniqueness guarantees and differences between versions): http://stackoverflow.com/questions/7458139/net-is-type-gethashcode-guaranteed-to-be-unique

 

Hash the GUID using SHA1 and truncate it or something like that. That's probably the best you are going to do. (perhaps you will have to truncate it to much, forcing a too high of probability for collision -- you should check the probability).

 

EDIT: Oh also, if you encode the result of hashing in a higher base, you reduce the amount of information loss during truncation.

 

EDIT:  Maybe what the article is saying, and what you are trying to tell me is that two different GUIDs could return the same hex?

 

 

 

Pardon me if I appear dense; I just read that article and ran some test against the same guid value for 1 billion iterations and it always comes up with the same hex.  I understand that 1 billion isn't necessarily that large a number...  what I am asking is shouldn't the hex value for a specific string always return the same hex value. 

 

Quote: "does not guarantee unique return values for different objects."  Since the app will pull the guid from the db, and then issue a hex on demand wouldn't that value always be the same?

 

Thanks for your input

  • 0
  On 06/03/2014 at 22:25, James Rose said:

Pardon me if I appear dense; I just read that article and ran some test against the same guid value for 1 billion iterations and it always comes up with the same hex.  I understand that 1 billion isn't necessarily that large a number...  what I am asking is shouldn't the hex value for a specific string always return the same hex value. 

 

Quote: "does not guarantee unique return values for different objects."  Since the app will pull the guid from the db, and then issue a hex on demand wouldn't that value always be the same?

 

Thanks for your input

 

It's the same each time because you are using the same version of the .net runtime on the same object for each run so it's producing the same hash. What they are saying is really two things: (1) if you switch versions of the .net runtime (e.g. 3.5 to 4), the returned result can be different for the same object, and (2) and within the same version of the runtime (e.g. 4) there can be collisions in hashes between different objects. There are no uniqueness guarantees.

 

So for example GUID_A.getHashCode() can return different results if you switch .net runtimes. And GUID_B.getHashCode() and GUID_C.getHashCode() could return the same result in the same runtime.

  • 0
  On 06/03/2014 at 22:31, snaphat (Myles Landwehr) said:

So for example GUID_A.getHashCode() can return different results if you switch .net runtimes. And GUID_B.getHashCode() and GUID_C.getHashCode() could return the same result in the same runtime.

 

yea, this is the answer I finally got to (see my edit above).  I was having a very hard time getting to the idea that a 30+ char piece of data could reliably be set to a shorter value.

  • 0
  On 06/03/2014 at 22:39, James Rose said:

yea, this is the answer I finally got to (see my edit above).  I was having a very hard time getting to the idea that a 30+ char piece of data could reliably be set to a shorter value.

Well in any case, you should re-encode whatever you do use to a higher number base that is still valid as url characters. For example, as I was saying before if you do the following you can store more information of your hash in less characters. 

String result=re_encode_as_base_X(SHA1_hash(GUID), N) //base 16 --> base N

I think at the end of the day, you will have to truncate though regardless of what you do. 

  • 0

It turns out I may be suffering from "doing this too long" desease.  Someone was kind enough to send a private message to me that the issue of replication on numeric  idenities may no longer be the issue it used to be.

 

I'm reading this article now:  http://technet.microsoft.com/en-us/library/ms146907%28v=sql.105%29.aspx

  • Like 1
  • 0
  On 06/03/2014 at 22:01, James Rose said:

Thanks Asik, however the "guidAsString" variable is still too long to be a short url.

I was suggesting taking the BigInteger and passing it through whatever method you mentionned that converted numerical values into short URLs, not taking it as a string directly. Anyway, looks like you found your answer.

This topic is now closed to further replies.
  • Posts

    • Generally, Earth never initiated that animals lay straight
    • Several UI improvements masquerading as a major update. I'm truly hating this trend.
    • OpenAI to use Google Cloud despite rivalry, diversifying beyond Microsoft by Paul Hill To help it meet its massive computing demands for training and deploying AI models, OpenAI is looking into a surprising partnership with Google Cloud to use its services. It was widely seen that OpenAI was Google’s biggest threat, but this deal puts an end to the idea that the pair are purely competing. The two companies haven’t made any public announcement about the deal but a source speaking to Reuters claimed that talks had been ongoing for a few months before a deal was finalized in May. Notably, such a deal would see OpenAI expand its compute sources beyond Microsoft Azure. Microsoft had arrangements in place with OpenAI since 2019 that gave it the exclusive right to build new computing infrastructure for the startup. This limitation was loosened earlier this year with the announcement of Project Stargate. OpenAI is now allowed to look elsewhere for compute if Microsoft is unable to meet the demand. A win for Google Cloud, a challenge for Google's AI strategy The deal will see Google Cloud supply computing capacity for OpenAI’s AI model training and inference. This is a big win for Google’s Cloud unit because OpenAI is a massive name in AI and it lends credence to Google’s cloud offering. It also justifies Google Cloud’s expansion of its Tensor Processing Units (TPUs) for external use. On the back of the news, Alphabet’s stock price rose 2.1%, while Microsoft’s sank 0.6%, showing investors think it’s a good move for Google too. While many end users don’t interact with Google Cloud the same way they do with something like Android or Chrome, Cloud is actually a huge part of Google’s business. In 2024, it comprised $43 billion (12%) of Alphabet’s total revenue. With OpenAI as a customer, this figure could rise even more given the massive amounts of compute OpenAI needs. By leveraging Google’s services, it will also give OpenAI access to the search giant’s Tensor Processing Units (TPUs). Unlike GPUs, these chips are specifically designed to handle the kinds of calculations that are most common in AI and machine learning, leading to greater efficiency. Google’s expansion of these chips to external customers has already helped it attract business from Anthropic and Safe Superintelligence. While Google will happily take OpenAI’s money, it needs to tread carefully giving compute power to a rival, which will only make OpenAI more of a threat to Google’s search business. Specifically, it’ll need to manage how resources are allocated between Google’s own AI projects and its cloud customers. Another issue is that Google has been struggling to keep up with the overall demand for cloud computing, even with its own TPUs, according to its Chief Financial Officer in April. By giving access to OpenAI, it means even more pressure. Hopefully, this will be short lived as companies compete to build out capacity to attract customers. OpenAI's push for compute independence Back in 2019 when Microsoft became OpenAI’s exclusive cloud partner in exchange for $1 billion, the AI landscape was much different. End users wouldn’t have access to ChatGPT for another 3 years and the rate of development of new models was less ferocious than it is today. As OpenAI’s compute needs evolve, its relationship with Microsoft has had to evolve too, including this deal with Google and the Stargate infrastructure program. Reuters said that OpenAI’s annualized run rate (the amount they’ll earn in one year at its current pace) had surged to $10 billion, which highlights its explosive growth and need for more resources than Microsoft alone can offer. To make itself more independent, OpenAI has also signed deals worth billions of dollars with CoreWeave, another cloud compute provider, and it is nearing the finalization of the design of its first in-house chip, which could reduce its dependency on external hardware providers altogether. Source: Reuters
    • I don't think that means what you think it means
    • The Google Home app gets video forwarding support and many more features by Aman Kumar Along with releasing the Android 16 update for supported Pixel devices, Google has also showcased a number of features coming to its Home app. First up is PiP, also known as picture-in-picture mode, which will be available for Nest Cams on any Google TV device you own. It’ll be similar to YouTube’s PiP, with which you must be familiar with. A small window will appear in a corner of the TV screen, allowing you to view your Nest Cams without interrupting your viewing experience. The feature is currently in public preview, and you can enroll to try it out before its public release. Another YouTube feature that Google is adding to its Home app is the ability to jump 10 seconds forward or backward in recorded videos. This feature ensures that you don't have to go through the entire footage to locate the moment you’re looking for. Google mentioned in its blog post that it is adding more controls to the Google Home web app. Currently, the web app offers limited functionality, such as setting automations and viewing cameras, but soon you’ll be able to manage more things through it, such as adjusting lighting, controlling temperature, and locking or unlocking the door. Google’s AI model, Gemini, is also getting more controls in the Home app. You can use natural language in the Gemini app to search for specific footage in the camera history. Furthermore, the fallback assistant experience that broadcast commands use is also being updated. You’ll now be able to use your voice to broadcast messages through the connected speakers in your home. The Google blog post also mentions that you are no longer required to use the standalone Nest app to receive smoke and other critical alerts. You can now view the Nest Protect smoke and carbon monoxide (CO) status directly in the Home app. You’ll also be able to run safety checkups and hush alarms through the Home app. In addition to all these features, Google is also making the automation creation process much quicker, will allow you to add more tiles to the Home app Favorites section, and will let you create different Favorites for any other device you use, such as your smartwatch. The Home app will now also support third-party Matter locks. Similar to the Nest x Yale lock, you’ll be able to control various settings of these third-party locks, like managing household access, creating guest profiles, and more.
  • Recent Achievements

    • Week One Done
      Falisha Manpower earned a badge
      Week One Done
    • One Month Later
      elsa777 earned a badge
      One Month Later
    • Week One Done
      elsa777 earned a badge
      Week One Done
    • First Post
      K Dorman earned a badge
      First Post
    • Reacting Well
      rshit earned a badge
      Reacting Well
  • Popular Contributors

    1. 1
      +primortal
      544
    2. 2
      ATLien_0
      272
    3. 3
      +FloatingFatMan
      207
    4. 4
      +Edouard
      201
    5. 5
      snowy owl
      139
  • Tell a friend

    Love Neowin? Tell a friend!