code logic not made for community sites

The module works well, with one big exception:

It's user access logic is based on "permission to creating new tables", when it should be "permission to VIEW and ADD/EDIT their OWN content into an EXISTING table."

Here's why...

What if you have a large community site 1000+ users, where users can create their own, for example, "Resume" table... OK... great, this can be done... (of course it'll be a bit confusing for most typical users asking the users about how many columns they want, and what they want to name each, etc.)
Anyhow...
Let's say that the users are smarter than your regular joe, and have no problems creating their own charts... fine... that's great and all.......

BUT... here's the biggie: each time a table is made, a new "permission" listing is made under "access control"

so what now? well... if you have 1000 users, and each creates 1 form... you then have a huge mess of 1000 permission listings added to "access control"....

Not good...

Nevertheless... what this module SHOULD have focussed around, is this:

1. allow only administrator to create specific forms (e.g. Resume: (3 columns) Title, Position, Year )
2. give users access to ADD their OWN content into theses forms
3. give users access to EDIT only their OWN content
4. List ONLY the content created by 1 specific USER (e.g. If viewing Joe Shmoe's Resume, ONLY list what he ADDED into the resume form--and NOT all other users (which is the way it's designed to do now)

I know you can make the argument that this wasn't made for large communities, but still, the current logic behind it insists on the use of "user created forms" and giving permission options to ALLOW OTHER users to ADD or EDIT someone else's forms (which doesn't make much usability sense)

Instead of having the permission settings to allow other users to edit ALL data on a single form... it SHOULD have been focussed on: ONLY display data from a single user, and allow that user to ONLY edit his own content.