I'm not sure if this is the 'best' approach, but you can definitely accomplish this without creating your own tables, unless you have some other specific need. In your plugin defineSettings method you could either define individual fields (if the entry fields are predetermined) or a table field (if both the post data and entry fields should be configurable) to store field mappings. In your public controller method you can then map the post data to your entry's fields via the settings that you defined, perform other security/data checks, etc. and save the entry.

In the plugin's controller:

public function actionSaveJob()
{    
    // get 'post to field' mappings from plugin settings
    $pluginSettings = craft()->plugins->getPlugin('JobPostPlugin')->getSettings();
    $titlePostVar   = $pluginSettings->titlePostVar;
    $bodyPostVar    = $pluginSettings->bodyPostVar;
    $summaryPostVar = $pluginSettings->summaryPostVar;

    // retrieve post data
    $title   = craft()->request->getPost($titlePostVar);
    $body     = craft()->request->getPost($bodyPostVar);
    $summary = craft()->request->getPost($summaryPostVar);

    // create a new entry
    $entry = new EntryModel(); 
    $entry->sectionId  = 2; 
    $entry->typeId     = 2; 
    $entry->authorId   = 1; 
    $entry->enabled    = true;

    // set entry content
    $entry->getContent()->setAttributes(array(     
        'title'     => $title,     
        'body'      => $body,
        'summary'   => $summary, 
    ));
    $success = craft()->entries->saveEntry($entry);
}

Completely untested, but should be more or less correct. If anyone sees an error please comment or feel free to edit.

You would also want to add conditions to ensure that the post data exists and that it is formatted correctly, and that whatever security conditions you've established are met, and perhaps record/return success and or errors.

For simplicity I have shown this all happening in a controller action, however, I think the recommended approach would be to separate this between a controller and a corresponding service, so that the controller is never actually modifying the DB.

I'm not sure if this is the 'best' approach, but you can definitely accomplish this without creating your own tables, unless you have some other specific need. In your plugin defineSettings method you could either define individual fields (if the entry fields are predetermined) or a table field (if both the post data and entry fields should be configurable) to store field mappings. In your public controller method you can then map the post data to your entry's fields via the settings that you defined, perform other security/data checks, etc. and save the entry.

In the plugin's controller:

public function actionSaveJob()
{    
    // get 'post to field' mappings from plugin settings
    $pluginSettings = craft()->plugins->getPlugin('JobPostPlugin')->getSettings();
    $titlePostVar   = $pluginSettings->titlePostVar;
    $bodyPostVar    = $pluginSettings->bodyPostVar;
    $summaryPostVar = $pluginSettings->summaryPostVar;

    // retrieve post data
    $title   = craft()->request->getPost($titlePostVar);
    $body     = craft()->request->getPost($bodyPostVar);
    $summary = craft()->request->getPost($summaryPostVar);

    // create a new entry
    $entry = new EntryModel(); 
    $entry->sectionId  = 2; 
    $entry->typeId     = 2; 
    $entry->authorId   = 1; 
    $entry->enabled    = true;

    // set entry content
    $entry->getContent()->setAttributes(array(     
        'title'     => $title,     
        'body'      => $body,
        'summary'   => $summary, 
    ));
    
    // save the entry
    $success = craft()->entries->saveEntry($entry);
}

Completely untested, but should be more or less correct. If anyone sees an error please comment or feel free to edit.

You would also want to add conditions to ensure that the post data exists and that it is formatted correctly, and that whatever security conditions you've established are met, and perhaps record/return success and or errors.

For simplicity I have shown this all happening in a controller action, however, I think the recommended approach would be to separate this between a controller and a corresponding service, so that the controller is never actually modifying the DB.