The SQL select function will allow you to perform cross-table searching far
more effectively that the method you suggest.
select * from orgs_table,org_list where orgs_table.userid = org_list.userid
and org_list.userid = $required_match
It's not a perl thing though - it's very definitely a DB design thing. The
essence of DB design, in fact. Perl is flexible enough to allow you to
perform workrounds so that you can get workable results from bad DB design
but what you are thinking of in your proposal will really really start to
hurt if you accummulate a significant number of records.
On 5/30/07 6:15 PM, essential quint at quintessential1%40hotmail.com">quintessential1
hotmail.com wrote:
>
> I've been working on a DB design for use with Perl DBI, and I am kind of
> stuck.
>
> The general problem I'm confronting right now is developing a registration
> section for two different types of entities: 1.) orgs and 2.) individuals, and
> then allow each type of user to log in and run a session under their account.
> Orgs and Individuals each get their own table in the DB, as their profile
> information is uniquely different. That's not particularly difficult. The
> hard part is that I want the individual users to be able to join different
> orgs (org list), as well as add other members to buddy lists. And, vice versa
> with orgs, who should be able to add moderators or members have different orgs
>; assign different members/mods.
>
> I'm considering setting up separate tables, like so:
>
> buddy_list {
> blist (primary key)
>; userid (foreign key; id from account holder's profile)
> buddy_id (foreign key; id from buddy's account profile)
> }
>
> org_list {
> olist (primary key)
>; userid (foreign key; id from account holder's profile)
> org_id (foreign key; id from org's account profile)
> }
>
> The problem with this design is that there's no information other than id's,
> and a list of reference numbers wouldnt mean much to the end user. I could
> put in duplicate data from the profile tables, like username, etc., but that
>; would go against normalization.
>
> But I had a different idea..
>
> What if I ran a loop/query just to get the id numbers from the buddy list,
> tucked those numbers into an array, and then looped through the array to query
> each element in the array in the profile table. I think that might work.
>
> Now to sum up my questions (before I go through all that coding).
>
> 1.) I am wondering if this is feasible? And, if so, how? Would I have to
> nest the second loop? Or should I just run through one loop and then the
> other in sequence?
>
> 2.) If it is possible, and, if I have it right, would this be what (I think)
> is called a 2D array?
>
> 3.) Would it take a long time (or too long) to execute? And, if so, then are
> there any ways to make it execute faster?
>
> Okay, I'll shut up now... If you've read this far, thank you!
>; 
>
> ~q
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __________________________________________________________
> Create the ultimate e-mail address book. Import your contacts to Windows Live
>; Hotmail.
> www.windowslive-hotmail.com/learnmore/managemail2.html?locale=en-us&;ocid=TXT_T
> AGLM_HMWL_reten_impcont_0507
>
> [Non-text portions of this message have been removed]
>
>
>
> Unsubscribing info is here:
> http://help.yahoo.com/help/us/groups/groups-32.html
> Yahoo! Groups Links
>
>
>
.
