I am developing a web application and Among the finest to understand how to consider Drupal's db originating from an MVC background. I've tables to represent individuals data for example SSN, Name, Surname, Zipcode, Address, Language, Location. Now around the front-end I wish to produce a form to populate these details for a lot of subjects (people). I've my database stabilized therefore the Zipcode features its own table (having a foreign key connect to the individual table). The "person" table has stuff for example Name, Surname, Address etc... and also the "language" table may have the various language abbreviations (again having a foreign key to the individual table).

I must understand how to move something similar to this to drupal's schema. I understand I possibly could create my very own tables and link it well towards the "node" table after which I suppose build my forms to simply accept user input...but is the recommended method of doing it? I had been searching at webform, however it appears this ought to be employed for simpler forms in which the database is not stabilized and things are just saved in a single large table. I am unsure, however i would certainly like to hear what everyone think...and when you can point me with a assets that'd do well.

Drupal is flexible enough that you could create whatever tables you would like after which write code to link it well towards the node table. However doing this means that you finish up with many different code that is very specific for your schema, and it is not so interoperable along with other Drupal modules.

You will notice that you receive on better with Drupal should you mostly do things the Drupal way. And just get a very personalized solution where you stand doing a thing that is not included in standard Drupal modules.

For instance you might find the profile module meets your needs so far as standard details about people goes. The location module (particularly user location) covers customers addresses. By utilizing these modules you may find other modules which use them later on and overall you'll find you've less code to create.

One factor you might find helpful may be the migrate module to get your overall data into Drupal.

It may sound like you are just storing information and also the subjects (people) will not be customers from the Drupal site.

Using the node and CCK modules to achieve this would remove the majority of the development work. For instance, all of your tables (e.g. Person, Zipcode, Language) might be symbolized with a content type with numerous fields. The foreign secrets could be symbolized by node reference fields. Therefore the Person content type might have a number of node references to nodes of type, Language.

The migrate module appears well used (626th most popular of 4000+ modules utilized in a minimum of 10 distinct Drupal sites), however it may be simpler cooking your own migration script, but I am unfamiliar with either your circumstances, your knowledge of Drupal's API, or even the migrate module.

Node reference fields display as links towards the recommended nodes automatically, but could be designed to load and display the recommended node rather (e.g. exhibiting Language information inside a Person node). There is a handy screencast that demonstrates how to pull off theming node reference fields to load and selectively display the recommended nodes' contents.

Originating from an MVC background you might not like how Drupal stores data within the DB.

Profile module was pointed out, however i find I recieve more versatility with Content Profile and CCK combined.

I have written some migration scripts before from Coldfusion to Drupal, and it is much less involved.