I think what they were trying to say was that although it is wonderful to go on a journey of discovery, the effort required to create your own XML database (and they do exist), is immense.
I also understand your perspective is that "Hey, I did this cool thing, it simplified thinking about structure for me".
I'd personally say that what you've done might be more complex than grabbing a thing and simply using it, but as long as nobodies life depends on it, it's a cool experiment and a necessary part of a journey, not a waste.
Next steps I'd suggest is to look into file-system limits, particularly locking and resource sharing, concurrency and document-oriented systems, and max open files. Also if you feel up to it, look into types of injections, handling of problematic artefacts, partial reads, typing and consistency of records etc.
It's mostly not even that DB systems do a good job of communicating where the fences are, solve all these problems. Just that it allows you to go home rather than spend all your efforts in one place. Where you land on spend all your time, vs build lots of things is just the difference between a systems programmer (few things in depth), and an application developer (higher-volume, less detail-oriented compared with crafting a kernel or FS driver).
I think what they were trying to say was that although it is wonderful to go on a journey of discovery, the effort required to create your own XML database (and they do exist), is immense.
I also understand your perspective is that "Hey, I did this cool thing, it simplified thinking about structure for me".
I'd personally say that what you've done might be more complex than grabbing a thing and simply using it, but as long as nobodies life depends on it, it's a cool experiment and a necessary part of a journey, not a waste.
Next steps I'd suggest is to look into file-system limits, particularly locking and resource sharing, concurrency and document-oriented systems, and max open files. Also if you feel up to it, look into types of injections, handling of problematic artefacts, partial reads, typing and consistency of records etc.
It's mostly not even that DB systems do a good job of communicating where the fences are, solve all these problems. Just that it allows you to go home rather than spend all your efforts in one place. Where you land on spend all your time, vs build lots of things is just the difference between a systems programmer (few things in depth), and an application developer (higher-volume, less detail-oriented compared with crafting a kernel or FS driver).
Thanks for your reply and for pointing me the right direction! There's definitely a lot more interesting stuff to learn for me!