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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday February 17, 2006
11:54 AM

Informal Survey on Databases

[ #28716 ]

I'll try to present this somewhat neutrally. There's a long-standing argument about business rules and databases and in my quest to get this written before breakfast, I'm going to oversimplify like mad. Don't shoot me.

Business logic in the application:

  • It's trivial to inspect and change. Stored procedures and triggers are typically hidden.
  • It's more like to be database agnostic. Life will be miserable if you try to port you Postgresql stored procedures written in Perl to Oracle.

Business logic in the database:

  • Business logic and data should not be separated. What if another app writes to the database?
  • There fewer worries that an inexperienced programmer will write code which circumvents the logic.

So my informal, useless survey is basically this:

  1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?
  2. How often have you had completely separate apps writing to the same data store (using completely different code bases)?
  3. Do you depend on non-portable database features?
  4. Have you experienced programmers damaging your data because the logic wasn't in the database layer?

Other thoughts, comments welcome.

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.
  • 1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

    Never.

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

    A couple of times. Putting the logic in the database generally also simplifies data retrieval and storage in the app layer.

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

    Absolutely.

    4. Have you experienced programmers damaging your data because the logic wasn't in the da
  • Heh, my largest database project so far was on a database with data that was so bad that stored procedures were not even realistic due to the amount of special-casing. We couldn't change the schema because legacy applications still did a lot of the work. We made heavy use of accessors and mutators in Perl to make the data look somewhat less hairy to the business logic.

    So, I my responses:

    1) porting: nearly never (almost 100% mysql)
    2) multiple apps: on at least two occasions
    3) db features: not often
    4) damag
  • How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

    Once.

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

    I would say 50% of the time (but I'm a Middleware Engineer and not a web programmer).

    Do you depend on non-portable database features?

    Quite frequently.

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

    Actually... not that I c

  • 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, pro

  • (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 expectatio
  • Short answer -- If you have DBAs who earn their big bucks, do it their way. If not, ask why not; and do it so that your next project will be easier. Data logc belongs in the DB. Logic specific to a specific use of the data belongs in the specific application.

    Business logic in the application:
    Stored procedures and triggers are typically hidden. DB Neutral
    Logic that is data centric belongs with the Data, so that it's programming language neutral. I'm more likely to have programs in two different langu
    --
    Bill
    # I had a sig when sigs were cool
    use Sig;
  • How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

    3 times from MySQL to PostgreSQL, but they were all small DBs. A couple times from Access to MS SQL but I'm not sure how much that counts.

    I've never done this when there was more than app using the DB.

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

    Many, many times.

    Do you depend on non-portable database features?

    Always -

  • 1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)? only small applications. 2. How often have you had completely separate apps writing to the same data store (using completely different code bases)? every day. it is maddening. 3. Do you depend on non-portable database features? yes, but they are mainly isolated to a a library that generates the sql we need, so it doesn't frighten me (well, not completely, anyway) to need to change it. 4. Have
  • 1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

    Once in 8 years.

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

    About a dozen (still maintained) projects.

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

    It depends. Beyond default values, not nulls, primary keys, foreign keys, autoincrement and constraints (cascade delete...) I generally don't encode

  • I've tried before to move some business logic into the database because I thought it should be there. I got stuck figuring how to write the procedural language code. After fussing with it a bit, I pragmatically backed out, realizing the maintenance programmers were also strong in Perl, not procedual SQL programming. I rationalized that this decision made the application cheaper and easier to maintain, because a smaller skill set was involved. In this case, we still able to enforce some rules through the
  • 1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

    A fair number of times. Must be a dozen or so in the last 10 years. Once already this year and it's only February - and this was the second time that this particular application had it's database changed from underneath it.

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

    A significant minority of applications.

    3. Do you depend

  • 1. I often use SQLite for prototyping and then throw the prototype away and re-write in MySQL or Oracle. I've only once ported a working application from one db to another though, and that was Access to MS SQL Server.

    2. Whenever I have seperate applications writing to the database, they're pretty much always just seperate wrappers around a library - eg, a GUI front-end and a command-line front-end.

    3. I try not to use DB-specific features, at least in low-end databases like SQLite and MySQL, on the (alm