use Perl

• Give them their own copy (Score:1)

  by Ed Avis (3134)

  Why not give them a dump of your whole database and let them load it on their own server? It won't keep up to date, but if ad hoc queries are all they need then that won't matter. Reinventing the wheel by implementing your own home-grown query language instead of SQL may make sense in some cases, but it's not necessarily the best way.

  --
  -- Ed Avis ed@membled.com
  • Re: (Score:2)

    by Ovid (2709)

    Thought about that, but they need live data. Our data changes rapidly and being even one day out of date is like playing the stock market by reading a day old newspaper (well, ok, not quite that severe :). It would be good to have a series of read-only slave servers, but that still puts us in the position of them insisting that we can't make that important database change just yet. We've had that happen enough times that we have nasty hacks in our code and database [perl.org] to work around these issues.
    • Re: (Score:1)

      by Ed Avis (3134)

      How about an interface that lets them submit arbitrary SQL queries, but checks them against a whitelist first. So for example your customer might say 'we need to SELECT COUNT(*) FROM FOO' and you would say 'that seems fine, I will add it to the list'. The next day they ask for 'SELECT FRED FROM BAR' and you decide no, the FRED column is an implementation detail I don't want to support forever, so I will not allow them to make that query. That way you have control over what's happening.

      If they want a parti

      --
      -- Ed Avis ed@membled.com
• Oracle? (Score:2)

  by djberg96 (2603)

  At Qwest we had a snapshot of the production database for people to run reports off of. It had a few limitations (you couldn't snap some of the larger field types), but it worked pretty well.

  Also, with Oracle you can set IO limits on a per account basis, so queries like the one you mention would simply timeout after a while.

  Does MySQL provide such features?
• Are You Talking about Databases? (Score:1)

  by chromatic (983)

  ... good intentions mean nothing when you need to coordinate your internals with people who should know better than to violate encapsulation.

  Perhaps Perl 5 should have a REST API for writing extensions.
  • Re: (Score:1)

    by audreyt (6654)

    Perhaps something like GHC Plugins [haskell.org]? :-)
• Counter-point (Score:1)

  by stinkingpig (5626)

  I work on a project where the API is three years out of date and has gone through five licenses in those three years. Direct database access wins, sorry.
  • Re: (Score:2)

    by Ovid (2709)

    I don't know what "three years out of date" means in this context, but if you mean that neither management nor developers have bothered to address customer concerns for three years, than there are far larger problems than direct database access. If you meant something else, than I guess I can't respond to that :)

    Nor do I know what five licenses has to do with the situation.
• Counter-point (Score:1)

  by stinkingpig (5626)

  You're telling me. Is that different than the norm? I find it to be very normal, as meeting all customer needs in a given release cycle is impractical. The 5 licenses are important for accessing the API. Under some of them, the customer cannot use it without paying, while under others, they can. If my code used the API instead of the database, I'd have to rewrite during those changes. I didn't even mention the second (also incomplete) API that's struggling for relevance at Layer 8/9. I suspect you're talk