Re^4: Concatenation of scaler reference

[Largins]

No real offense taken!
It is to be expected in the learning curve, and I do appreciate your pointing out the articles to me.
I will (and plan to do so shortly) read and apply what I learn.
I have already used hashes, (used to write my own in C). As a matter of fact, after striping the XML file (using HTML::Parser) of what I am interested in, I load the remainder into a hash of arrays. The array portion is needed for duplicate hash keys (Description comes to mind), so the key is 'description' and the array of values are the values of all the description tags.
I find most tasks that I do in perl to be much simpler than C or C++, except when it comes to complex structures.
This is taking a lot of 'Ok, now what is wrong' time, but should be worth it.
Someone else mentioned using auto-increment on the database keys, and I will certainly so that, so long as I find it trouble free.
Back to reading and absorbing.
Thank You
Largins

[Marshall]

I think that once you get used to Perl, you will find that complex data structures are far easier in Perl.
The Data::Dumper module (a core module, meaning that all Perl installations have it without further adieu) is very, very helpful.

I think that once you refine your DB application, the unique "id" number will not be so interesting.

$dbh->do ("CREATE INDEX name_idx ON bookplateleaf (name)");

That will index the bookplateleaf table so that a SELECT on a "name" has performance like a hash table...far faster than a SELECT without being indexed. The unique record id is normally not that interesting. And you do NOT have to keep track of this unique ID when adding records! (see previous post).

Also normally the index, "name_idx" is also not interesting. You will probably search, i.e. SELECT on "names" and the fact that this index exists is transparent to you. But you have to create it in order for the DB to search efficiently on names, but once you do that, the DB "knows" how to search on that column efficiently.