2 ms·
This is a pretty clever idea, but I have to wonder how much of a concern an "ExternalId" column is today. Assuming you are really paranoid, and each is 256 bit
by bob1029 4y ago
This is a pretty clever idea, but I have to wonder how much of a concern an "ExternalId" column is today.
Assuming you are really paranoid, and each is 256 bits of the best CSPRNG output available, then for a table containing 1 million records you are only talking about an additional ~32 megabytes of overhead.
With modern CPUs and most applications, this extra amount of data is not going to move the needle at all.
- piaste 4y agoThe two approaches can be combined! You can use AES to generate and store the ExternalId column. As you pointed out, this saves you from having to encrypt/decrypt it on the fly every time, at the cost of an extra lookup and some storage (you're going to want an index on that column as well). If it ever comes up that you prefer to do it on the fly, you can just drop the column. All your external references will still be valid since the ExternalId was generated deterministically.
- dangerface 4y agoYup, I once tried using aes to create uuids but then ended up with a page that would send a thousand results to the client each one needing a uuid generated, multiply that by a thousand users and the cpu time started to add up it obviously wasn't going to be as scalable as just storing the uuid. Possibly only doing one round of aes or skipping the key expansion steps would make it more scalable but I didn't have the knowledge to do that securely.
- DmitryOlshansky 4y agoPlus the advantage of changing the way you generate your externalIds. As long as they are stored the external links to said record stay stable which is typically important with integration