Forum: Ruby on Rails Large Database with lots of tables

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
71b39cce77a48a3f99b4e6a14a656007?d=identicon&s=25 Peer Allan (Guest)
on 2006-03-28 04:24
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
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-03-28 04:58
(Received via mailing list)
On Tue, Mar 28, 2006 at 04:24:49AM +0200, Peer Allan 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>,<%= label :\1 %>,g'
_form.rhtml

} Thanks
} peer
--Greg
5810a1b7743eb2186ca0ea1d0a3469a0?d=identicon&s=25 Stephen Bannasch (Guest)
on 2006-03-28 06:21
(Received via mailing list)
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
F719c6cb34bd5b691c12b373b7244b4d?d=identicon&s=25 Dorian Mcfarland (tachekent)
on 2006-03-28 06:25
(Received via mailing list)
planet = Planet.new(:name => "Earth")
planet.save
F719c6cb34bd5b691c12b373b7244b4d?d=identicon&s=25 Dorian Mcfarland (tachekent)
on 2006-03-28 06:30
(Received via mailing list)
oh, I think you'll need to create a model as well.
5810a1b7743eb2186ca0ea1d0a3469a0?d=identicon&s=25 Stephen Bannasch (Guest)
on 2006-03-28 06:44
(Received via mailing list)
>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 ;-)
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.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-03-28 09:03
(Received via mailing list)
Peer Allan 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...
71b39cce77a48a3f99b4e6a14a656007?d=identicon&s=25 Peer Allan (Guest)
on 2006-03-28 14:23
Alex Young 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
E54a059675e8e64474988e2faffdcb3b?d=identicon&s=25 ix (Guest)
on 2006-03-28 14:40
> 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..
This topic is locked and can not be replied to.