1st normal form question How many tables is too many??
From: shawn <robertshawnmitchell_at_yahoo.com>
Date: 19 Oct 2001 07:59:51 -0700
Message-ID: <c3547d5c.0110190659.8d7454d_at_posting.google.com>
Okay, I have ACCOUNTs, ACCOUNTGROUPs, TRANSACTIONGROUPs and TRANSACTIONS. ACCOUNTs can have TRANSACTIONs, and be members of ACCOUNTGROUPs and TRANSACTIONGROUPs. In addition, ACCOUNTGROUPs can be members of TRANSACTIONGROUPs. So far so good. Now these TRANSACTIONs link to backend sysetms which require various little tidbits of data like IDs, passwords, email addresses, etc. There is no consistancy to the data requirements of the various backend systems. So what I am considering is a BAGGAGE table. But this is getting kind of busy now, because BAGGAGE amy be associated with an ACCOUNTGROUP or an ACCOUNTGROUP-TRANSACTIONGROUP relationship (or any other entity or relationship) so we are getting into a fairly large and complex (for me anyway) set of tables and relationships. I also think that the BAGGAGE is potentially many-to-many so that I will need for example a ACCOUNTGROUP-TRANSACTIONGROUP-BAGGAGE table, ACCOUNTGROUP-BAGGAGE, TRANSACTIONGROUP-BAGGAGE, ACCOUNT-ACCTOUNTGROUP-BAGGAGE, ad infinitum (almost).
Date: 19 Oct 2001 07:59:51 -0700
Message-ID: <c3547d5c.0110190659.8d7454d_at_posting.google.com>
Okay, I have ACCOUNTs, ACCOUNTGROUPs, TRANSACTIONGROUPs and TRANSACTIONS. ACCOUNTs can have TRANSACTIONs, and be members of ACCOUNTGROUPs and TRANSACTIONGROUPs. In addition, ACCOUNTGROUPs can be members of TRANSACTIONGROUPs. So far so good. Now these TRANSACTIONs link to backend sysetms which require various little tidbits of data like IDs, passwords, email addresses, etc. There is no consistancy to the data requirements of the various backend systems. So what I am considering is a BAGGAGE table. But this is getting kind of busy now, because BAGGAGE amy be associated with an ACCOUNTGROUP or an ACCOUNTGROUP-TRANSACTIONGROUP relationship (or any other entity or relationship) so we are getting into a fairly large and complex (for me anyway) set of tables and relationships. I also think that the BAGGAGE is potentially many-to-many so that I will need for example a ACCOUNTGROUP-TRANSACTIONGROUP-BAGGAGE table, ACCOUNTGROUP-BAGGAGE, TRANSACTIONGROUP-BAGGAGE, ACCOUNT-ACCTOUNTGROUP-BAGGAGE, ad infinitum (almost).
So where is the question you ask... here it is: Do this make any sense to you. Is there a better / normal / known pattern way to do this? I am a Java developer and I've been thrust into this so my knowledge of SQL design principals is rudementary (sp?) at best. In any case thank you in advance for any thoughts, links, advice you may have. And if this is not the proper forum for this post I really appologize.
Thanks,
Shawn Received on Fri Oct 19 2001 - 16:59:51 CEST