Record keeping, batch numbering

I am not sure if anyone else makes batch numbering or not, but if you do or if you would; How would you do it?

I mean for us home-brew folks. I am a software engineer by day, so if I am overanalyzing I apologize.

Here is a thought:


[batch number][ID][day][month][year][days 'till bottled]


Batch number will be the actual number of batches I have ever done. Thus ensuring a unique identifier. Four digits. Probably more digits than I need, but if my kids want to continue to use my batch numbering system (and I hope they will) it will handle it.

ID will be the id of the product. I don't anticipate getting too technical with the types of brew-ables. The actual label should be sufficient. Come to think of it, maybe type ID is a bit much.

Other: 0
Mead: 1
Wine: 2
Beer: 3
Cyder: 4

day, month, year will be when yeast was pitched or said product was started. each two digits. Month and year could each be truncated to one digit, using letters or alpha numerics.



Days until bottled will be the count in days from the start date until it was bottled.

So my very first batch of JAOM will have a batch id of: 0001 1 110413 0099


The point is, then if I keep a digital record, it's super easy lookup. If I am doing a paper and pencil record keeping it's easy to decrypt. And so far in my notes on paper, I can write things like "started on Nottingham yeast cake from #6."

I do hope to transfer it all to a custom built software solution, web based. But once I get a hang of it I will then build the system.


Thoughts?

 

I'm a computer science major, so I found this interesting. Especially since I did fairly decent in Database Management. Change your month date and year tables into one Date table. Makes it easier to manage since it could be in MMDDYY form. IMO three separate tables for a date takes longer to manage than one table with six digits . Also remove days until bottled table out, because that's a dynamic variable and changes from day to day, because if you want to add your second batch on the day it was started you won't know how many days until bottling unless you've chosen a date. Say you've chosen a days until bottled variable and let's assume it's 99. Well you'll have to have it auto update each time you chose to access that data from the table. Instead you can make a vintage table which could be the day it was bottle, also in MMDDYY form. As far as encrypting it, I'm not sure that's necessary. But thinking of that makes me think of a possible idea. Maybe you could set up small Linux server, and create a MySQL database on the server with recipes, your notes, and basically anything related to winemaking and home brewing.

 

Like you (OP) I'm super technical as well, even though I am just starting out. I been writing in a journal cause I'm not too data base witty but I really like your batch numbering system. I may have to play a little bit with Access now!

 

If we are talking DB optimization, there are many ways to achieve that through the program interfacing to the DB. As per the date; I actually would use whatever date format the DB used, just transforming it to whatever format I want it to be at through the program. Same with the bottle date, then let the program or DB do the math to know how many days until bottled.

I am no doubt going to make an application to house all my data. Just when is the question.

Wondering what else anyone includes in their record keeping? Maybe a place for pictures. What info on labels?

I haven't look yet, since I have to get going. But, is there any open source web application for brewing/winemaking out there? Maybe we could just modify that one.

I am off to a long weekend wedding, so I wont be back until Monday.

 

Not on your process, but on having one. It is a good thing. I've read -but not applied - the dictum that by recording what you do and keeping careful record, you can reproduce your results (that and backups of your documentation - someone else posted that they lost their HD and now have lost their recipes).

Also remember this will work for you and possibly others can customize it, but it won't work for others. Either they can't read code - that is even if they know how to decode, it all becomes jiberish and not a fluent language. Or they are just naturally disorganized (that would be me.)

 

you guys wouldn't like the #1 or #2 i put on my beer caps. LOL

 

I sharpie something like A(pple) or L(emon) wines or BB(belgian blond) or CR(chocolate rye) or something (beers)...

 

What is the benifit of using an integer to encode the batch type rather than a string? Why "0001 1 110413 0099" instead of "0001 mead 110413 0099"?

Also, you might replace days till bottled with bottled on date (with 000000 indicating not bottled yet). Of course cmiller365's criticism still applies in that the entry will have to be updated at some point.

 

There is no benefit. In fact, the dates can have string values for the month as well. It's personal preference, and how you want to manage the database yourself. You can call it mead or you can call it one. As long is it identifies what type the batch is.

 

I am a SW Architect by day... What's wrong with:
1
2
3
...
N

Or if you want to be fancier, pad it with leading zero's:
0001
0002
...
NNNN

In the end, you are putting it in a database so why complicate your life coming up with a numbering scheme? Store all your fields in the database and let the client present it how you like to see it.