[thesite] database: Attributes table

rudy r937 at interlog.com
Sat Aug 4 15:21:50 CDT 2001


> I'm more or less looking towards evolt3.0 where one of the
> things that will have to be fixed is copies of the member table
> for each subsite.

um, i don't see 3.0 solving that problem, since we are futzing things up
now

kinda like saying "i'm looking forward to the day they solve the problem of
wanton pollution and resource consumption" when in reality, this will occur
only if we tackle them now

your idea of a table that will not be joined is a (pardon the pun)
rudimentary data dictionary

when i was *cough* younger *cough* i spent years specializing in data
dictionaries

you don't hear much about data dictionaries nowadays, as most projects to
implement them fail spectacularly


> I assume that one way this could be fixed is to make one database
> for all *eo sites.

that's one way, but so far, nobody has declared a state of emergency

still, it is nice to consider all the options beforehand

> I don't want to wipe that out as a possibility because odd-ball
> feo requires an extra table and column that doesn't exist in the
> weo database. More principle than the effects of this addition alone.
> Ya know?

but of course

it is not just the principle, either

some very pragmatic implications depend on how we handle calving of
applications -- both the database and the code

(like that word? "calving" as in cloning, genetic reproduction, offshoots,
cuttings...)

personally, i prefer one schema -- i come from the old school that says a
rose is a rose (and therefore in real life your database may need a rose
type code, and maybe a thing type code where a rose has to reference what
kind of a thing it is... okay, substitute rose type with recipe type... but
i digress...)

so if you need attribute type, as a new column and/or a table, i would be
curious why the other *eo apps haven't needed it yet, or if you're the
first, what is it doing for you that the other apps can also use... but i
would prolly still go ahead and do it for you (except you, matt, can, as
my german brother roland would say, "tu it yourselbst")

some people (sadly, many of them in my experience in positions
of power) insist that the way to solve this whole problem is to
have "checkin/checkout" -- remember, we are really talking about both
database and code -- and therefore impose a "superstructure" of which all
apps are subsets

me, i don't care

what counts with me is this -- where is "the" data?

sounds contrite, almost silly, but just take as example the question
of evolt  users and members

where does user and member data come from?  how often does it change?  who
changes it? which applications have to have it?

see, as far as i'm concerned, there is only "the" data, and if separate
apps have separate databases with concomitant separate update procedures
then there's a good chance they'll have separate versions of "the" data,
now, isn't there?  oh, the individual databases themselves, taken
individually, might not be *wrong* per se (as in bad data) but there sure
could be inconsistencies and confusion and emails in the dark of night
asking "please, can you please reset my password, i went to the admin page
but i'm not showing up!!!"

but don't go by me, because while i can model all sorts of ways of dealing
with these problems (and worse -- including tracking the time dimension, as
they do in data warehousing), what we implement will depend on what we
code, and you know what always happens? when it gets to the crunch, the
moment of truth, when the rubber hits the road, when push comes to shove,
when we're finally down to the short strokes -- as it were; me, i wouldn't
know -- everything depends on the guy faced with the job of doing the
coding

changing a schema takes a couple of minutes, but that's not as hard as
deciding whether to change it or not in the first place

often the coder can have something coded and working based on what he
thinks the way to go is before the data modeller can get his finger outta,
er, i mean, can make a recommendation about which way to go...


>  Not to spark an evolt3.0 discussion or anything.

heaven forfend

;o)


no, this discussion is timeless, so if you want to go further into it, i'm
game


rudy







More information about the thesite mailing list