Re: Database Design Question

On Thu, Jul 21, 2011 at 5:35 PM, Marc Aymerich wrote: > > ups, I think it should be: > contract.products.filter(id=Y).values_list('rebate_pct', flat=True) > product.contractproduct_set.filter(id=X).values_list('rebate_pct', > flat=True) Thanks. The first one does not work

Re: Database Design Question

On Thu, Jul 21, 2011 at 11:33 PM, Marc Aymerich wrote: > > > On Thu, Jul 21, 2011 at 11:11 PM, nixlists wrote: > >> On Thu, Jul 21, 2011 at 4:30 PM, Jani Tiainen wrote: >> > ContractProduct.objects.all() >> > Following might work

Re: Database Design Question

On Thu, Jul 21, 2011 at 11:11 PM, nixlists wrote: > On Thu, Jul 21, 2011 at 4:30 PM, Jani Tiainen wrote: > > ContractProduct.objects.all() > > Following might work also (not sure, but is easy to test in shell for > > example): > > for c in

Re: Database Design Question

On Thu, Jul 21, 2011 at 4:30 PM, Jani Tiainen wrote: > ContractProduct.objects.all() > Following might work also (not sure, but is easy to test in shell for > example): > for c in Contract.objects.all(): >     for cp in c.contractproduct_set.all(): >         print c,

Re: Database Design Question

On Thu, Jul 21, 2011 at 10:50 PM, nixlists wrote: > On Thu, Jul 21, 2011 at 2:17 PM, Jani Tiainen wrote: > > Hi, > > So you want to tie Contract with Product(s) with rebate_pct? You then > need > > custom intermediary m2m table say "ContractProduct" > >

Re: Database Design Question

On Thu, Jul 21, 2011 at 2:17 PM, Jani Tiainen wrote: > Hi, > So you want to tie Contract with Product(s) with rebate_pct? You then need > custom intermediary m2m table say "ContractProduct" >

Re: Database Design Question

Hi, So you want to tie Contract with Product(s) with rebate_pct? You then need custom intermediary m2m table say "ContractProduct" https://docs.djangoproject.com/en/1.3/topics/db/models/#intermediary-manytomany> for more. So in the end your models would probably look a alike following: class

Re: Database Design Question

Sorry about formatting. Also the there is a mistake. "I'd like to define the Product model..." should be "I'd like to define the Contract model... Thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to

Database Design Question

Hi. I have a question about writing normalized models. I began writing an app that has non-normalized tables, and would like to rewrite it with a normalized design. I have non-normalized legacy tables like this without foreign keys or many-to-many relationships, which I would like to have.

Re: Database Design Question

> > > The sample type table is only needed to generate a form for new samples. > >  The attribute table could be broken up by data type if necessary as well. > > > Sent from my Verizon Wireless BlackBerry > > > -Original Message- > > From: llan

Re: Database Design Question

well. > > Sent from my Verizon Wireless BlackBerry > > -Original Message- > From: llanitedave <llanited...@veawb.coop> > Date: Fri, 18 Jun 2010 23:27:55 > To: Django users<django-users@googlegroups.com> > Subject: Re: Database Design Question > > Th

Re: Database Design Question

from my Verizon Wireless BlackBerry -Original Message- From: llanitedave <llanited...@veawb.coop> Date: Fri, 18 Jun 2010 23:27:55 To: Django users<django-users@googlegroups.com> Subject: Re: Database Design Question Thanks for the response, Venkatraman. You're right that I don

Re: Database Design Question

Hallöchen! llanitedave writes: > [...] > > I guess it's mostly a normalization question. > > And while I was typing out a long explanatory discussion to > enlarge on the problem, I stumbled across the answer. > > I'll need to use a separate table for each sample type to store > its unique set of

Re: Database Design Question

Thanks for the response, Venkatraman. You're right that I don't anticipate a huge number of records here -- a few hundred thousand at the extreme high end. Sharding isn't something I considered, and I don't think it would be necessary. I guess it's mostly a normalization question. And while I

Re: Database Design Question

On Sat, Jun 19, 2010 at 10:12 AM, Venkatraman S wrote: > Prefer a table like follows (tblname:samples): sampleid, samplename , > sampledesc etc etc > Ok - i missed explaining why i would recommend this: In most of the applications, maintainence is a bigger pain than

Re: Database Design Question

On Sat, Jun 19, 2010 at 4:28 AM, llanitedave wrote: > I'm putting together a system to track scientific samples of various > types. The "various types" is what's making me scratch my head at the > moment. > Prefer a table like follows (tblname:samples): sampleid,

Database Design Question

