[casper87]

Hej!

jag vill hämta information från mitt formulär och placera det i databasen.
tanken är att databasen ska ha raderna form_id , column_name och column_data.

jag vill hämta alla kolumnnamn jag har i mitt formulär, i detta fallet mina $_POST parametrar. men hur hämtar jag alla val i en array och placerar dom efter varandra i databasen? tänkte göra samma sak med innehållet för varje kolumn.

så databasen ser ut såhär typ:

forms_id	column_name	column_data
    1            förnamn                casper	
    1            efternamn             Karlsson

osv.
Just nu så sätts column_name och column_data till "array" i klartext i db.

detta är vad jag har så långt:

PHP-kod:

<?php
//echo mysql_error(); - felsök

$submit = strip_tags($_POST['submit']);
$firstname = strip_tags($_POST['firstname']);
$lastname = strip_tags($_POST['lastname']);
$phone = strip_tags($_POST['phone']);
$email = strip_tags($_POST['email']);

$formsId =1;


$colname = array(
"förnamn"=>$firstname,
"efternamn"=>$lastname,
"telefon"=>$phone,
"email"=>$email,
);




$coldata = array(
$firstname,
$lastname,
$phone,
$email
);



$con = mysql_connect("*****","*****","*****");
if (!$con)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("*****", $con);


mysql_query("INSERT INTO tb_formsdata (forms_id, column_name, column_data) VALUES ('$formsId','$colname','$coldata')" );


mysql_close($con);

echo "bra jobb, kolla db nu!";

[emilv]

Kör en for-loop och kör en fråga per fält. Eller ännu hellre, bygg upp en SQL-fråga med flera block i VALUES-klausulen:

... VALUES (1, 'förnamn', 'Emil'), (1, 'efternamn', 'Vikström'), ...

Men innan du gör detta, förklara varför du vill spara formuläret på detta ostrukturerade vis. Det är nämligen antagligen en dålig idé från början.

Förresten har du glömt att säkra ditt indata mot SQL-injektioner. Använd mysql_real_escape_string för detta eller byt till prepared statements/PDO.

[casper87]

Ursprungligen postat av emilv

Kör en for-loop och kör en fråga per fält. Eller ännu hellre, bygg upp en SQL-fråga med flera block i VALUES-klausulen:

... VALUES (1, 'förnamn', 'Emil'), (1, 'efternamn', 'Vikström'), ...

Men innan du gör detta, förklara varför du vill spara formuläret på detta ostrukturerade vis. Det är nämligen antagligen en dålig idé från början.

Förresten har du glömt att säkra ditt indata mot SQL-injektioner. Använd mysql_real_escape_string för detta eller byt till prepared statements/PDO.

min tanke är att slippa lägga till alla $_post variablar i mysql insert frågan. att bara kunna hämta 1 varaibel som ger mig alla värdena. på så vis blir det ju enklare att göra ett nytt formulär med andra inputs. dvs jag slipper sitta och lägga till varje ny input data till min mysql insert fråga. Jag kan återanvända koden och bara ändra i mitt formulär

om det låter förståeligt?

[emilv]

Jag tror att du ska tänka ett steg längre än "det blir lätt att skapa nya formulär". Vad vill du använda ditt data till? Vill du enbart peta in informationen i en databas eller vill du faktiskt också kunna söka, filtrera, sortera och plocka ut information från databasen senare?

Normalt strukturerar man datat i databasen efter dess syfte, inte efter hur man kan skriva så lite kod som möjligt (och faktum är, som jag ska visa strax, att det inte ens blir mer kod när man strukturerar datat). Har du ett medlemsregister så skapar du en tabell för detta register. varje medlem är ett objekt som får en egen rad i tabellen. Objektets egenskaper (namn, adress, ...) sparas i varsitt för uppgiften optimalt fält. Det är till exempel onödigt dyrt både för lagring och hantering att spara registreringsdatumet som en VARCHAR (11 byte) när man lika gärna kan välja typen DATE (3 byte).

Den stor fördelen med att spara datat på detta sätt, uppdelat i olika tabeller och med flera egenskaper på varje rad, är att du kan bygga relationer mellan objekten. Du kan använda JOIN, UNION, GROUP BY och andra verktyg som är särskilt anpassade för detta sätt att spara data. Datat är strukturerat på ett sätt som du kan dra nytta av i dina SQL-frågor. Strukturen kan även användas för att indexera de kolumner man oftast filterar efter (i allmänhet de som ofta dyker upp i ens WHERE-klausuler) och på så vis snabba upp sökningar rejält. Man kan förvisso skapa index även med din modell men då är det alltid ett VARCHAR-index och det blir bara ett enda stort index istället för att partitionera upp det på flera mindre.

