On Jul 9, 2009, at 9:21 PM, fREW Schmidt wrote:
Anyway, I'm reading up on what another poster said about nulls in
the db. So far I'm not convinced, but give me a while to read up on
some of this stuff. I'd appreciate any other, more complete links
relating to nulls in the database.
It just seems to me that it make sense to have undefined values in a
field, but I need to think through that some more.
Both sides of this allow/disallow NULL issue are well represented
online. I find that we generally pick one camp to fall into and
rationalize our choices accordingly.
For what it's worth, here is my rationalization...When using any ORM,
I strive to create data objects that closely resemble my programmed
ones. When I find myself "needing" a NULL, it often means I have not
really defined my class properly.
From your original example you defined QCParts as having Fixtures.
If a QCPart can exist without a Fixture, then the Fixture does not
belong in the QCPart class. And you might need q_c_part_id in
Fixtures or a Fixtures_QCParts table depending on the reverse
relationship.
If a QCPart cannot exist without a Fixture, then it seems that it
should not be allowed to be unknown but may be allowed to be undefined-
because per Darren Duncan's suggestion.
-Ryan
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
