If we are talking about an SQL database, you have what looks like a row ("record") of separate data fields, with one row for each CD, and if I understand your question correctly, a column Title which is designated the primary key, and a column CdObj which contains a serialized data structure.
The database does the looping for you, and you are just concerned with checking to see if there is already a row which contains a Title field of that name. If your SELECT query does not return any data, you are safe.
If you are not using a database but just writing to disk, It is probably a similar problem. You need not load every object, just your index. Maybe you have it in a separate file from all those big objects and it can be easily loaded into a hash. If so you don't need to loop, just look to see if your hash key exists and if not (so long as they all got read in correctly), you are safe.
Unpacking objects one at a time and looking inside each one would be a terribly slow way to search a database. Much better to let Perl or SQL "look" at a whole column at a time for you and not call all that disk use and computing overhead. I don't understand why you need to serialize an object at all actually, it would seem to be much more interesting to have a separate database field for every part of the object, so you could search by singer, track length, genre, etc. Does this answer the question? If not please try to explain a bit more, thanks.
In reply to Re: handling Perl Persistent Objects
by mattr
in thread handling Perl Persistent Objects
by rgatliff
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |