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 the
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
Kenneth,
> the whole idea of having an rdbms is that it maintains
> integrity of data. And data without unique primary keys is not
> data, it is junk
Well, if my app can't manage to respect the data integrity, then my app
is junk! I have no objection against data integrity either, redundant
but
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 imp
> 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
Dody,
> ...for performance reason I would put both foreignkey
> (one 2 many) to company and user in newsposting model...
I was actually thinking about that, was wondering if it breaks the
system for some unknown reason. I am glad it is common practice and I
can count on it within my application.
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 appr
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. Alth
On 1/9/06, Mike <[EMAIL PROTECTED]> wrote:
> 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 --
Thanks Patrick,
> actually, i don´t really see a difference between model 1 and 2.
In model 1, there is no direct relationship between the company table
and posting table, and for the company to find out what news it has, it
has to go through the users table. Also, for a posting to find out to
w
> 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. t
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 hav
18 matches
Mail list logo
