in reply to Re: Website Application Framework with Sybase, Apache & Perl: My Thoughts
in thread Website Application Framework with Sybase, Apache & Perl: My Thoughts

Changing your tables is neither a minor nor everyday activity. You must expect that changes at such a fundamental level will have cascading effects...
Exactly. DDL schema changes aren't a trivial operation - their effect should be assessed across the entire system (i.e. from the database to the client code). By using stored procedure some schema changes can be hidden from the client code.

is it conceivable that the stored procedures could tax the RAM of the database server?
RAM is generally consumed by data structures, not procedures. I think you would require truly vast numbers of them to impact memory performance.
It should also be noted that the vast majority of Sybase sites run on pretty hefty hardware, and even those that run on linux or WinNT tend to have in excess of 1GB of RAM available to the database server (which doesn't mean that memory should be wasted, of course).

Michael

  • Comment on Re: Re: Website Application Framework with Sybase, Apache & Perl: My Thoughts

Replies are listed 'Best First'.
Re: Re: Re: Website Application Framework with Sybase, Apache & Perl: My Thoughts
by Ryszard (Priest) on Dec 19, 2002 at 06:37 UTC
    At a certain level of experience in Application design, I see two different "influences":
    1. Application Programmer
    2. DBA

    The application programmer likes to keep control in the application, putting DML and DDL in the application, and the DBA influence who likes to keep control in the database..

    I personally see the merits of both sides, and, depending on the strength of the DBA's at the site I'm working at, would prefer the DBA control method..

    I'm wondering what camp you're coming from? .. ;-)

[reply]
      I'm wondering what camp you're coming from? .. ;-)

      Both!
      Seriously though I've mostly worked as a developer for the last 8 years or so, and I've only recently taken up jobs as pure DBA gigs. But I've seen the damage an inconsiderate query can have on a production database too many times, hence the need for controlled access to a resource that if misused will affect not only this one instance but all the other users as well.

      Michael

[reply]
        good call, you can be a part of my team anyday (or visa-versa).. :-)
[reply]

In Section Meditations