DIYbanter - View Single Post

Don Y[_3_]

On 2/6/2016 11:55 PM, wrote:
On Sat, 06 Feb 2016 23:07:15 -0700, Don Y
wrote:

On 2/6/2016 10:43 PM, wrote:

The biggest problem I have is I will take a picture and name it with
something like "Christmas 2006" in the name and then later I will
figure out that may be the only picture of something I have that has
no relation to Christmas so I am still looking through hundreds of
shots.

Coming up with *a* name for (damn near ANYTHING!) is virtually
impossible -- if you want to LATER be able to determine what
the significant aspects of that "thing" might be.

I've been involved with several small companies/startups
that are trying to put procedures/mechanisms in place upon
which to build.

Part numbering systems are my favorite example of peoples'
inability to acknowledge the complexity inherent in the description
of any THING! Invariably, "some guy" sits down and tries to impose
some "order" on the numbering system: I'll let the first digit
indicate whether it's a fastener, solvent or raw material; the second
digit will REFINE that (e.g., "fastener, screw" vs. "fastener, nut");
the third will refine *that* (e.g., "fastener, screw, reeds&prince"
vs. "fastener, screw, philips")

Fortunately by the time I got into the parts business we had
computers. The part numbers were pretty much random and the computer
would tell you what it was. In the system I wrote, we actually put a
bar code on every box that came into the parts room and from then on
we tracked that bar code number. From that I had the part number, the
description, everyone who may have taken it out and brought it back
with the dates. From that point I could also go into our time tracking
and dispatch system and figure out where the part was used if they
didn't bring it back.

We really only tracked high dollar parts but they could easily be
worth more than a new car. Some were more like the price of a house.

My point is to avoid the temptation to put structure/significance into
things that you can't truly embody all of the NECESSARY structure/significance.
Yeah, you *may* be able to tell me the part number for a 1/2", Philips PHMS
"off the top of your head". But, how does that help anyone else? And,
can you tell me the part number of a 7/16" Clutch FHMS with the same
level of certainty? I.e., can you live with JUST your "mental system"?
Or, will you also need to rely on some other "system"? (in which case,
why not rely on it for everything??)

When I went into business, I sat down with 00000001 and assigned that to the
first "item" that I needed to "control" (it happened to be a specification).
Then, 00000002 assigned to the second item (it may have been a screw!).
I.e., no reason to have one set of numbers for specifications, another
for "hardware", still more for individual source code modules, etc.

I've designed two "process monitoring" systems in which I arbitrarily
assign "identifiers" to "objects". The identity of the object -- along
with an indication of its *type* -- is stored in a table. Objects
are then tagged with barcodes so they can be "identified" whenever their
corresponding label is scanned.

So, "Bob" (whose employee badge has the barcode 1432123 printed on it)
can hand a stipend check (payable to "Joe", carrying the barcode 5858590
printed on the check to identify this check -- payee, date, amount)
to "Larry" (whose employee badge has the barcode 33333 printed on it).
"I" can see the 1432123 identifier from Bob's badge and know this
transaction is taking an asset currently controlled by Bob, transfering
it to Larry and identifying the specific asset in the transaction.

Now, Larry is liable for that asset. If Joe calls and wonders where his
check is, "I" can tell him that "Larry" has it. If Larry *claims*
he has given it to someone_else, I can verify or disprove that
claim just by querying the table of transactions for that asset.
If Joe has already received the check, I can verify that, as well:
"Joe, my records show that Bob gave the check to Larry on Thursday.
Larry then gave it to Brenda later that afternoon. Brenda gave it to
*you* on the following Saturday -- because *YOUR* ID was scanned in that
transaction! (at 3:27PM, if you doubt my data)"

No need to deal with "people IDs", "check ID's", "requisition ID's", etc.
An ID is just an ID -- let the RDBMS keep track of the actual details
concerning *what* it is!

Now, you can print off sheets of barcode labels, slap one on an object,
scan it and then "tell" the RDBMS what "it" actually is. No need to
reprint a "lost" barcode label. Only one instance of *any* label
ever comes into being! No possibility of encountering a CHECK with
the label 12345 and an EMPLOYEE with that same 12345 (cuz we only printed
ONE "12345" label)