At this time, I don't have time to read what are probably very valuable responses, so I must respond to you in the blind based solely on my own experiences.

Storable is an exceptionally useful and pretty darned efficient and very effective method of serialization of Perl data. In fact, it's the primary storage mechanism for the IPC::Shareable distribution that allows one to share extremely complex Perl structures in memory between processes that I've managed for several years now. In fact, in years of testing, I haven't found anything comparable. Have I found faster? Yes. More capable? Yes. More resilient? Yes. More able for my very specific usage case? No.

And that's what I leave you with. No. Don't use Storable for your use case. There are far better alternatives. Many of them. Even (by my own testing) a JSON string to a DB is likely preferable than using a proprietary serialization mechanism.

Storable is a format that you'll have to load from disk (or memory) each time you need read access, and you'll have to write that back each time. There are significant proc cycles used to do this, far more than DB writes. This is compounded exponentially if you store all settings in one Storable file, and if you do, contention issues are a bloody nightmare. If you keep each user in their own file, well, as you can imagine, that has I/O headaches all on its own, and can itself make things unscalable quickly for the CPU and your poor disk array.

Then you have to deal with compatibility. Not all Storable formats are compatible with one another. The next version of perl could be included with an update that renders all previous saved data as unavailable or inaccessible. This may not be relevant now, but what if you need to restore data from tape later?

Use a common format to store your data. Sounds like a DB is the correct approach. If it needs to be serialized, use a common, cross-language standard. Storable is a fantastic resource, but not for this case.

Besides... it doesn't seem like you need to store data *structures* anyways, just data, so in reality there's no need for such complex overhead such as Storable.

The "what ifs" are too many, and there's no complexity to the data. Just store it in a DB (or JSON or equivalent manner) and be done with it. Don't compound things by introducing an unneeded technology that may confound you, or your successors in the future. If you can't use a DB, I'd advise a JSON-file-per-user approach long before I'd suggest a proprietary serialization mechanism such as Storable without hesitation for your needs.

My opinion, based on extensive experience,

-stevieb

In reply to Re: Storable for user preferences by stevieb
in thread Storable for user preferences by Bod

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.