On 23 Oct 2002 at 9:39, Josh Berkus wrote:
<snip>
> 1) I am not reccomending that you use this approach for addresses --
> the standard relational model will serve your purposes, so there's not
> reason to get creative. I was reccomending that you try the "flexible
> child" approach *only* for the BLOB reference table.
OK, I'm convinced. I will apply the "arc" only when there is no other
way. For the addresses I will use the relational method.
> 2) In answer to your question: Imagine that I have 5 tables, clients,
> employees, invoices, orders, and payments. Imagine that each table
> has roughly 20,000 rows. Each table also has a row in the "mod_data"
> table. If I want to query the mod_data for a particular client, then
> the database has to search 100,000 rows, not the 20,000 it would search
> if the mod_data were directly in the clients table. get it?
>
> > Do you have an URL to such systems? I'm not familiar with them, I
> > guess
> > you don't mean journalling filesystems? TIA!
>
> I'm talking about triggers or other mechanisms that record each change
> to the database records into a permanent archive for auditing purposes.
Oh, I see.
> > With the info I have so far, I plan to work like this:
>
> See above. As I said before, I feel that the "flexible child" approach
> is a *bad* approach for storing the addresses. I just suggested it
> for the BOLBs. For the addresses, see my first e-mail to you on the
> topic.
I will, thanks again for all your help!
