General request for comments & corrections from the more experienced (than me) programmers in this group please. I really don't want to be giving bad advice. Anyway, on to the advice...
Rupesh, In the end, it doesn't matter what scheme you use, as long as you find it easy & your practices are consistent. If you are working on shared code (i.e. working with somebody else), then you should both agree on a set of coding practices. If you are working on multiple applications within the same database, then it makes sense to prefix application-specific tables with something which easily describes it (in case you have to examine the back-end database, or have to make cross-application queries). That being said, I suggest that at the very least, you take a look at Python PEP <http://www.python.org/dev/peps/pep-0008/> guidelines, in order to standardise your coding practice. As far as database naming goes, if you are building applications from scratch, try to ensure that you have memorable names (or ones which are logical & easy to recreate). If there is the possibility of more than one app being stored in your database backend, and the possibility exists for table name collisions (tables called 'name' or 'address' are very common). It is, in my opinion, good practice to prefix your application-specific tables with something to separate them from the other applications tables. Let's call your app *Contacts List.* We now have a nice, 2-prefix addition to our table names: CL # Storing our address types in a list as opposed to # devoting a full table to them: address_types=['permanent', 'temporary', 'postal', 'additional'] db.define_table('cl_contact', Field('name'), ) db.define_table('cl_address', Field('contact', db.cl_contact), Field('address_type', 'string', requires=IS_IN_LIST(address_types)) Field(' ) For small values of the list (i.e. less than a dozen items, which are unlikely to change), you may as well store them in a list (as above) and let web2py deal with the lookup. If you need a lookup table, then prefix it with whatever is easy enough to remember. The important part (*and trust me on this* :) is consistency. At the end of the day, as long as your methodology is consistent, logical and easy to follow, then just go with whatever's easiest for you. Martin. On 31 January 2011 21:58, Rupesh Pradhan <rupeshkrprad...@gmail.com> wrote: > I am trying to standardize my naming schemes for my database, table and > fields. I am trying to follow the one given below. Please share with me your > scheme. > > Standard Database Table Naming Scheme > ===================================== > Table name: > ----------- > small caps with underscore > look-up table prefixed with 'lu_' > link table prefixed with 'lk_' (should i do this?) > > > eg. > contact > lu_address_type > > > Field names: > ------------ > small caps with under score > primary key suffixed with '_id' > > eg. > name > address_text > contact_id > > Table Field access notation: > --------------------------- > table name DOT field name > > eg. > contact.name > contact.contact_id > lu_address_type.name > lu_address_type.address_type > >
