I am fairly sure what you are doing will not result in efficient use of your database. It certainly isn't good programming practice.
The whole point of object orientated programming is that you reuse the same coding over and over. Creating a new set of models for each user would very much go against this philosophy. How are you going to manage all these models - for example if you need to modify the way one of the tables works!
What you should do is have all users using the same 4-5 tables and then uniquely identify the table entries for each user via a user_id field.
In raw SQL you'd then add a WHERE condition to your SELECT statements. So if the user has id 3 you'd add "WHERE user_id = 3". The database will then return just the entries for that user.
SQL is designed to retrieve data this way and is very efficient at it.
ActiveRecord in Rails make this even easier for you by automatically generating the correct WHERE statement for you when you define your has_many, has_one and belongs_to relationships.
The problem isn't Rails. The problem is you are trying to do something that can be done much more easily another way.
Originally Posted by yourstruly_ram
I understand that.. so this is actually a handicap specific to Rails?
No. You can make your models work any way you want. The limit is how well you can program in Ruby. It just the automatic stuff that won't work as well, and the problems you'll get because you'll lose a lot of the simplicity of Rails.
If you want to overwrite the user model find method, or create customer methods to grab the data you want - Rails has all the tools you need to do that. There is nothing to stop you using custom SQL calls within a model.
If you want to have a separate set of tables to for each user, the tools are available within Rails to do it. However, it's a silly thing to do and Rails won't do it automatically for you. You'll need to customize your models to suit the crazy plan.
It's not a handicap of Rails. It just compliance with good programming practice.