views:

179

answers:

8

A while ago I wrote a plan management system for the council that I work for, which lets us store all the old and new plans in digital format with information associated with via a access database(I didn't know MS SQL server at the time).

Each plan has a unique plan ID which is just a auto incrementing int (primary key), a title and the path to the picture. At the time, I just used a GUID as the picture name to insure uniqueness and I'm just wondering if this was a bad move.

All the pictures are moved into one central folder at the time of import so there names have to be unqiue.

I was thinking that maybe I should have just used the auto incrementing int as the name of the file rather the long and not very user/debug friendly GUID.

What would you do?

EDIT: Sorry forgot to mention that the files are really only known by the software, after the import the program creates a shortcut to the file in the folder it was imported from with the name of the original file. I did this so that people could still get to the document without having to go through the program and so old hyperlinks etc worked.

A: 

Depends; is the filename used/seen/referenced by users, or just by the software? Will users "know" the ID of then plan and then have occasion to go look at the filename on disk?

I suspect I'd have just used the plan ID as the filename, if the answer is "no, no" -- though I don't see any real drawback to using a GUID either in that case.

DarkSquid
+2  A: 

As I understand, these pictures are to be used only by the software itself, never directly by humans. If I couldn't find a compelling reason to change, I would leave it as it is.

Alfred Myers
+6  A: 

Generally integer keys are faster, but you can run into issues with archiving and replication under some circumstances if you're not careful. If you do not have performance concerns / issues I would tend to stick with a GUID.

In any event, I would recommend you allow the user to assign a "friendly" name to each image that is displayed in the UI.

Eric J.
+2  A: 

If you have any plans to replicate or "work offline" then I would encourage you to use GUID for both the filename and the pk of the table.

Ken Browning
If you're considering Jet replication of a database with a GUID PK, you need to be aware that the built-in conflict resolver will be broken by that, as it expects the s_GUID field to be there, but if your PK is already a GUID field, Jet won't add the s_GUID field and use your existing PK instead. This means you have to roll your own conflict resolver, so I would definitely say that if you plan to replicate, then DO NOT USE GUID PKs.
David-W-Fenton
A: 

If users do not directly access the files in that central folder, I would use a GUID internally and display a friendly name to the user.

If users do interact directly with the central folder, I would use a GUID in the database and a friendly name in the file, using a collision detection algorithm

extension = getFileExtension();
filename = getFriendlyName();
int i = 1;
while (File.Exists(filename)) {
    filename = getFriendlyName() + (i++);
}
writeFile(filename+extension);

Remember you can have an easier retrieval by having subfolders in that central folder per letters (A\, B\, and so on) or letter combinations

Vinko Vrsalovic
A: 

Are there any security/permission concerns there? Incremental numbers allow you to easily iterate through a range of integers to extract all images, with GUIDs it will be not that simple.

DmitryK
+1  A: 

GUID's are useful when you're going to need to identify an image on multiple systems. For example, when you copy the image from your system to another system and then back again. When you copy it back, the unique GUID would provide a reliable way to recognise it.

But if only one system is going to access them, auto-increment numbers would be more practical. Actually, a GUID would be more at risk of still generating duplicate ID's if you only create them on a single system, although you'd likely have to use a million GUID's or more before the chance of duplicates moves from statistically none to statistically very small.

Personally, I only tend to use GUIDs when I need to create data on multiple systems. It would allow me to uniquely identify them. But on a single system, I just use an incremental number and keep increasing it until... Well, forever if possible. A 32-bits integer still have two billion possible numbers. A 64-bits integer will allow you to go even further.

Choosing between a GUID or an integer to make the name more user-friendly? Why? If you want user-friendly names, let the user provide them...

Workshop Alex
+2  A: 

GUIDs in Access have several problems. They are all outlined here:

http://trigeminal.com/usenet/usenet011.asp?1033

I would never use them in an Access app except if there was an outside dependency that required them.

If you're storing photos and need uniqueness, a random Autonumber is going to give more than a large enough numeric space to store any number of graphics files that any real-world application is going to create. And unless you're adding at independent locations, there's not even any justification for that -- a standard incrementing Autonumber will be just fine, and perfectly good for a multi-user environment (and completely smooth sailing for a single-user environment).

So, NO -- GUIDs are not a good choice, nor do they seem justified by anything you've described in your original question.

David-W-Fenton