I have a php script that will parse html page content link and view but I need to know how to store this content in the sqlite3 database any suggestion?
include_once('simple_html_dom.php'); //PHP Simple HTML DOM Parser library
$html = file_get_html('www.website.com');
// Find all article blocks
foreach($html->find('div.postbody') as $article) {
$item['details'] = $article->find('div.content', 0)->innertext;
$articles[] = $item;
}
print_r($articles);
try {
$db = new SQLite3('db/mysqlitedb.db');
$db->exec// what type of table should i create
$db->exec// how tell db to store html content from $articles
$result = $db->query('SELECT bar FROM gg');
var_dump($result->fetchArray());
/* Close connections to Database */
$db = NULL;
}
catch( PDOException $e )
{
/* Print Error-Messages */
echo $e->getMessage();
}
Typically you will create just one table to store all fragments in, not a table per fragment. Thus, the bare minimum of fields you will need in that table are something to identify the fragment, and the fragment itself. Based on your requirements you may want to add extra fields like the datetime the fragment was inserted, the inserter’s userid, etc.
The fragment will be stored as
TEXT(a large object datatype that can contain text information) and for simplicity’s sake I’ll use anINTEGERfield as identifier. Depending on how you will want to retrieve the fragments you can also use a short string, eg aVARCHARNext, in that collection of codelines you included in your question you are using the native SQLite driver wrapped in a PDO exception. It is highly doubtful that that is going to work properly. I suggest you stick to PDO and to prepared statements. Don’t even consider using cobbled-together literal INSERT statements, especially not in this case where you are inserting html fragments. or in any other case for that matter, preparedstatements are the only water- and bulletproof defense against sql injection attacks and related mischief.
That’s the basic setup. Can’t think of a unique numeric key for these fragments? No problem, change identifier’s type to
VARCHARin the table definition.