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 since rebate_pct is in the
contractproduct table.
--
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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
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 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, cp.product, cp.rebate_pct
>> > --
>> > Jani Tiainen
>>
>> Thanks. This works but kind of confusing, and I am looking for an easy
>> way to find rebate_pct given contract and product ids.
>>
>
> Something like this?
>
> ContractProduct.objects.filter(contract__id=X,
> product__id=Y).values_list('rebate_pct', flat=True)
>
> or if you already have a contract:
> contract.products.filter(product__id=Y).values_list('rebate_pct',
> flat=True)
>
> or product:
> product.contractproduct_set.filter(contract__id=Y).values_list('rebate_pct',
> flat=True)
>
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)
--
Marc
--
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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
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 Contract.objects.all():
> > for cp in c.contractproduct_set.all():
> > print c, cp.product, cp.rebate_pct
> > --
> > Jani Tiainen
>
> Thanks. This works but kind of confusing, and I am looking for an easy
> way to find rebate_pct given contract and product ids.
>
Something like this?
ContractProduct.objects.filter(contract__id=X,
product__id=Y).values_list('rebate_pct', flat=True)
or if you already have a contract:
contract.products.filter(product__id=Y).values_list('rebate_pct', flat=True)
or product:
product.contractproduct_set.filter(contract__id=Y).values_list('rebate_pct',
flat=True)
--
Marc
--
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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
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, cp.product, cp.rebate_pct > -- > Jani Tiainen Thanks. This works but kind of confusing, and I am looking for an easy way to find rebate_pct given contract and product ids. Thanks. -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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" > > 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 Contract(): > > contract_id = models.lIntegerField(...) > > products = models.ManyToManyField(Product, through='ContractProduct') > > class ContractProduct(): > > contract = models.ForeignKey(Contract) > > product = models.ForeignKey(Product) > > rebate_pct = models.DecimalField(max_digits=4, decimal_places=2) > > So now you can link Contract with multiple Products adding custom > rebate_pct > > value to each link. > > And what comes to rebate value, I think you want to keep value with > product > > linkage for two reasons: > > 1) It's a single scalar value > > 2) It's probably something that should not be changed ever after saving. > > hth, > > Thanks for your response, I think this will work. How would I write a > query to find the rebate_pct per contract per product? > > 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, cp.product, cp.rebate_pct -- Jani Tiainen -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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" > 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 Contract(): > contract_id = models.lIntegerField(...) > products = models.ManyToManyField(Product, through='ContractProduct') > class ContractProduct(): > contract = models.ForeignKey(Contract) > product = models.ForeignKey(Product) > rebate_pct = models.DecimalField(max_digits=4, decimal_places=2) > So now you can link Contract with multiple Products adding custom rebate_pct > value to each link. > And what comes to rebate value, I think you want to keep value with product > linkage for two reasons: > 1) It's a single scalar value > 2) It's probably something that should not be changed ever after saving. > hth, Thanks for your response, I think this will work. How would I write a query to find the rebate_pct per contract per product? Thanks! -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 Contract(): contract_id = models.lIntegerField(...) products = models.ManyToManyField(Product, through='ContractProduct') class ContractProduct(): contract = models.ForeignKey(Contract) product = models.ForeignKey(Product) rebate_pct = models.DecimalField(max_digits=4, decimal_places=2) So now you can link Contract with multiple Products adding custom rebate_pct value to each link. And what comes to rebate value, I think you want to keep value with product linkage for two reasons: 1) It's a single scalar value 2) It's probably something that should not be changed ever after saving. hth, -- Jani Tiainen On Thu, Jul 21, 2011 at 8:25 PM, newtodjango wrote: > 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 django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Database Design Question
Now that's a fascinating idea, because the three-table solution is very similar to something I tried in the 1990's using a tool called 4th Dimension. I've been out of database development for about a decade, and this is my first foray into Django since doing the tutorials. The previous database had only a few sample types, and the existing design limited our ability to expand. The idea that you've given here is pretty much the same one I came up with when trying to find a way to expand its capabilities. I never could get the interface quite the way I wanted it using 4D, and the idea was never implemented, but Django looks like it can give me a bit more flexibility. I hadn't thought of using a separate table for each attribute data type, though. That might be something to give a whirl to. Thanks, all! On Jun 19, 1:52 am, S Basl wrote: > Ok.. that wasn't really ideal, a better (and more normalized) solution might > look a bit like this: > > Sample Table: > -> sample_id (pk) > -> sample_type_id (fk) > -> other descriptive fields > Sample Type Table: > -> sample_type_id (pk) > -> other descriptive fields > > Attribute Type Table: > -> attribute_type_id (pk) > -> attribute_name > -> attribute_datatype > > Attribute Tables:* > ->attribute_id (pk) > -> sample_id (fk) > -> attribute_value > *one attribute table for each appropriate datatype, ie string attribute > table, integer attribute table, float attribute table, etc. > > With the above schema you should be able to allow users to define sample > types, store those definitions in the database, and programattically create > the necessary forms for any sample type necessary. > > On Sat, Jun 19, 2010 at 3:34 AM, wrote: > > I'm thinking you should be able to do this without having users create > > tables. Three separate tables should be enough. Maybe more if you want to > > get fancy. > > > Sample table: holds sample id & sample type (fk) > > > Sample type table: holds sample type id & comma separated list which > > defines number and type of attributes for that type of sample. > > > Attribute table: holds attribute name, attribute value, and foreign key to > > a sample id. > > > 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: llanitedave > > Date: Fri, 18 Jun 2010 23:27:55 > > To: Django users > > Subject: 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 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 attributes. > > > For example, a fluid sample type might have the fields: volume, > > concentration, pH, and expiration date. > > A soil sample might have the fields: Clay content, color, grain size, > > moisture content. > > > All sample types will have the common fields sample ID, sample type, > > date collected, collector, source, and storage location. > > > So I'll need a generic "Sample" table and then related tables for each > > sample type. > > > The difficulty is that many sample types are still undefined, and will > > have to be defined by the individual users. That means they'll have > > to have an interface that allows them to create tables and fields in > > the database. I suppose I can put together a form for that which will > > ensure it gets done in a limited, consistent and standard way. > > > I'm thinking out loud here, but it's getting the feedback that helped > > to clarify it. Any other comments or suggestions will be welcome. > > > On Jun 18, 9:46 pm, Venkatraman S wrote: > > > 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 > > development. > > > > In your cas
Re: Database Design Question
Ok.. that wasn't really ideal, a better (and more normalized) solution might look a bit like this: Sample Table: -> sample_id (pk) -> sample_type_id (fk) -> other descriptive fields Sample Type Table: -> sample_type_id (pk) -> other descriptive fields Attribute Type Table: -> attribute_type_id (pk) -> attribute_name -> attribute_datatype Attribute Tables:* ->attribute_id (pk) -> sample_id (fk) -> attribute_value *one attribute table for each appropriate datatype, ie string attribute table, integer attribute table, float attribute table, etc. With the above schema you should be able to allow users to define sample types, store those definitions in the database, and programattically create the necessary forms for any sample type necessary. On Sat, Jun 19, 2010 at 3:34 AM, wrote: > I'm thinking you should be able to do this without having users create > tables. Three separate tables should be enough. Maybe more if you want to > get fancy. > > Sample table: holds sample id & sample type (fk) > > Sample type table: holds sample type id & comma separated list which > defines number and type of attributes for that type of sample. > > Attribute table: holds attribute name, attribute value, and foreign key to > a sample id. > > 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: llanitedave > Date: Fri, 18 Jun 2010 23:27:55 > To: Django users > Subject: 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 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 attributes. > > For example, a fluid sample type might have the fields: volume, > concentration, pH, and expiration date. > A soil sample might have the fields: Clay content, color, grain size, > moisture content. > > All sample types will have the common fields sample ID, sample type, > date collected, collector, source, and storage location. > > So I'll need a generic "Sample" table and then related tables for each > sample type. > > The difficulty is that many sample types are still undefined, and will > have to be defined by the individual users. That means they'll have > to have an interface that allows them to create tables and fields in > the database. I suppose I can put together a form for that which will > ensure it gets done in a limited, consistent and standard way. > > I'm thinking out loud here, but it's getting the feedback that helped > to clarify it. Any other comments or suggestions will be welcome. > > On Jun 18, 9:46 pm, Venkatraman S wrote: > > 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 > development. > > > > In your case, i do not think that this table would contain a billion > records > > and even if it does, this design helps in sharding. Maintaining this > system > > in latter case would be more of a db-admin or sys-admin job - and already > > there are many solutions in addition to sharding, when the size of a > single > > table is HUGE. (when Facebook can contain the entire 32Gb profile data in > > the RAM, doesnt the world look small? ;) ) > > > > -V-http://twitter.com/venkasub > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Database Design Question
I'm thinking you should be able to do this without having users create tables. Three separate tables should be enough. Maybe more if you want to get fancy. Sample table: holds sample id & sample type (fk) Sample type table: holds sample type id & comma separated list which defines number and type of attributes for that type of sample. Attribute table: holds attribute name, attribute value, and foreign key to a sample id. 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: llanitedave Date: Fri, 18 Jun 2010 23:27:55 To: Django users Subject: 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 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 attributes. For example, a fluid sample type might have the fields: volume, concentration, pH, and expiration date. A soil sample might have the fields: Clay content, color, grain size, moisture content. All sample types will have the common fields sample ID, sample type, date collected, collector, source, and storage location. So I'll need a generic "Sample" table and then related tables for each sample type. The difficulty is that many sample types are still undefined, and will have to be defined by the individual users. That means they'll have to have an interface that allows them to create tables and fields in the database. I suppose I can put together a form for that which will ensure it gets done in a limited, consistent and standard way. I'm thinking out loud here, but it's getting the feedback that helped to clarify it. Any other comments or suggestions will be welcome. On Jun 18, 9:46 pm, Venkatraman S wrote: > 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 development. > > In your case, i do not think that this table would contain a billion records > and even if it does, this design helps in sharding. Maintaining this system > in latter case would be more of a db-admin or sys-admin job - and already > there are many solutions in addition to sharding, when the size of a single > table is HUGE. (when Facebook can contain the entire 32Gb profile data in > the RAM, doesnt the world look small? ;) ) > > -V-http://twitter.com/venkasub -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 attributes. > > For example, a fluid sample type might have the fields: volume, > concentration, pH, and expiration date. A soil sample might have > the fields: Clay content, color, grain size, moisture content. > > All sample types will have the common fields sample ID, sample > type, date collected, collector, source, and storage location. > > So I'll need a generic "Sample" table and then related tables for > each sample type. In our nanotech institute, we have already created a samples database with Django. We used an approach very similar to yours: There is the "Sample" model with almost no fields -- more or less, just the sample name. Then, there is a "Process" model with a timestamp, and an M2M relationship with "Sample". And finally, there is a plethora of models derived from "Process" through multi-table inheritace. Etching processes, deposition processes, measurements etc. Even properties inherent to a sample like sample size or sample substate are organised in special processes. Now, the sample's datasheet simply is the list of all related processes, in timestamp order. > The difficulty is that many sample types are still undefined, and > will have to be defined by the individual users. That means > they'll have to have an interface that allows them to create > tables and fields in the database. I suppose I can put together a > form for that which will ensure it gets done in a limited, > consistent and standard way. We haven't thought about this yet, and we won't do this probably. What we *may* implement someday is that the administrator can create new processes without programming. But this still includes restarting the server. On the other hand, we've defined a "general purpose" process with a spreadsheet-like 2D array, and the user can set the column names arbitrarily. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 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 attributes. For example, a fluid sample type might have the fields: volume, concentration, pH, and expiration date. A soil sample might have the fields: Clay content, color, grain size, moisture content. All sample types will have the common fields sample ID, sample type, date collected, collector, source, and storage location. So I'll need a generic "Sample" table and then related tables for each sample type. The difficulty is that many sample types are still undefined, and will have to be defined by the individual users. That means they'll have to have an interface that allows them to create tables and fields in the database. I suppose I can put together a form for that which will ensure it gets done in a limited, consistent and standard way. I'm thinking out loud here, but it's getting the feedback that helped to clarify it. Any other comments or suggestions will be welcome. On Jun 18, 9:46 pm, Venkatraman S wrote: > 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 development. > > In your case, i do not think that this table would contain a billion records > and even if it does, this design helps in sharding. Maintaining this system > in latter case would be more of a db-admin or sys-admin job - and already > there are many solutions in addition to sharding, when the size of a single > table is HUGE. (when Facebook can contain the entire 32Gb profile data in > the RAM, doesnt the world look small? ;) ) > > -V-http://twitter.com/venkasub -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 development. In your case, i do not think that this table would contain a billion records and even if it does, this design helps in sharding. Maintaining this system in latter case would be more of a db-admin or sys-admin job - and already there are many solutions in addition to sharding, when the size of a single table is HUGE. (when Facebook can contain the entire 32Gb profile data in the RAM, doesnt the world look small? ;) ) -V- http://twitter.com/venkasub -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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, samplename , sampledesc etc etc Define another tbl(tblname:sample_types): sampleid(this refers to samples.sampleid) ,sampletype ,samplevalue sampletype and samplevalue above would contain the relationship. In your case (for eg) : sampleid sampeletype samplevalue 1001Concentration 0.9 Prefer some other naming convention for sampletype-samplevalue. (param:value?) -V- http://twitter.com/venkasub -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 = models.CharField(max_length=32, unique=True)
parent_account = models.ForeignKey('self', related_name='children',
null=True, blank=True)
def __unicode__(self):
return '%s owned by %s' % (self.alias, self.get_owner())
def save(self, force_insert=False, force_update=False):
if not Account.is_valid_parent_or_child(self.user,
self.parent_account):
raise AccountInheritanceError
super(Account, self).save(force_insert, force_update)
def get_canonical_alias(self):
if self.is_child():
return self.parent_account.get_canonical_alias()
return self.alias
def get_owner(self):
if self.is_child():
return self.parent_account.get_owner()
return self.user
@staticmethod
def is_valid_parent_or_child(user, parent_account):
# We need either a user (meaning this is a primary account)
# or a parent (meaning this is a child account), but not both
if bool(user) == bool(parent_account):
return False
if parent_account.is_child():
return False
return True
def is_parent(self):
return bool(self.user)
def is_child(self):
return bool(self.parent_account)
I'll probably end up shunting any required account fields into a
Profile model and either a)attaching that to Account with a nullable
one-to-one relationship, and making that required for parent accounts;
or b) making the Profile model the AUTH_PROFILE_MODULE rather than
Account (which is currently).
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
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: > 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 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 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 and such. > > > > > Since one will always have to be declared before the other, is there > > > > any way to do this? > > > > What I would recommend is to drop the ForeignKey in the Account table. > > You > > > can always retrieve the set of Aliases for an Account based on the > > > ForeignKey from Alias to Account. I believe that you will even be able to > > > access Account.alias_set in your code, though if not you can always get > > > Alias.objects.filter(Account_id=xx) and for the primary you will be able > > to > > > say either Account.alias_set.filter(parent__isnull=True)or > > > Alias.objects.filter(Account_id=xx).filter(parent__isnull=True) --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
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 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 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 and such. > > > > > Since one will always have to be declared before the other, is there > > > any way to do this? > > > > What I would recommend is to drop the ForeignKey in the Account table. > You > > can always retrieve the set of Aliases for an Account based on the > > ForeignKey from Alias to Account. I believe that you will even be able to > > access Account.alias_set in your code, though if not you can always get > > Alias.objects.filter(Account_id=xx) and for the primary you will be able > to > > say either Account.alias_set.filter(parent__isnull=True)or > > Alias.objects.filter(Account_id=xx).filter(parent__isnull=True) > > > --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
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 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 and such. > > > Since one will always have to be declared before the other, is there > > any way to do this? > > What I would recommend is to drop the ForeignKey in the Account table. You > can always retrieve the set of Aliases for an Account based on the > ForeignKey from Alias to Account. I believe that you will even be able to > access Account.alias_set in your code, though if not you can always get > Alias.objects.filter(Account_id=xx) and for the primary you will be able to > say either Account.alias_set.filter(parent__isnull=True)or > Alias.objects.filter(Account_id=xx).filter(parent__isnull=True) --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
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 from Alias for validation purposes -- and not just in > ForeignKey declarations and such. > > Since one will always have to be declared before the other, is there > any way to do this? What I would recommend is to drop the ForeignKey in the Account table. You can always retrieve the set of Aliases for an Account based on the ForeignKey from Alias to Account. I believe that you will even be able to access Account.alias_set in your code, though if not you can always get Alias.objects.filter(Account_id=xx) and for the primary you will be able to say either Account.alias_set.filter(parent__isnull=True)or Alias.objects.filter(Account_id=xx).filter(parent__isnull=True) --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
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 and such.
Since one will always have to be declared before the other, is there
any way to do this?
On Aug 18, 7:02 pm, Joshua Russo wrote:
> 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 Account model, and allow Accounts to
> > have parent accounts; then only accounts with no parents are permitted
> > to be assigned to users. (Also prohibiting accounts with parents from
> > having children to prevent deeply nested trees.) I suppose the same
> > could be done with the Aliases having parents / children instead of
> > the accounts, so as not to have to duplicate other account data.
>
> > On Aug 18, 6:30 pm, Joshua Russo wrote:
> > > 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:
>
> > > > class Account(models.Model):
> > > > ...
> > > > primary_alias = models.OneToOneField('Alias',
> > > > related_name='accout_if_primary')
>
> > > > class Alias(models.Model):
> > > > name = models.CharField(max_length=50, primary_key=True)
> > > > account = models.ForeignKey(Account)
>
> > > > The trouble with this approach is that basically you can't create an
> > > > account without an alias, and you can't create an alias without an
> > > > account because of what amount to circular references, so you
> > > > essentially can't add any data.
>
> > > > 2) Assign primary status to the alias:
>
> > > > class Account(models.Model):
> > > > ...
>
> > > > class Alias(models.Model):
> > > > name = models.CharField(max_length=50, primary_key=True)
> > > > account = models.ForeignKey(Account)
> > > > is_primary = models.BooleanField(default=False)
>
> > > > The trouble here is that it is a real pain to enforce that each
> > > > account has a primary alias (in fact you have to initially create an
> > > > account with no aliases and then create aliases and add them to it).
> > > > Additionally, enforcing a limit on the number of aliases is
> > > > problematic. Finally, even if you do enforce these constraints
> > > > programmatically, it doesn't seem to be feasible to relay error
> > > > messages to contrib.admin.
>
> > > > Has anyone else encountered this design problem, and how did you go
> > > > about addressing it?
>
> > > I have experienced this situation a couple of times and I would recommend
> > > the second option you discussed. Circular referenced like your first
> > option
> > > can become very problematic and are not recommended from a database
> > design
> > > perspective.
>
> > > What I would recommend is to create an Alias record automatically when a
> > new
> > > Account is created. You can do this in the save of the Account model or
> > with
> > > signals.
> >http://docs.djangoproject.com/en/dev/ref/models/instances/http://docs...
>
> > > Then in the save of the Alias you can manage the primary flag. I just
> > check
> > > to see if the current record being saved has primary set, if so then I
> > reset
> > > all others for (in your case) the account to not primary. The only other
> > > case is if the current alias isn't set as primary, check to see if there
> > are
> > > any primary aliases yet and if not automatically set the current one as
> > > primary.
>
> > > Ya, it's a little tricky but it's worth not having the headache of the
> > > circular reference.
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
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:
>
> class Account(models.Model):
> ...
> primary_alias = models.OneToOneField('Alias',
> related_name='accout_if_primary')
>
> class Alias(models.Model):
> name = models.CharField(max_length=50, primary_key=True)
> account = models.ForeignKey(Account)
>
> The trouble with this approach is that basically you can't create an
> account without an alias, and you can't create an alias without an
> account because of what amount to circular references, so you
> essentially can't add any data.
>
> 2) Assign primary status to the alias:
>
> class Account(models.Model):
> ...
>
> class Alias(models.Model):
> name = models.CharField(max_length=50, primary_key=True)
> account = models.ForeignKey(Account)
> is_primary = models.BooleanField(default=False)
>
> The trouble here is that it is a real pain to enforce that each
> account has a primary alias (in fact you have to initially create an
> account with no aliases and then create aliases and add them to it).
> Additionally, enforcing a limit on the number of aliases is
> problematic. Finally, even if you do enforce these constraints
> programmatically, it doesn't seem to be feasible to relay error
> messages to contrib.admin.
>
> Has anyone else encountered this design problem, and how did you go
> about addressing it?
>
I have experienced this situation a couple of times and I would recommend
the second option you discussed. Circular referenced like your first option
can become very problematic and are not recommended from a database design
perspective.
What I would recommend is to create an Alias record automatically when a new
Account is created. You can do this in the save of the Account model or with
signals.
http://docs.djangoproject.com/en/dev/ref/models/instances/
http://docs.djangoproject.com/en/dev/ref/signals/
Then in the save of the Alias you can manage the primary flag. I just check
to see if the current record being saved has primary set, if so then I reset
all others for (in your case) the account to not primary. The only other
case is if the current alias isn't set as primary, check to see if there are
any primary aliases yet and if not automatically set the current one as
primary.
Ya, it's a little tricky but it's worth not having the headache of the
circular reference.
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
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 Account model, and allow Accounts to
> have parent accounts; then only accounts with no parents are permitted
> to be assigned to users. (Also prohibiting accounts with parents from
> having children to prevent deeply nested trees.) I suppose the same
> could be done with the Aliases having parents / children instead of
> the accounts, so as not to have to duplicate other account data.
>
>
> On Aug 18, 6:30 pm, Joshua Russo wrote:
> > 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:
> >
> > > class Account(models.Model):
> > > ...
> > > primary_alias = models.OneToOneField('Alias',
> > > related_name='accout_if_primary')
> >
> > > class Alias(models.Model):
> > > name = models.CharField(max_length=50, primary_key=True)
> > > account = models.ForeignKey(Account)
> >
> > > The trouble with this approach is that basically you can't create an
> > > account without an alias, and you can't create an alias without an
> > > account because of what amount to circular references, so you
> > > essentially can't add any data.
> >
> > > 2) Assign primary status to the alias:
> >
> > > class Account(models.Model):
> > > ...
> >
> > > class Alias(models.Model):
> > > name = models.CharField(max_length=50, primary_key=True)
> > > account = models.ForeignKey(Account)
> > > is_primary = models.BooleanField(default=False)
> >
> > > The trouble here is that it is a real pain to enforce that each
> > > account has a primary alias (in fact you have to initially create an
> > > account with no aliases and then create aliases and add them to it).
> > > Additionally, enforcing a limit on the number of aliases is
> > > problematic. Finally, even if you do enforce these constraints
> > > programmatically, it doesn't seem to be feasible to relay error
> > > messages to contrib.admin.
> >
> > > Has anyone else encountered this design problem, and how did you go
> > > about addressing it?
> >
> > I have experienced this situation a couple of times and I would recommend
> > the second option you discussed. Circular referenced like your first
> option
> > can become very problematic and are not recommended from a database
> design
> > perspective.
> >
> > What I would recommend is to create an Alias record automatically when a
> new
> > Account is created. You can do this in the save of the Account model or
> with
> > signals.
> http://docs.djangoproject.com/en/dev/ref/models/instances/http://docs.djangoproject.com/en/dev/ref/signals/
> >
> > Then in the save of the Alias you can manage the primary flag. I just
> check
> > to see if the current record being saved has primary set, if so then I
> reset
> > all others for (in your case) the account to not primary. The only other
> > case is if the current alias isn't set as primary, check to see if there
> are
> > any primary aliases yet and if not automatically set the current one as
> > primary.
> >
> > Ya, it's a little tricky but it's worth not having the headache of the
> > circular reference.
> >
>
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
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 prohibiting accounts with parents from
having children to prevent deeply nested trees.) I suppose the same
could be done with the Aliases having parents / children instead of
the accounts, so as not to have to duplicate other account data.
On Aug 18, 6:30 pm, Joshua Russo wrote:
> 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:
>
> > class Account(models.Model):
> > ...
> > primary_alias = models.OneToOneField('Alias',
> > related_name='accout_if_primary')
>
> > class Alias(models.Model):
> > name = models.CharField(max_length=50, primary_key=True)
> > account = models.ForeignKey(Account)
>
> > The trouble with this approach is that basically you can't create an
> > account without an alias, and you can't create an alias without an
> > account because of what amount to circular references, so you
> > essentially can't add any data.
>
> > 2) Assign primary status to the alias:
>
> > class Account(models.Model):
> > ...
>
> > class Alias(models.Model):
> > name = models.CharField(max_length=50, primary_key=True)
> > account = models.ForeignKey(Account)
> > is_primary = models.BooleanField(default=False)
>
> > The trouble here is that it is a real pain to enforce that each
> > account has a primary alias (in fact you have to initially create an
> > account with no aliases and then create aliases and add them to it).
> > Additionally, enforcing a limit on the number of aliases is
> > problematic. Finally, even if you do enforce these constraints
> > programmatically, it doesn't seem to be feasible to relay error
> > messages to contrib.admin.
>
> > Has anyone else encountered this design problem, and how did you go
> > about addressing it?
>
> I have experienced this situation a couple of times and I would recommend
> the second option you discussed. Circular referenced like your first option
> can become very problematic and are not recommended from a database design
> perspective.
>
> What I would recommend is to create an Alias record automatically when a new
> Account is created. You can do this in the save of the Account model or with
> signals.http://docs.djangoproject.com/en/dev/ref/models/instances/http://docs.djangoproject.com/en/dev/ref/signals/
>
> Then in the save of the Alias you can manage the primary flag. I just check
> to see if the current record being saved has primary set, if so then I reset
> all others for (in your case) the account to not primary. The only other
> case is if the current alias isn't set as primary, check to see if there are
> any primary aliases yet and if not automatically set the current one as
> primary.
>
> Ya, it's a little tricky but it's worth not having the headache of the
> circular reference.
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
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 they are no longer keys tomorrow. When that happens, you > float your resume and find a new gig. Thanks for the links. :-) In my case, the primary_key will ever be unique. It is impossible that another entry has the same name. > Don't take my recommendation as authoritative. I'm not a DBA by > trade, I'm a code monkey. Take the time to read up on the subject. > The Wikipedia pages are a good start. :-) Yes, I'm a code monkey too and I prefer giving the db design to something else. :-) > doug. Thanks again Kai --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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 Peruse those at your leisure. I'll wait... Okay, with those articles in mind, I would recommend you always use a surrogate key as your primary key. 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 they are no longer keys tomorrow. When that happens, you float your resume and find a new gig. The only time you don't need a surrogate key is in cross reference, or many-to-many, tables. They consist of two columns, each pointing to tables being related. Django hides the 'detail' of that relationship from you, but if you check the SQL it spits out, you'll see that they are, in fact, there. Don't take my recommendation as authoritative. I'm not a DBA by trade, I'm a code monkey. Take the time to read up on the subject. The Wikipedia pages are a good start. :-) In my personal experience, I can not think of a database I've worked with in my career that used natural keys (15 years experience, so you can frame that statement). doug. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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 address as username. That column is declared unique and indexed. I use the id internally, and the email address for logins, etc. I assume an integer index is a little faster, but mainly I do it because it doesn't rely on user data that may for some unknown reason change. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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? Which one do you use (and why)? Thanks Kai PS: I meant opinion instead of option. :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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 reflects the real world. In general, a person's name isn't very > unique. So if you really have some data that has a real unique > characteristic, then use it as the primary key. If you are really setting > up a Person table, don't use the name as a primary key. You probably will > be altering the table sooner rather than later to remove the unique > designation. The last department I worked in had 3 Mike's in about a dozen > people. That is why governments invent things like SSN, to make you unique. > So in that case, an implicit id is going to work better, but know you have > to figure out how to keep the 3 John Smiths apart. Thanks for your option. The person was a bad example, I don't have Person objects. Thanks again Kai --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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 unique. So if you really have some data that has a real unique characteristic, then use it as the primary key. If you are really setting up a Person table, don't use the name as a primary key. You probably will be altering the table sooner rather than later to remove the unique designation. The last department I worked in had 3 Mike's in about a dozen people. That is why governments invent things like SSN, to make you unique. So in that case, an implicit id is going to work better, but know you have to figure out how to keep the 3 John Smiths apart. On 4/25/07, Kai Kuehne <[EMAIL PROTECTED]> wrote: > > > 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 "unique=True" set: > > class Person(models.Model): > name = models.CharField(maxlength=255, unique=True) > > > 2) or the name directly as the primary key of the table without an id: > > class Person(models.Model): > name = models.CharField(maxlength, primary_key) > > I'm a bit confused on how do it 'right(tm)'. Is there a > rule or how would you do it? > > Thanks for ideas > Kai > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Database design question
Mike Caldwell wrote: > That is why governments invent things like SSN, to make you unique. btw, don't use SSN as unique id 8) Besides security and privacy issues, it's also not guaranteed to be unique. At a previous job dealing w/ cell phone accounts, it was possible for the same person to have multiple accounts (for instance, a personal and business number). I know, doesn't answer your question, but... heh --B --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
