A family of Microsoft relational database management systems designed for ease of use.
You've done much as I expected, and approached the project in a spreadsheet manner, rather than as a relational database. In the latter each table models an entity type, and each column in the table models an attribute which is functionally determined solely by the while of the key. Each table will generally have relatively few columns, but many rows.
I suspect you'll probably feel that you are in too deep for the radical redesign which would be involved in changing the database to one which conforms to the principles of the database relational model, but essentially what you'd have would be a table of orders, a table of garment types, and a table of garment features, for want of a better word, as values in columns, not as column headings. The order specification would be a many-to-many relationship type between these tables, which would be modelled by a further table which resolves the relationship type into three one-to-many relationship types. Non-key columns in this table represent the attributes of the relationship type, e.g. with the example of collars which you've posted, a value such as 'semi-spread collar' would be an attribute value of the ternary relationship type between garment type shirt, feature collar and the order in question.
Moreover, the above is a simplification of the model. It would also contain other relationship types modelled by further tables to enforce constraints between the entity types, e.g. trousers don't have collars, so a further table would model the relationship type between trousers and features and would define those features pertinent to trousers, and similarly between coats/shirts/vests, and other features. The nearest example I can give you to this is Relationships.zip in the same OneDrive folder to which gave you a link. This uses a simplified medical prescriptions model as its example, to illustrate how relationships are built up across a database to achieve a robust model.
Recasting the database into a correct model would be a major undertaking, and my guess is that you won't want to go down that road. You can of course still do the same as in my CopyTree demo, but you'd have to assign values for each column in the tables. While the code would therefore be 'bulky', writing it is a one-off exercise, and its execution should still be efficient.