That certainly is unusual. If you don't want to (or cannot) convert
the ten user tables into a single users table, I would consider
creating a pure ruby class that was composed with a user model. The
pure ruby class would be a proxy and you'd delegate most of the method
calls to the instance that you find by querying the ten 'sub-user'
tables.
It's possible that you could use this as a plan for migrating the data
into one table, too. You could query from any table, but always save
the data back to one. Eventually you'll get all the active users over
to one table. That's probably more work than it's worth but it's an
option.
My User data is split to 10 Table. named user_0, user_1,user_2
if user.id % 10 = 1 will store to user_1 for (database scable reason)
What scaling issue is addressed by this remarkable approach?
Allowing the database to ignore its own built-in block paging algorithms?
I suspect the original coder invented that beauty. In PhP, natch...
xxdd should read the /Rails Recipes/ chapter on legacy databases, then
connect directly to that database. And she or he should then write and
deploy new features in Rails while leaving the old system online. Don't
write Rails (or any app) for a long time without delivering anything. The
best way to get your foot in the door is add one new feature with Rails,
then give it to customers who can leave the old system online with the new
one.