Hmm, I'm currently using a recursive ('self') Many2Many and ForeignKey
for Children and Spouse, respectively (see source in the first post).
Is that what you meant?
Or perhaps I'm not quite getting what you mean - any chance you could
paste a models.py example so I can make sure I'm on the same page?
Cheers,
Victor
On Nov 30, 5:02 pm, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> On 30/11/2010 4:26pm, Victor Hooi wrote:
>
> > heya,
>
> > Phone Number - Yup, you're both right, I'll be using CharField now,
> > and model validation to make sure they're digits.
>
> > Spouse/Children:
>
> Victor
>
> I'm coming in late on this and don't have the context for your design
> but I think there might be a better (perhaps more flexible) way to
> handle spouses and children without worrying about NULLs.
>
> I really like a single table for everyone. After all spouses and
> children are persons too. You can use a separate table to hold named
> many-to-many relationships between the person table and itself.
>
> If the relationship is "Spouse" then that relationship speaks for
> itself. Children can simultaneously have relationships with "Father",
> "Mother", "Step-mother" etc. Other persons can have "Ex-spouse"
> relationships when divorced etc.
>
> If you can find any person then you can navigate through all the
> relationships to find all connected persons.
>
> Finally, if someone has multiple spouses then they probably need
> counselling but at least you can represent it with multiple relationship
> records :)
>
> Mike
>
>
>
>
>
>
>
>
>
> > With children, a M2M field, there's a link table, and if you don't
> > have a spouse, then there won't be any lines in that table. So no need
> > for NULLs there. I've just tested it with just blank=True, and no
> > null=True - seems to do what I want (optional children).
>
> > With ForeignKeyField though, I thought this was simply an FK field,
> > with the ID number of the object we're relating/pointing stored in
> > that field? Isn't that how it works in a normal DB? Why is there a
> > separate Person_spouse table?
>
> > Is there any way to make this optional without using NULLs, or should
> > I make it a m2m field? (I suppose in theory you can have multiple
> > spouses...well, not under my jurisdiction, I guess...lol).
>
> > Cheers,
> > Victor
>
> > On Nov 30, 3:11 pm, Lachlan Musicman<data...@gmail.com> wrote:
> >> On Tue, Nov 30, 2010 at 12:28, Victor Hooi<victorh...@gmail.com> wrote:
> >>> Hi,
>
> >>> I'm wondering what the community's stance on using NULL in Django is?
>
> >>> Say for example you have:
>
> >>> class Person(models.Model):
> >>> street_address = models.CharField(max_length=50, blank=True)
> >>> suburb = models.CharField(max_length=30)
> >>> postcode = models.IntegerField()
> >>> state = models.CharField(max_length=3)
> >>> email = models.EmailField()
> >>> mobile_phone_number = models.IntegerField(max_length=12)
> >>> home_phone_number = models.IntegerField(max_length=10,
> >>> null=True, blank=True)
> >>> work_phone_number = models.IntegerField(max_length=8,
> >>> null=True, blank=True)
>
> >>> spouse = models.ForeignKey('self', null=True, blank=True)
> >>> children = models.ManyToManyField('self', null=True,
> >>> blank=True)
>
> >>> For string fields like street_address, I can make these "blank=True",
> >>> and Django will store an empty string if the user leaves it blank.
>
> >>> However, for integer fields like home_phone_number and
> >>> work_phone_number, I've had to make these "null=True" for the case
> >>> where somebody doesn't supply them (i.e. they're meant to be optional,
> >>> mobile is required).
>
> >>> However, is there a better way of handling this case? (assuming I want
> >>> to keep these fields as integers).
>
> >> Is it possible to know why you would want to keep them as integers?
> >> Given that there are no mathematical functions that you would want to
> >> apply to them....
>
> >>> What about in the case of optional foreign keys (spouse and children)
> >>> - is there a better way of handling these, without using NULLs?
>
> >> As I understand it, foreign keys are kept in the db as follows:
>
> >> 1. table_Person
> >> 2. table_Person_children
> >> 3. table_Person_spouse
>
> >> table 2 has three columns: id, Person, Children
> >> table 3 has three columns: id, Person, Spouse
>
> >> or something to that effect.
>
> >> Therefore, if there is no Spouse or Child, there is no entry for
> >> Person in tables 2 or 3.
>
> >>> Cheers,
> >>> Victor
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "Django users" group.
> >>> To post to this group, send email to django-users@googlegroups.com.
> >>> To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
> >>> For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment