Dody,
Thanks for your clear explanation.
Regards,
Mike
Kenneth,
> maybe i was jumping to conclusions - what i am saying is that a
> rdbms has the capacity to implement a lot of business logic within
> the rdbms itself, so one should attempt to put the maximum of the
> business logic there, where it will be looked after by the db
> itself rather than
On Tuesday 10 Jan 2006 9:51 am, Mike wrote:
> but necessary enough. The point I was making was, what's the
> difference between a primary key vs. any other unique field?
database design mandates that every row in a table must be unique.
Where there is a serial data type as the primary key, this
In my experience, some designers used primary key to enforce logical
parent/child relationship (where the parent's pk is prefixed into one of
the child's primay key), and usually to signify the pk fields to be
"uneditable" since it actually also doubles as "foreignkey", the value
refer to
On Tuesday 10 Jan 2006 9:51 am, Mike wrote:
> hemm. So, database by definition is heavy/inefficient in regard
> to scalability? If so, please instruct me with some pointers
> where I can better approach my current project as I am still in
> planning phase.
sorry, i had a bad morning with someone
On Tuesday 10 Jan 2006 9:12 am, Mike wrote:
> Thank you for your elaborate and informative response. I guess I
> fail to properly understand the significance of Primary Keys.
> Isn't it there just to make our records Unique? Then, who cares
> if the other XXX_id's are unique or not! I'd rather
> I wouldn't recommend approach #2, because it's a slightly messy
> database layout, but it would still work with Django as long as the
> "user" field of NewsPosting was a ForeignKey(User).
Thanks for your response,
Mike
On 1/9/06, Mike <[EMAIL PROTECTED]> wrote:
> Actually, this was the 'aha' answer to my question. Thank you. On a
> different note, is there anyway to implement approach #2, having
> NewsPosting have a user_id field in django-way? If not so, is there any
> reason why not?
I wouldn't recommend
Adrian,
Actually, this was the 'aha' answer to my question. Thank you. On a
different note, is there anyway to implement approach #2, having
NewsPosting have a user_id field in django-way? If not so, is there any
reason why not?
Regards,
Mike
Having said that, I just remembered there's a common practice in
designing database that I could never done in any ORM (not only
django's), and that is to have a group of fields as primary key. Ie:
Company table
- company id (pk)
- name
Employee
- company id (pk)
-
My approach is, if you would often be needing to get list of news both
by company and user, for performance reason I would put both foreignkey
(one 2 many) to company and user in newsposting model. That way, the
resulting join query only need to join maximum of two tables and be
faster.
> Thanks Patrick,
>
> So, you are voting for the second model. I think Django should have
> such relationship builtin where I can avoid defining user_id as a field
> in my news table.
actually, i don´t really see a difference between model 1 and 2.
you have a company which you assign users to.
Thanks Patrick,
So, you are voting for the second model. I think Django should have
such relationship builtin where I can avoid defining user_id as a field
in my news table.
I maybe wrong but I don't think (news.get_user.username) works in
templates. I have to double check.
Regards,
Mike
within a view you could use
news_list = news.get_list(user__id__exact=request.user.id)
for the logged-in user
to get the user within the template use
news.get_user.username
...
http://www.djangoproject.com/documentation/db_api/#many-to-one-relations
hope that helps,
patrick
>
> Hi,
>
> I
Hi,
I have a model with multiple companies (Basecamp Style), where each
have multiple users and multiple company news. Which of the two way is
more appropriate:
1: Company -one-to-many> User one-to-many> NewsPosting
2: Company -one-to-many> User
15 matches
Mail list logo
