Hello, list. First post here, I think.
So I've worked with several *lousy* DB engines and *poorly* designed databases behind crappy applications over these
manyyears. I look forward to moving everything to PG. First issue is addressed.
Now with the grand opportunity to be hoist upon my own petard on issues 2 and 3, DB design-wise, I have a question. Or
several,but I'll try to stick to one. ;-)
I have a situation where a location may belong to a larger corporation, for instance. In some cases, they may belong to
morethan one corporation. Corporation is someone we-wee can bill or pay. Everyone else is not belonging to this set.
There's probably a name for this kind of model and it's probably trivial but I'm always in the dark when it comes to CS
terms.
Anyway, my thought is to make a table with two columns (loc_id, corp_id) and unique ID would be the combination of the
two.
Is that about right? I guess the question is answered by knowing how I need to use the information..??
Well, to find possible 'billable' locations, i.e. those with a 'corp' ID (this ID relates to a certain structure of
charges,for example). The corp table will have a default location for AR/AP, which could be the same ID as the location
searchedfor. Presenting a corp should give a list of possibly multiple locations. And so on…
So, pretty much I would use a join with this table depending on how I want to use the data..?? I'm trying to be
flexiblebut combine four different tables of addresses, keeping the functions they represent. Or, like that.
Anyway, I'm just asking generally if I could be painting myself into a corner here. And hoping I'll eventually find a
wayto ask the right questions. TIA for any help or suggestions. '-)
Cheers,
-- |\ /| | | ~ ~ | \/ | |---| `|` ?| |ichael | |iggins \^
/michael.higgins[at]evolone[dot]org
