You lose the fact that that database it does not know it is a reference. In practice you do not lose anything. Your code may be slower if you do not create an index manually but it is easy to do that anytime if there is a need.
Massimo On Oct 21, 8:50 am, billf <[EMAIL PROTECTED]> wrote: > So what exactly do I lose by defining the reference id as an integer > as opposed to a table? > > On Oct 21, 2:35 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > There are many ways around this. The easiest is define department > > before person and make created_by and modified_by integers instead of > > references. > > > On Oct 21, 4:18 am, billf <[EMAIL PROTECTED]> wrote: > > > > I want to define tables as follows: > > > 1) extend t2_person with additional fields some of which are > > > references to other tables (many people work in "department" x?) > > > 2) all tables to have created_by and modified_by fields (which > > > themselves refer to t2_person) > > > > The problem is that to satisfy 1) I must define "department" before > > > t2_person. To satisfy 2) I must define t2_person before > > > "department". If I import T2 before "department" to get a reference > > > to t2_person, the re-definition of t2_person throws "table already > > > defined". > > > > Is the only solution to define my own "person" table that contains the > > > reference to "department" and a reference to t2_person? ...and then > > > import T2 (and t2_person), define "define" then define my "person". > > > > If the answer is yes then is that seen as "better design" or a "work- > > > around"? > > > > A second problem relates to the desire to navigate efficiently through > > > a database in more than one direction. In the above example, let > > > "person" be a bank account holder and the "other table" be a bank > > > account. Keeping it simple, assume it is a one-to-many relationship, > > > one-or-more accounts each owned by 1 account holder. If the only > > > reference is from person/account holder to account then a search to > > > see who owns account 12345678 is costly. If the only reference is > > > from account to person/account holder then the search for "accounts > > > for this account holder" is costly. > > > > However, in web2py, I cannot define an account with a reference to > > > person/account holder and a person/account holder with a reference to > > > account as one of the other definition fails with an undefined term. > > > > I believe I have to define a third table: person, account and > > > account_holder to overcome this. Is that correct? > > > > It seems the bottom-line is that the database design is constrained by > > > the fact that the table definitions are validated by python in a > > > single pass. If that is true it seems unfortunate. > > > > I would be very happy if someone can show me the error of my ways: > > > either the way to define the above tables or explain why I shouldn't > > > want to. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
