Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by ziggy (25) on 2006.02.17 15:55 (#46186) Journal
    (Thinking about 15 years of projects, some web, some not):

    1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

    One migration, from RDB to Oracle, but only because Oracle bought RDB, and that was the only path forward. (Come to think of it, that may have just been a re-branded version of RDB, so there was no real migration to speak of.)

    Lots of work with custom data storage solutions (as in, write your own database engine), typically because there was an expectation of managing our data on a customer's server, and out of our control. (Haven't worked on a project like that in ~5 years; may be an artifact of mid 90s economics, big data and prevailing strategy.)

    2. How often have you had completely separate apps writing to the same data store (using completely different code bases)?

    Pretty frequently. Most common scenario is one codebase for front-end, customer facing apps, and a separate suite for managing the database. (Sometimes it starts as a unified codebase, but diverges, with database mutation going into the backend only.)

    In one case, front end and back end were written in multiple languages. (This is where referential integrity really saves your bacon.)

    3. Do you depend on non-portable database features?

    All the time. Designing database-neutral code is a non-starter for app development. The typical mission is to deliver features by any means necessary, and retarget if/when the current stack runs out of steam.

    4. Have you experienced programmers damaging your data because the logic wasn't in the database layer?

    Probably. Don't remember anything serious, or at least anything that made it out to a customer.

    Worked on a couple of projects where the logic was in the database layer. One specific project seemed like an exercise in job security for the DBA (rules all in the database, impenetrably coded); then again, if you're a DBA for something other than Oracle, that's sufficient job security right there. ;-)