CRUD module for Drupal for managing DB table records

IMHO, this is a critical element that Drupal lacks.

Imagine the impact this could make on this product...one set of code that could be reused over and over, providing a CRUD-like sub-infrastructure for managing arbitrary database tables.

The main things, as I see it, that would be needed are:

• Operations: create, read (view lists of records (with edit/delete links), and view details on individual records), update, delete
• Ability to sort record lists (ascending and descending) by clicking on field headers
• Ability to grant and restrict access to individual CRUD operations for each table based on group membership
• Link for CRUD management in backend
• Create a new section in Drupal's backend interface which would be a gateway to each table's CRUD (i.e. click a link, and you are taken to the list of records for the corresponding table)
• Ability to plug a CRUD interface into the frontend
• Functionality to create new CRUD interface
• Specify table to use (via displaying a drop down list of tables found in the database which don't already have CRUD interfaces)
• Display multi-select list of fields in selected database table. Have another multi-select list to the right, and allow users to select fields which they want to be displayed in the record list. I see this part as a wizard-like series of linked pages.
• A way to specify "friendly names" for selected fields (e.g. "Model Number" rather than "model_no")

Some considerations:

• What already exists that could (appropriately) be used? Maybe the CCK stuff?
• Should create and edit forms be auto-generated?
• Display appropriate HTML input fields based on database field types (e.g. date uses 3 drop downs for mm/dd/yyyy; datetime uses 3 drop downs + 3 more for hh/mm/ss; numeric and varchar fields uses text input fields; longtext/text uses a textarea)
• It might be a good idea to allow users to override what types of input fields get displayed for individual database fields
• maxlength should be imposed for varchar (i.e. text input) fields based on their lengths
• What about foreign-keyed fields which use codes and have their actual values in other tables? It would be nice (probably even necessary) to display selection lists for these fields which pull values from the lookup database table. I see two possible solutions for this:
• Determine which fields are foreign keys, and for those that are, determine which table they link to. This, however, requires foreign keys to be defined, and it could also be a PITA to support multiple DBMSes.
• Require the users to, via the backend interface, define foreign key relationships.
• Should create and edit forms use the exact same code?
• Certain fields should be required on create and edit forms, like primary keys and perhaps fields flagged as NOT NULL.

Is this possible and realistic? Why has this not already been done? Is there value in this?

I might be willing to work on this, if enough people want something like this. I would need some help from a few other people though.