• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: database design patterns for the desperate
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: database design patterns for the desperate


  • Subject: Re: database design patterns for the desperate
  • From: Mark Morris <email@hidden>
  • Date: Wed, 11 May 2011 16:01:32 -0500

Similarly, could your templates be modeled using one table, with a one-to-many to itself? This might be more flexible in general, but of course I don't know your specifics.

Either way (either using a single class or a superclass of your three classes), perhaps you could teach the template to create the user's corresponding object, copy the relevant attributes, then loop through each of its children having them do the same (including creating the relationship to the parent).

Hope this helps!

Regards,
Mark

On May 11, 2011, at 3:51 PM, Mark Wardle wrote:

> Can you re-imagine your problem as objects instead of thinking of the
> database or do you have other code accessing SQL directly?
>
> Mark
>
> On 11 May 2011 20:14, Michael Gargano <email@hidden> wrote:
>> I was just talking to David Holt about this and he suggested I tap the brain trust.  :)
>>
>> I was wondering if there is a database design pattern for a situation where I have some template structure
>> let's say
>>
>>        tA <->> tB <->> tC  (records across these tables are the template, the template is a whole object graph rooted at one record in tA)
>>
>> where the templates can be configured on a per tenant basis (so, the templates themselves are records that define defaults and new ones can be added when new tenants or templates are added).  I need to make a copy of a template that a tenant uses and make it local to a user (under that tenant) who can then customize the values in that template for their needs.
>>
>> It's basically a class/instance kind of structure, but at the data level in the database.  It's as if I need to copy an EOs from one table to another where the destination table has a few more attributes than the source table did.  It's made more complicated by the fact that I need to copy that template object graph, not just one EO.
>>
>> Any suggestions?
>> *Hopes beyond hope*
>>
>> Thanks.
>> -Mike
>>
>>
>>  _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>>
>
>
>
> --
> Dr. Mark Wardle
> Specialist registrar, Neurology
> Cardiff, UK
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >database design patterns for the desperate (From: Michael Gargano <email@hidden>)
 >Re: database design patterns for the desperate (From: Mark Wardle <email@hidden>)

  • Prev by Date: Re: database design patterns for the desperate
  • Next by Date: qualifier to check for empty toMany
  • Previous by thread: Re: database design patterns for the desperate
  • Next by thread: Re: database design patterns for the desperate
  • Index(es):
    • Date
    • Thread