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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
