Re: Schema Design.
From: joel garry <joel-garry_at_home.com>
Date: Fri, 10 Dec 2010 09:13:06 -0800 (PST)
Message-ID: <3bf247bd-6827-4541-b2c9-9d32abd35d36_at_m20g2000prc.googlegroups.com>
On Dec 10, 2:20 am, "Preston" <dontwant..._at_nowhere.invalid> wrote:
> joel garry wrote:
> > On Dec 9, 2:28 am, "Preston" <dontwant..._at_nowhere.invalid> wrote:
>
> > > So what I'm trying to figure out is the best way to map
> > > applications to schemas, bearing in mind this is a database &
> > > applications that we install & maintain at various client sites. I
> > > don't want to stick with using a single schema for various reasons.
>
> > This winds up being an intractable problem. I work on an enterprise
> > app that originally was a couple of apps/schemata, then various
> > modules within those were spun off as separate options. Over time,
> > one schema became dominant, and an argument could be made everything
> > should have been lumped in there to begin with. As Fred pointed out,
> > people think of these schemata as separate databases (which is what
> > they are called in non-Oracle dbms's and tools like Excel), so strange
> > things happen - different definitions of the same field or table, or
> > sometimes the same definition but one table isn't used, and so forth.
>
> That is something we need to be careful of, not because there's any
> confusion over what a schema is, but because we've all been involved
> with this system for 14 years & the object names for each process are
> firmly ingrained. As many of those processes will now be duplicated to
> a certain extent in the new apps, I suspect the developers may start
> creating new db objects with the same names as the original ones but
> with '_new' tagged on the end to make them easy to remember. I guess
> that's one reason to just have one new schema for the new stuff - it
> makes a simple naming standard easier.
Date: Fri, 10 Dec 2010 09:13:06 -0800 (PST)
Message-ID: <3bf247bd-6827-4541-b2c9-9d32abd35d36_at_m20g2000prc.googlegroups.com>
On Dec 10, 2:20 am, "Preston" <dontwant..._at_nowhere.invalid> wrote:
> joel garry wrote:
> > On Dec 9, 2:28 am, "Preston" <dontwant..._at_nowhere.invalid> wrote:
>
> > > So what I'm trying to figure out is the best way to map
> > > applications to schemas, bearing in mind this is a database &
> > > applications that we install & maintain at various client sites. I
> > > don't want to stick with using a single schema for various reasons.
>
> > This winds up being an intractable problem. I work on an enterprise
> > app that originally was a couple of apps/schemata, then various
> > modules within those were spun off as separate options. Over time,
> > one schema became dominant, and an argument could be made everything
> > should have been lumped in there to begin with. As Fred pointed out,
> > people think of these schemata as separate databases (which is what
> > they are called in non-Oracle dbms's and tools like Excel), so strange
> > things happen - different definitions of the same field or table, or
> > sometimes the same definition but one table isn't used, and so forth.
>
> That is something we need to be careful of, not because there's any
> confusion over what a schema is, but because we've all been involved
> with this system for 14 years & the object names for each process are
> firmly ingrained. As many of those processes will now be duplicated to
> a certain extent in the new apps, I suspect the developers may start
> creating new db objects with the same names as the original ones but
> with '_new' tagged on the end to make them easy to remember. I guess
> that's one reason to just have one new schema for the new stuff - it
> makes a simple naming standard easier.
lol, I can imagine the naming you'll have 14 years from now with all those old new er uh...
...
>
> Heh, that's exactly what one of our clients was doing (in Access), &
> drove the decision to create one of the new apps. It will still run on
> data sucked down overnight, but simply because they need a static view
> throughout the day without any new transactions affecting things.
>
I still come unstuck in time when I realize I'm writing the same program I wrote in 1980...
jg
-- _at_home.com is bogus. If at first you don't succeed, don't test yourself against Nature. http://www.canoekayak.com/whitewater-kayak/hendri-coetzee-killed-by-crocodile/Received on Fri Dec 10 2010 - 11:13:06 CST