En stor nackdel med att spara datat som du gör är att det kräver mycket lagringsutrymme, samt minne och beräkningskraft för att besvara dina SQL-frågor. Varje enskild rad i din tabell behöver spara namnet på fältet. Till exempel fältet "förnamn" kräver då åtminstone 9 byte (två för ö samt en för att säga hur stort VARCHAR-fältet är) för varje objekt bara för att avgöra vilken sorts egenskap det är, istället för att man sparar detta på ett ställe i tabelldefinitionen. För att söka igenom ditt data måste man vada igenom en större datamängd, data som helst ska ligga i arbetsminnet för optimalt arbete men då du är så slösaktig med resurserna ofta kommer plockas bort ur RAM och sparas på disk istället.

Men nu till det riktigt dumma i din modell, som jag introducerade i början av det här inlägget. Du säger att du vill kunna skapa fler formulär, men du tänker ingenting på hur datat från formulären ska användas. Säg att det är ett community du bygger (som exempel). Ska då medlemsregistreringar, forumtrådar och PM ligga i samma tabell? Hur vet man vad som är vad? Du blandar objekten hej vilt i samma tabell. Att hålla koll på detta kräver en egen tabell, eller ännu värre: ytterligare en rad för varje objekt som säger vad objektet representerar. Med en egen tabell har du tappat hela poängen då du fortfarande inte kan bygga ut systemet sömlöst, och då kan du lika gärna använda en traditionell databasstruktur med en tabell per "register" och en rad per objekt. Ska du lägga till ytterligare en rad för varje objekt blir det bara ännu tyngre att hämta ut objektet. Plötsligt pratar vi om en fråga för att hitta, säg, alla PM, och en fråga till för att se vilka av dessa som hör till en viss mottagare. Du skyfflar data flera gånger och kommer dessutom få mer programkod att skriva.

Och det är nu vi kommer till det jag hintade om i början: din modell ger inte mindre programkod. Det du försöker göra är, lite generaliserat, att abstrahera bort databasen och göra den till en stor lagringsyta. Vissa abstraktioner är bra (till exempel abstraherar PHP bort C:s minneshantering och udnerlättar för dig som programmerare, samt ger mindre kod), men den abstraktion du syslar med tillhör inte de kategorier som ger mindre kod. Istället blir det mycket mer kod när du ska hämta ut datat vid ett senare tillfälle. Och jag ska nu visa att den traditionella metoden, med "var sak har sin plats"/"en tabell per register", kan skrivas med väldigt lite kod och ändå vara både återanvändbar och icke-upprepbar:

PHP-kod:

<?php
$fields = array('firstname', 'lastname', 'phone', 'email');
$table = 'tb_users';

$query = 'INSERT INTO %s (%s) VALUES (%s)';
$insert_fields = array();
$insert_data = array();
foreach($fields as $name) {
  $insert_fields[] = $name;
  $insert_data[] = "'".mysql_real_escape_string($_POST[$name])."'";
}
$query = sprintf($query,
                 $table,
                 implode(',', $insert_fields),
                 implode(',', $insert_data));

mysql_query($query) or die(mysql_error()."<br>\nQuery: ".$query);
?>

Som du ser är koden mer generell än din, men sparar ändå datat på ett sådant strukturerat vis som relationsdatabaser är menade för. Jag får en vinst i att id-fältet kan vara AUTO_INCREMENT så ser databasmotorn till att värdena blir unika (så att inte två samtidiga körningar råkar få samma id-nummer), och eftersom det bara är en rad som ska skrivas blir arbetet för databasen mindre. Vid användning av datat kan man lätt ställa frågor mot de tabeller man vill arbeta mot och loopa igenom resultatet på sedvanligt vis.

Jag har förresten bytt ut strip_tags (en närmast meningslös funktion för nästan alla tillämpningar, och farlig om man tror att den bidrar till ökad säkerhet) mot mysql_real_escape_string som skyddar mot SQL-injektioner. Använd htmlspecialchars på datat innan du skriver ut det på en webbsida, men spara det i originalformat när du lägger in det i databasen. På så vis kan det användas även i andra sammanhang än bara webb.