If I was Earth Czar and had total control over everything, my file names would be simply numbers.
Mixing alpha and numbers can be confusing. (stupid "I" and "O" can cause confusion.)
My Earth Czar numbers wouldn't have any meaning, just the next available number when I create the file. Though I appreciate dashes because it makes numbers easier to read, they add a level of complexity when it comes to programming so I'd make my loyal subjects read numbers without dashes.
I wouldn't even have leading zeros. Mt first file would be "1" and my tenth file would be "10".
But so far I am just Jeff, so I understand there have to be compromises, and with a PDM system the file naming convention really isn't that big of a deal - you can live with almost anything those marketing guys come up with.
"you can live with almost anything those marketing guys come up with"
true, especially if you get paid by the hour (ah, if only!)
what brought this on is a filename with 59 characters,
glad I didn't originally post that since the max size I have encountered is now 74
74 characters pretty long. Remember many applications will only accept full file names (including their paths) to be less than 255 characters, you'll need to ensure your local cache is very shallow in your directory structure or you'll go over that limit pretty easily.
The system you implement must be data base friendly. Once you start numbering in a certain way it's becomes difficult to change a year or two afterwards.
This is the system we use 0001, where 0001 means this is the first project we've done.
You could attach the year example, 2010_0001.
Then you could name your assembly '2010_0001 Machine Tool' and the parts 2010_0001_01 and so on.
Hope this helps.
I would look at a spec for the industry you are providing data for. In the aircraft industry we follow manufacturer, customer or industry standards for file naming conventions.
There's also another way of thinking...
Many smart people have written that the more meaning you place in a numbering scheme the more likely it is to fail you in the future. Think about all of the changes a company can go through over the years. When a place in the character string or a sequence of characters has to mean something it may not work with some future project
...plus there is the subject of meta data. If you are using PDM you have little reason to assign any meaning to a numbering scheme. You'll always be able to find what you are looking for if the data cards are populated. This idea is not always realistic...but it does make sense.
the big problem with the present scheme is that with a mongo number of characters, filenames are often entered incorrectly.
another problem I see is in characters used to give order that only seem to foul things up
do I use a -, _, a space, or nothing at all?
do I call it Bracket-left-blue, blue left bracket, or left blue bracket
the consequence is that there are multiple part numbers for the same part, and we order more even though the stockroom has many, they are just "numbered" something else
Mark, that is easy to solve.
As long as you put a unique drawing number in front of name. For example, 1234_bracket left blue.
The bracket you use for the next project you will call 1235_bracket left blue.
If the part has a part number (it should for many reasons)...use that and not the description. If you must assign meaning to the filename have it be the document or part number.
I like non-significant part numbers, 5-8 characters long. These types of numbers force people to look at BOM or ERP data instead of trying to commit things to Tribal Knowledge.
Project number (the common four digits for any project used to be refered to as "Brass Tag" numbers) first, then three digit numbers after a dash (x00 being the assembly, x01, the first detail,, x02 second detail, etc.). I lean towards adding detail name text after that. If you have to renumber any files it really helps having a description to keep things straight. All jobs for year 2010 would be under the 2010 Jobs folder, after a few years it's pretty straightforward to see where the legacy files can be stripped off the server into archive. Some would argue PDM negates most of what I said, but obviously this depends on your line of business and company needs.
I agree with all of you...
A Part Number should be simple next number, no leading zero's.
The file name should be the part number in most cases, unless the file does not have a part number (a child of a purchased assembly).
Any other coding should be at the field/property level. Then you can search in any combination you like.
If needed for programing or other, you can build a configuration string from the spec's filled out.
Avoid "where used" codes. Anything can be used anywhere always.