Large Database with lots of tables

Hello all,

I am a rails nuby and I am evaluating using Rails for a new web
application. The application will have a large number of tables (>70)
that will basically mimic a large collection of paper forms that user
would otherwise have to fill out. From what I have read on rails thus
far it seems I would have to create a lot of models and form templates.
Is this common and if so does anyone have any suggestions of efficient
ways to do this?

There is one catch, the forms need to be able to display their labels in
more that one language.

Thanks

peer

On Tue, Mar 28, 2006 at 04:24:49AM +0200, Peer A. wrote:
} I am a rails nuby and I am evaluating using Rails for a new web
} application. The application will have a large number of tables (>70)
} that will basically mimic a large collection of paper forms that user
} would otherwise have to fill out. From what I have read on rails thus
} far it seems I would have to create a lot of models and form
templates.
} Is this common and if so does anyone have any suggestions of efficient
} ways to do this?

It sounds like each table will correspond to a single form. This is
pretty
much ideal for scaffolding. You should be able to generate basic models,
controllers, and views for the forms with script/generate scaffold. You
may
want to tweak the views and validation and such, but that is to be
expected. It sounds like scaffolding will be a very useful start for
you,
however.

} There is one catch, the forms need to be able to display their labels
in
} more that one language.

When the scaffolding is generated, assuming config/database.yml has the
proper configuration and the database exists, a _form.rhtml file will be
generated (for each model) which uses label tags. I recommend creating a
label helper method that will give the desired label based on the
appropriate language and the label identifier. Then run the following on
each _form.rhtml to replace the label tags as they exist with
invocations
of the label helper method:

sed -i ‘s,<label for="([^"])">[^<],<%= label :\1 %>,g’
_form.rhtml

} Thanks
} peer
–Greg

I’m trying to create a table AND create a row in my migration. I’m
having trouble with the creating a row part (the line Planet.create
below):

file: db/migrate/001_first_table.rb

class FirstTable < ActiveRecord::Migration
def self.up
create_table :planets do |t|
t.column :name, :string
end

 Planet.create(:name => "Earth")

end

def self.down
drop_table :planets
end
end

rake migrate => rake aborted!, uninitialized constant Planet

I’m getting this error on Rails 1.0 and edge 4068

oh, I think you’ll need to create a model as well.

planet = Planet.new(:name => “Earth”)
planet.save

oh, I think you’ll need to create a model as well.

Oh that helped, thanks … can you tell I haven’t done this much yet :wink:
I think maybe the scaffold I used before made the model … and checking
this page:

http://wiki.rubyonrails.org/rails/pages/UsingMigrations

didn’t remind me to make the model.

Peer A. wrote:

There is one catch, the forms need to be able to display their labels in
more that one language.
I know others have suggested the model-per-form route, and that’s
probably the simplest route, but you may want to take a look at the
processes that the forms fit into, to see if there are simpler domain
models that you could take advantage. For instance, if forms A, B and C
contain different information, but always need to be filled out
sequentially (for instance, by different people) as part of the same
process, then you could use a single model to represent that process.
You’d still need the separate templates, of course, but you’d gain a
much simpler workflow system.

Just another idea for the melting pot…

This kind of approach is one I was curious about. It seemed excessive
to me that I would have to create 70+ controllers, one for each form,
when most of the forms function in a similar way. I can understand
having to make that many models due to validation issues.

if theyre all forms, you proabbly want to be thinking more along the
lines of a FormTemplate and FormFields class, and making a GUI editor so
that you can design the forms from the interface, rather than writing
model code for each. you could even scratch the FormTemplate class and
just have the templates be tagged instances of a normal Form…and clone
their state.

if you have a lot of complex interrelationships between the forms, and
want to start thining about refactoring your business without having to
also think about refactoring your app, i’d suggest checking out
DabbleDB. theres no reason good chunks of Rails like ActiveRecord,
Migrations, RJS, and addons like Markaby and the AJAX scaffold generator
couldnt be plundered to create something like this, but the current
assumption is that the model is static and defined at server launch
time…

Alex Y. wrote:

Just another idea for the melting pot…

Every idea is welcome!

This kind of approach is one I was curious about. It seemed excessive
to me that I would have to create 70+ controllers, one for each form,
when most of the forms function in a similar way. I can understand
having to make that many models due to validation issues.

Does anyone find it hard to maintain an app with so many files?

Peer