[thesite] database: Attributes table

[Warden, Matt]

Thanks for the quick response, rudeman...


On Aug 4, rudy had something to say about Re: [thesite] database:...

>> 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

Hmmm... care to elaborate?

Maybe I'm living in Potheadsville, Wisconsin here, but what i was thinking
was that the evolt3 database would be much like the evolt2 database but
with another field called SITEID or sumfin. Like, category (not
content) would have a SITEID... and I'm sure other tables would need it,
but I'm just not in the mood to think about that ATM.

>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

I dunno about that. We Americans are just completely ignoring the problem
and the world hasn't blown up yet. Accurrate scientific reasoning suggests
that since this has yet to become a serious problem, it never will be.

*cough*

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

Ok, admit it. You just made that up.

>when i was *cough* younger *cough*

Would that be before or after I was born? *duck*

What? Oh yeah, the database...

>> 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

Well, can I? I still haven't figured out 100% how I'm going to work the
synchronizing of the member tables. I've narrowed it down to two possible
solutions, both of which seem a bit ugly to me and break independence of
weo and feo data source names. Maybe that's no big deal, but it's not
ideal.

Fwiw, this has been on my mind for a long time. You remember that talk
about an evolt passport that dan was working on? Well, that was prompted
by this.

Here's the deal with this shit:

- inserts go one way from weo to feo. there will be no feo signup
form. user X clicks the "sign up" or "join" link on feo and gets sent to
the weo sign up page. the weo sign up page will have to be modified to be
able to redirect back to weo. as far as going from feo's design, to weo's
design on its contact form, and back to feo... I think we're SOL there.

- updates to Joe User's record on weo will no propogate to feo's member
records.

Synchronizing methods:

1. Don't like this as much. I write a script that imports new records in
weo to feo's database. It gets set up in cron to run every x minutes. This
means i have to keep track of what records I've inserted already. Plus
there will always be a delay of up to x minutes before a new user can log
into feo. Ick.

2. Leaning towards this. Insert of new record from weo to feo happens only
when a user visits feo and their member id isn't found in the database. I
then query weo and import a copy of that record into feo's
database. However, this means that the import process consists of:
	(a) querying feo
	(b) querying weo
	(c) inserting into feo

So I dunno. And with #2, the tables won't actually be synched. Not that it
matters.

Then there's also the issue of the sequences. I'm assuming you have one
global sequence for a reason. Well, importing from weo means that the
member table in feo will really be based on weo's sequence. Not a big deal
as far as the uniqueness of the member table's PK because no member
records will be inserted based on feo's sequence. But, it seems messy and
if there is a reason you are using a global sequence, well, this will no
doubt fuck that up royally.

We could always bump the sequence up, but i think that's a losing battle
considering weo will be more popular that feo (at least until I wipe out
feo's competition with strategic ddos attacks). Speaking of:

X-No-Archive: Yes

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

Well, right now it's just weo and feo running the evolt CMS, eh?

It's just the nature of the content. And this is about content. THe nature
of weo's content just doesn't need metadata (oh, you have no idea how long
i've wanted to use that word. oh well. enough metadata.). If there is an
article about ASP or relational integrity (*cough*), those words will most
likely show up in the content body, and therefore is easily
searchable. Recipes... not so much.

Structured metadata.

>or if you're the
>first, what is it doing for you that the other apps can also use... 

Other apps could surely use it. Though I don't see much use for it on weo.

>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")

Ich bein ein DBA?

"Me fail English?  That's unpossible!"

There must have been a door there in The Wall.

er... oh yeah... database...

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

Well, you're starting to sound like an old boss of mine who would ask
those questions, but obviously didn't know what the answers meant. I know
you know what the answers mean and aren't just asking the questions to
hear your own voice, but, well, it's still scary, so I'll just move on.

>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!!!"

Yeah.

One of the things is, Joe Users's feo member id has to be the same as his
weo member id. Well, it doesn't have to, but for me to do what I want it
does. And there's usually hell to pay if I don't get what I want. I mean,
just ask dan. You don't think he just let me take over feo, did you? That
broken foot of his is *not* a coincidence.

>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

clich`es (and rhymes) aside, any help/insight you provide... is much
appreciated.

>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

Werd.

>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...

Well, as you can see, I have thoughts on the subject. But one of my
weaknesses is seeing how changes to the database side of things NOW will
effect things down the road. That's where you step in, I think.

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

Had to look that up btw. But, you knew that.

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

Well, your shot, I guess.

thelist has been too quiet lately anyways.

=)


Thanks bro,


--
mattwarden
mattwarden.com