Best design for a tree-like structure database
I would create a separate table for history.  If it was me, I would use an auto-increment column for the primary key (historyID) , a column for the vial ID, and a column for a location ID.   I would think the vial ID would be foreign key to the nodes table. You could then query against a vial to see it's full history. 

Since you don't list what your lookup tables are, I am going going to assume you don't have a history table yet.  I am also not sure you have a separate location table, and if you don't I would also use a location table that simply has a autoincrement primary key and a location description  the primary key of the location table would have foreign keys in both your node table and the history table. 

Since you mention that the batch number is redundant, I would also add a separate batch table that uses auto-increment as the primary key (batchID) along with any columns that would be useful for a batch, (date of manufacture,other information unique to the batch, etc.)  The batchID would would then be a foreign key in your node table and although the batch ID might be repeated many times for different nodes, you might be able to remove other redundancies related to the batch in your node table.  Of course, since you don't list all the columns that are in your node table, it's difficult to give advice that is not based on some assumptions.  As I review my post, I would also put the batchID in the history table.  It would give you an easy way to trace the history of the parent batch. 

Basically, you want to go through the process of normalizing your database.  By the time you normalize, your first main nodes table might end up being a very simple table that provides for the relationships between parent and children vials in a single table.  (Some might advocate for a separate table of parent and children vials, but since your manufacturing methods allow for multiple generations, I would keep it in a single table, and keep it simple.) 

Sounds like an interesting project. 

I hope this all makes sense and is helpful. 

Although I have been involved with databases since the days when Access 97 was still current, this is my first post in dba.stackexchange.  I've been the accidental DBA for multiple projects at our company and I am finally finding some of the most commonly used resources for help and information on the web DBAs.