in reply to A Perl DBMS?

One issue no-one has mentioned yet is that an RDBMS is fairly strongly typed compared with Perl. One data model I work with has to have five different tables for the different datatypes that all derive from just one table in the logical design - that's very awkward compared with what could be implemented with a more weakly typed database.

-M

Free your mind

Replies are listed 'Best First'.
Re^2: A Perl DBMS?
by perrin (Chancellor) on Mar 07, 2007 at 19:51 UTC
    Feel free to use one of the existing object-oriented DBs with perl bindings. For example, AcePerl.
[reply]
      That would be the obvious solution if the data is object-oriented - but it's not necessarily so. In my own case, over the last ten years I have been working more often than not with timestamp data, both in regard to realtime market pricing and mobile 'phone billing. Either way, neither the relational nor object-oriented model is ideal for storing and processing the data and relational tends to be used as a sort-of default architecture.

      For example, in the case of the billing, it stays in record form as long as possible during the algorithm where Perl rips through like a knife through butter. But eventually the huge 6-million record customer database is needed for lookup and the records have to be split into batches and processed slowly 100 at a time (and that's for best performance) while it trundles through the stored procedure processing before Perl could get its hands on it after that to finish the job off. The ineffectiveness of the relational architecture is costing the operators serious money and an object architecture would not in fact come to the rescue.

      -M

      Free your mind

[reply]
        The problem you're describing (slow stored procedures) sounds more like an implementation problem than an intrinsic limitation of relational databases.
[reply]

In Section Meditations