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.
  • You have to be careful whenever you use the word "all" or "always" when it comes to computing. :-)

    Generally, the business logic that belongs in the database is usually "data rules", like "an order must have a customer", "a customer must have a name". Business logic that doesn't belong in the database are things like process flow logic. Generally.

    Now on to your questions:

    How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?
    A few times: Informix to Sybase, proprietary to DB2, and SQL Server to Oracle.

    How often have you had completely separate apps writing to the same data store (using completely different code bases)?
    Writing, not often; reading, quite a lot. This is a typical pattern in data warehouses and reporting apps.

    Do you depend on non-portable database features?
    Yes. Unfortunately most databases don't fully comply with SQL standards yet.

    Have you experienced programmers damaging your data because the logic wasn't in the database layer?
    Depends on what you mean by "damage". I've had people generate garbage reports (and turn them over to management) because the database didn't enforce constraints properly.