On Dec 1, 9:51 pm, "Bret Walker" <[EMAIL PROTECTED]> wrote:
> On 12/1/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On 12/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > 1. Mark fields as optional.
> > > I don't like this because there will be lots of null values
> > > inserted into the database. I also don't think that this would be
> > > following SQL best practices.
>
> > Well, even in PHP you were going to have null columns. What you really
> > seem to want is a way to say, in SQL,
>
> > create table ticket (
> > user_id integer not null references "end_user" ('id') or references
> > "temp_user" ('id')
> > );
>
> > Except databases don't work that way ;)
>
> > So no matter what, you're going to get optional fields, with some
> > filled in for "real" users and NULL otherwise (and vice-versa).
>
> > Given that, optional fields seem to be the way to go. Use the admin,
> > train your staff on which fields need to be used in which situations,
> > and move on.I may not have been clear in my description of how I see the
> > database working.
> In the ticket table, there would be a bool dictating whether or not
> the ticket if for end_user or temp_user. There would also be a field
> for the id of the end or temp user (the user data would be in another
> table). If foreign keys were required, I guess there could be two
> columns, one for end_user id and one for temp_user id, one of which
> would always be null. This would at least allow the admin interface
> to display similar data the table view. This seems like a perfect
> application of model inheritance. The admin interface could display
> the columns that the parent class has (which means all child classes
> would have them as well).
>
> If I use optional fields, I'm going to end up having disparate columns
> that hold the same type of date (name, email, phone). This doesn't
> make sense to me. It also will render the admin interface ineffective
> (since, for example, I won't be able to sort by name because there
> will be two name columns). This is also impractical because I require
> too much information for the end_user objects. Trying to collect the
> data for each end user each time a ticket is created will lead to
> inconsistent data and wasted time.
>
> Surely someone has an eloquent solution to this type of problem, which
> I'm sure has come up before.
>
> Thanks for all of the quick responses.
>
> Bret
No answers to my questions? I'm thinking that my problem may be
related to the SQLAlchemy work that is going on. Is this the case?
Also, I tried to make my ForeignKey field optional, as suggested, but
Django threw an error saying that it had to have a value.
Bret
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