I'm putting together a system to track scientific samples of various types. The "various types" is what's making me scratch my head at the moment. Each sample type has a particular set of attributes, some of which are unique, others are shared with other sample types. For example, a fluid

Re: Database design question

Validation turns out to be well-nigh impossible using parent / child aliases, but pretty easy with parent / child accounts. Here's what I've ended up with: class Account(models.Model): user = models.ForeignKey(User, unique=True, null=True, blank=True) alias =

Re: Database design question

I'm not asking as a Django / foreign key thing. I'm having a lot of trouble referencing each model from the other's save method for validation purposes, because there's always going to be one that's declared after the other. On Aug 19, 10:35 am, Joshua Russo wrote: >

Re: Database design question

You can, it just creates headaches. At least one of the ForeignKeys needs to not be required (I believe that's the default anyway). On Wed, Aug 19, 2009 at 1:27 PM, ringemup wrote: > > > Is having two classes that reference one another just simply something > that can't be

Re: Database design question

Is having two classes that reference one another just simply something that can't be done in Python? On Aug 19, 4:36 am, Joshua Russo wrote: > On Tue, Aug 18, 2009 at 11:04 PM, ringemup wrote: > > > Well, I'm trying to implement parent / child

Re: Database design question

On Tue, Aug 18, 2009 at 11:04 PM, ringemup wrote: > > Well, I'm trying to implement parent / child aliases, but I'm running > into problems with class declaration order because I need to reference > the Alias class from within the Account class as well as referencing > Account

Re: Database design question

Well, I'm trying to implement parent / child aliases, but I'm running into problems with class declaration order because I need to reference the Alias class from within the Account class as well as referencing Account from Alias for validation purposes -- and not just in ForeignKey declarations

Re: Database design question

On Tue, Aug 18, 2009 at 8:26 PM, ringemup wrote: > > I have accounts that can have multiple aliases, but each account must > have a primary alias. I can think of two ways to institute this, but > they both have problems: > > 1) reference the primary alias from the account: >

Re: Database design question

Yup, that could work too. Let me know what you end up with. On Tue, Aug 18, 2009 at 9:58 PM, ringemup wrote: > > > Yes, I think that does make sense. Thank you! > > While pondering this, I also came up with a third option, which is to > make the alias data part of the

Re: Database design question

Yes, I think that does make sense. Thank you! While pondering this, I also came up with a third option, which is to make the alias data part of the Account model, and allow Accounts to have parent accounts; then only accounts with no parents are permitted to be assigned to users. (Also

Database design question

I have accounts that can have multiple aliases, but each account must have a primary alias. I can think of two ways to institute this, but they both have problems: 1) reference the primary alias from the account: class Account(models.Model): ... primary_alias =

Re: Database design question

Hi Doug, On 4/26/07, Doug Van Horn <[EMAIL PROTECTED]> wrote: > [Links] > There's no harm in having unique columns in addition to your primary > key (as you describe). The nut of the problem around natural keys, > IMHO, is that the rules that make them natural keys today can change > such that

Re: Database design question

On Apr 25, 3:16 pm, "Kai Kuehne" <[EMAIL PROTECTED]> wrote: > > I'm a bit confused on how do it 'right(tm)'. Is there a > rule or how would you do it? > You're asking about surrogate and natural keys: http://en.wikipedia.org/wiki/Surrogate_key http://en.wikipedia.org/wiki/Natural_key

Re: Database design question

Why not do both. I've always preferred letting the database generate an auto primary key (id in django) even if my usage is primarily a different column for key. Storing an int isn't wasting much space, what do you have to lose? I've got a users object for example that requires a unique email

Re: Database design question

A point that I missed was the speed. Is method 1) maybe faster than method 2? I think it could.. because in 1) there are only numbers stored as primary_key and not strings (which can be as long as 255 characters). Speed is one thing.. but is there any other difference between the two methods?

Re: Database design question

Hi, On 4/25/07, Mike Caldwell <[EMAIL PROTECTED]> wrote: > I don't think there is a "right(tm)" way, but there are some things to > consider. A lot of people would argue that a unique characteristic makes a > very good primary key, I think I might be one of them. But, remember that > data

Re: Database design question

I don't think there is a "right(tm)" way, but there are some things to consider. A lot of people would argue that a unique characteristic makes a very good primary key, I think I might be one of them. But, remember that data reflects the real world. In general, a person's name isn't very

Database design question

Hello list, I have a question regarding general database design. Ok.. which method would you recommend, if you have a table with a field 'name' which values should be unique in the whole table? 1) use (implicit) id which is automatically added by django, as primary key and a 'name' field with