|Perl: the Markov chain saw|
Not having experience with SQL limits my competence in answering, however I would like to observe that (1) you already appear to have a functional system and (2) at present, your data structures are not especially complicated.
I would be interested to know why what benefits a move to SQL will bring.
Right now, your data is stored in files that you read into perl data structures. You can write perl to get the entries that you want, to combine them, to print them, etc.
In the database approach, you will rewrite your scripts/applications to use SQL instead of perl to access your data. As you observe, you will write extra utilities to enter/update entries, replacing use of your text editor.
Although your editor may be trusty, every time you use it, you run the risk of editing entries by accident. That becomes a problem when you have many, many entries because an inadvertent mouse-click or keystroke could change an entry without your intention/awareness. A text editor has no protection against such randomness creeping in, although you could finesse the issue by using diff (or git-diff) to inspect your files' changes after each update.
If you've decided to changeover and managed to create a database with all your entries, the problem becomes how to rewrite your scripts with the least amount of pain. Probably you will modify them so that the data access part is contained in a few subroutines. You could even write tests to verify that these subroutines work properly. Later you can rewrite these subroutines to use the database instead of perl structures. When the tests pass, you know that everything (at least everything you test) performs as expected.
A large part of programming is changing code that already works into more beautiful/maintainable code that does that same thing. However, it is often practical to keep old, proven code.