I still do not agree.
If you run into this issue you can always offset the created_by fields...
db.define_table('audit_table',
Field('tablename'), Field('record_id', 'integer'),
Field('created_by', db.auth_user),
)
If you ever did need to audit, just look it up in this table. Then you don't
have the problem at all.
--
Thadeus
On Thu, Nov 11, 2010 at 12:17 PM, mdipierro <[email protected]> wrote:
> I agree with you that using a link table is better. This was my
> original argument.
>
> Yet often the need to sign tables (created_by) will suddenly cause a
> duplication of tables because lots of link tables have to be added and
> queries changed. This is what I meant by good case.
>
> Massimo
>
> On Nov 11, 12:05 pm, Thadeus Burgess <[email protected]> wrote:
> > WRong. cr2 is a really really bad design.
> >
> > Database 101, any many to many relationship must be defined through a
> link
> > table.
> >
> > Redesign CR2 like so...
> >
> > db.define_table('person',.... created_by('person'))
> > db.define_table('company',...created_by('company'))
> >
> > db.define_table('person_company', id_person('person'),
> > id_company('company'))
> >
> > If you want to knwo what company ap person belongs to, look it up in the
> > link table
> >
> > person = db.person.first()
> > link = db.person_company.id_person == person.id
> > company = db.company.id == link.id_company
> >
> > This is the "proper" way to design this type of relationship.
> >
> > I would opt more for a feature in web2py that did this in the background
> > than handled circular dependency magick.
> >
> > --
> > Thadeus
> >
> > On Thu, Nov 11, 2010 at 11:32 AM, mdipierro <[email protected]>
> wrote:
> > > Ok. Your crm2jpg makes a good case. You proved me wrong.
> > > I will try add this by the week-end.
> >
> > > Massimo
> >
> > > On Nov 11, 11:24 am, Mirek Zvolský <[email protected]> wrote:
> > > > -> mdipierro
> > > > I have prepared 2 pictures, and in this time there is new post from
> > > > you about company/author. Interesting that my pictures are about the
> > > > same :-)
> >
> > > > Model of your CRM application application is here:
> > >http://zvolsky.alwaysdata.net/crm1.jpg
> > > > Such model can be implemented in web2py, but order of definitions is
> > > > important: auth_user, company, person
> >
> > > > But let's think, you want all people from person's table can
> register/
> > > > login into your application. In such case you will follow web2py
> book,
> > > > chapter 8,http://web2py.com/book/default/chapter/08, Customizing
> Auth &
> > > Renaming
> > > > Auth Tables,
> > > > and you will receive following model:
> > >http://zvolsky.alwaysdata.net/crm2.jpg
> >
> > > > And using "reference..." field types, in both definition orders
> > > > (company,person or person,company) web2py will fail.
> >
> > > > As you say, I can use 'integer' type to avoid this problem, where it
> > > > is. But mixing 'reference..' and 'integer' for same goal would be
> > > > strange. So I can use 'integer' for all foreign keys in database. But
> > > > that means in other words, that the 'reference..' field type is for
> > > > nothing.
> >
> > > > What about a more difficult model ashttp://
> > > zvolsky.alwaysdata.net/crm3.jpg
> > > > I'm sorry, this is not in english. However it is something about
> > > > organization of courses, lessons, we have some teachers and
> > > > partitipant here, some payments for whole course of for one lesson
> > > > only, and so on.
> >
> > > > Generated web2py code from OndrejZara's web designer is here:
> > >http://zvolsky.alwaysdata.net/jekus.py
> >
> > > > And of course this code will fail in web2py, because of there is no
> > > > possibility to find a proper order of table definitions.
> > > > Please, think about this. The change in web2py in this direction
> would
> > > > be great.
> >
> > > > Best regards, Mirek
> >
> >
>