nicht angemeldet
variable egal ob normal oder Array in DB speichern
Servus,
Wie bring ich das hin, dass ich Name und Wert von Variablen die per GET und POST kommten in einer DB speichern kann, auch wenn es Arrays sind?
Das hier funktioniert:
if( isset($_GET['set']) )
{
$vars = $_GET;
}
if( isset($_POST['set']) )
{
$vars = $_POST;
}
if( isset($vars) )
{
foreach( $vars AS $name => $wert)
{
Speichere name und wert in DB;
}
}
Sieht z.B. so aus in der Datenbank:
id name wert
------------------------
1 farbe grün
2 option1 rechts
3 zähler usw
Aber wenn da Arrays kommen habe ich ein Problem.
Verständlicherweise sieht es dann so aus:
id name wert
------------------------
1 farbe grün
2 Array
Anstatt irgendwie so:
id name wert
------------------------
1 farbe grün
2 option[1] rechts
3 option[2] links
Wie löst man dieses Problem am einfachsten? Und kann man beim Auslesen der DB die Namen (als Text) wieder zu Arrays machen?
( z.B. "option[1]" zu $option[1] )
Besten Dank im voraus.
-
Hello,
es ist nicht ungefährlich für Diene Datenbank, was Du da gerade praktizierst.
Man nennt die Sicherheitslücke, die Du da baust "SQL Injection".Außerdem ist es möglich, gleichzeitig $_GET und $_POST zu empfangen.
Willst Du wirklich alle Parameter, die Dir übersandt werden, als Variablen in der DB speichern, oder nur eine definierte Menge daraus? Du weißt ja sicher, dass man per Formular vom Client senden kann, was immer man will.
Du solltest also auf dem Server einen Abgleich betreiben mit der (maximal) erwarteten Menge von Parametern.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
Hello,
Du solltest also auf dem Server einen Abgleich betreiben mit der (maximal) erwarteten Menge von Parametern.
mach ich, mein Beispiel habe ich nur wegen der Verständlichkeit abgeändert.
Eigentlich geht es darum, Benutzer-Einstellungen in der DB zu speichern. Es wird jedoch vorher überprüft, ob die entsprechende Standart-Einstellung bereits vorhanden ist.
Und diese Einstellungen sollten eben auch Arrays sein können.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
-
Hello,
Eigentlich geht es darum, Benutzer-Einstellungen in der DB zu speichern. Es wird jedoch vorher überprüft, ob die entsprechende Standart-Einstellung bereits vorhanden ist.
Und diese Einstellungen sollten eben auch Arrays sein können.
Das habe ich mit Style-Eigenschaften so gemacht. Es gibt eine Tabelle mit den Vorgaben und Namen der CSS-Eigenschaften. Diese enthält auch Angaben über die Range und, ob diese Angabe zum jeweiligen Objekt eine Pflichteingabe ist oder eine freiwillige und ob der User sie überhaupt beeinflussen darf, oder die Angabe automatisch in das Gesamtobjekt eingefügt werden muss.
Abgespeichert wird dann tatsächlich das geprüfte und überarbeitete serialisierte Array. Da man nicht nach Daten dieses Feldes suchen muss, ist keine atomistische Darstellung (weitere Normalisierung) notwendig.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo,
... Da man nicht nach Daten dieses Feldes suchen muss, ist keine atomistische Darstellung (weitere Normalisierung) notwendig.
warum unter den scheffel stellen. so wie du es beschreibst liegen deine daten dann in atomarer form vor. demzufolge muss auch nicht weiter normalisiert werden.
Ilja
-
Hello,
... Da man nicht nach Daten dieses Feldes suchen muss, ist keine atomistische Darstellung (weitere Normalisierung) notwendig.
warum unter den scheffel stellen. so wie du es beschreibst liegen deine daten dann in atomarer form vor. demzufolge muss auch nicht weiter normalisiert werden.
nicht ganz. Nur die Mustertabellen (Klassen + Eigenschaften der Klasse) liegen wirklich als eigene Zeilen vor. Die CSS-Daten der Instanz des Makro-Objektes, das über die Klasse beschrieben wird, sind dann in einem Array verpackt. Die Normalisierung ist also nicht homogen vorgenommen, sondern hat hier einen Bruch beim Übergang von Einzeldatensätzen zum Array.
Im Sinne von SQL liegt also keine atomistische Aufbereitung mehr vor.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo,
... Die CSS-Daten der Instanz des Makro-Objektes, das über die Klasse beschrieben wird, sind dann in einem Array verpackt. Die Normalisierung ist also nicht homogen vorgenommen, sondern hat hier einen Bruch beim Übergang von Einzeldatensätzen zum Array.
der begriff atomar ist im zusammenhang der normalisierung leider sehr verwirrend. ob ein feld nun atomar ist oder nicht, kommt nicht dadurch zustande, dass es sich nicht weiter aufteilen läßt. so kann zum beispiel der zelleninhalt "Herr Mustermann, 12345 Schloßstraße 15 b, Germany" durchaus atomar sein und demzufolge liegt die normaliersung schon vor.
Ilja
-
Hello,
der begriff atomar ist im zusammenhang der normalisierung leider sehr verwirrend. ob ein feld nun atomar ist oder nicht, kommt nicht dadurch zustande, dass es sich nicht weiter aufteilen läßt. so kann zum beispiel der zelleninhalt "Herr Mustermann, 12345 Schloßstraße 15 b, Germany" durchaus atomar sein und demzufolge liegt die normaliersung schon vor.
Wenn Du damit meinst, dass der Zelleninhalt "Anrede, Vorname, Nachname, PLZ, Strasse, Land" für alle Datensätze der Tabelle immer in dieser Form und Kombination auftritt, dann stimme ich Dir teilweise zu. Allerdings enthalten Teile der Zelle dann voraussichtlich immer noch redundante Datenvorkommen in der Vertikalen.
Ich kann die Regeln nicht auswendig runterbeten, aber wenn sich Daten häufiger wiederholen, wäre eigentlich Normalisierung angesagt, zumindest, wenn ein Schlüssel (erheblich) kürze wäre, als die Klarschriftdaten. Eine PLZ zu normalisieren ist dann also wenig sinnvoll, da die PLZ bereits einen Schlüssel darstellt und der Datenwert nicht länger ist, als ein "Ersatzschlüssel"
Eine Kombination PLZ-Ort-Strasse kann aber durch einen numerischen Schlüssel ersetzt werden, zumal der wahrscheinlich wesentlich kürzer wäre.
Doubletten ähnlicher Daten (Telefon, Fax, Handy) kommen ja hier nicht vor, sodass eine horizontale Zerlegung nicht in Frage kommt.
Allerdings hat jede Zeile eine unterschiedliche Anzahl von Attribut-Wert-Paaren in der horizontalen Richtung. Und die müssten eigentlich normalisiert werden, was durch Werwendung des varianten Zellenformates (Text) hier auch deutlich sichtbar wird.
Das meinte ich vorhin. Ich habe hier also bewusst geschlampt.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo,
Wenn Du damit meinst, dass der Zelleninhalt "Anrede, Vorname, Nachname, PLZ, Strasse, Land" für alle Datensätze der Tabelle immer in dieser Form und Kombination auftritt, dann stimme ich Dir teilweise zu. Allerdings enthalten Teile der Zelle dann voraussichtlich immer noch redundante Datenvorkommen in der Vertikalen.
nein, das meine ich nicht. die form der datensätze muss nicht gleich sein für alle datensätze und trotzdem kann das feld in atomarer form vorliegen. vielmehr sollte man verstehen, was atomar im zusammenhang mit normalisierung bedeutet. ich glaube, da haben wir beide eine unterschiedliche auffassung von.
Ich kann die Regeln nicht auswendig runterbeten, aber wenn sich Daten häufiger wiederholen, wäre eigentlich Normalisierung angesagt, zumindest, wenn ein Schlüssel (erheblich) kürze wäre, als die Klarschriftdaten.
normalsierung hat nur indirekt mit häufigkeiten zu tun. das ist kein kriterium für für eine normaliserungsregel. und auch nicht mit der länge eines schlüssels. normalisierung ergibt sich aus abhängigkeiten. aber nicht jeder gleicher feldeitrag ist auch voneinaner abhängig. wenn von 100 mitarbeitern 50 schulze mit nachnamen heissen, dann ist das kein kriterium für eine normalisierung. das hätte fatale folgen.
Ilja
-
Hello,
normalsierung hat nur indirekt mit häufigkeiten zu tun. das ist kein kriterium für für eine normaliserungsregel. und auch nicht mit der länge eines schlüssels. normalisierung ergibt sich aus abhängigkeiten. aber nicht jeder gleicher feldeitrag ist auch voneinaner abhängig. wenn von 100 mitarbeitern 50 schulze mit nachnamen heissen, dann ist das kein kriterium für eine normalisierung. das hätte fatale folgen.
Kommt darauf an...
Stell Dir vor, Du hast einen Zeitungsvertrieb (morgens verteilen gehen *gg*) und musst Deine Kunden den Stadtteilen und Straßen zuordnen. Dann wäre es legitim, eine Tabelle aufzubauen, in der die Kombination Stadtteil-Straße-Tour mit einer Tournummer indiziert und ausgegliedert würde.
Da ist sowas ähnliches, wie Schulze, Schulze, Schulze, ...
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo,
Kommt darauf an...
nein, was atomar bezüglich normalisierung ist und aus welchen gründen man normalisiert ist ganz eindeutig definiert. was du persönlich davon hälst und wie du deine datenbank-struktur letztlich aufbaust ist eine andere sache und es steht jedem frei.
Ilja
-
Hello,
yo,
Kommt darauf an...
nein, was atomar bezüglich normalisierung ist und aus welchen gründen man normalisiert ist ganz eindeutig definiert. was du persönlich davon hälst und wie du deine datenbank-struktur letztlich aufbaust ist eine andere sache und es steht jedem frei.
Ja. Da stimme ich Dir auch zu. Aber welche zwei leicht erkennbaren Erscheinungsformen von Datensammlungen sollten denn die Normalisierungslampen auf Alarm stellen? Ich kriegs heute Abend nicht mehr in Worte gegossen.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo Tom,
... Aber welche zwei leicht erkennbaren Erscheinungsformen von Datensammlungen sollten denn die Normalisierungslampen auf Alarm stellen?
gar keine. die ersten drei regel sollte man anwenden und zwar unabhängig davon, welche daten letztlich zur verfügung stehen. wenn du ein datenmodell entwickelst, hast du in aller regel eh noch gar keine daten, sondern es ist eben nur die datenstrukur, die entworfen wird. es gibt also bei den ersten drei normalisierungen keinen bezug auf den dateninhalt.
die erste regel stellt sicher, dass die daten in atomarer form vorliegen. dieser begriff wird leider sehr oft falsch verstanden. atomar bedeutet nicht, alles in kleinste teile zerlegen zu müssen, sondern atomar bezieht sich auf die art und weise, wie ich die daten nutze. das bedeutet atomar bezüglich der normalisierung.
die beiden nächsten schritte entfernen die direkten (2. regel) und indirekten (3. regel) abhängigkeiten der daten aus dem datenmodell. hier kommt auch der bezug zu "doppelten" daten. aber es hat damit im engen sinne nichts damit zu tun. wichtig ist nur die abhängigkeit, nicht aber der gleiche inhalt.
Ilja
-
Hello,
... Aber welche zwei leicht erkennbaren Erscheinungsformen von Datensammlungen sollten denn die Normalisierungslampen auf Alarm stellen?
gar keine. die ersten drei regel sollte man anwenden und zwar unabhängig davon, welche daten letztlich zur verfügung stehen. wenn du ein datenmodell entwickelst, hast du in aller regel eh noch gar keine daten, sondern es ist eben nur die datenstrukur, die entworfen wird. es gibt also bei den ersten drei normalisierungen keinen bezug auf den dateninhalt.
Da hast Du mich jetzt aber gründlich verkehrt verstanden. Ich meine nicht die Realdaten, sondern ihre Darstellungsform, also die Datenstruktur und/oder das daraus zu entwickelnde Datenmodell.
Ich versuche nur, das mal allgemeinverständlich auszudrücken. Und da gibt es ein horizontale und eine vertikale Sicht auf die Datenstrukturen, die Auslöser für die Normalisierung sind.
Ich sehe das bisher so:
Horizontal wäre, wenn ich z.B. mehrere Felder "Telefon" im Datensatz habe, die sich dann natürlich im Namen unterscheiden, bei einem Datensatz gar nicht benötigt werden und beim anderen immer noch nicht ausreichen
Vertikal wäre die dauernde Wiederholung von Datenwerten in Feldern der Tabelle (Gruppenbildung)
Und schließlich, wenn Felder mehrwertig werden, also _gleichzeitig_ verschiedene Teilmengen einer bekannten Gesamtmenge annehmen können (aber nicht müssen)
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo,
vielleicht habe ich es ja wirklich falsch verstanden. aber mir ist es ein wenig schleierhaft, wie du begriffe wie "datensammlung" und "vertikale sicht" verwendest, ohne dabei auf datenbestände zurückzugreifen, sondern nur auf die daten-struktur. wenn du dir mal die ersten drei normalisierungsregeln anschauen würdest, dort ist kein hinweis auf doppelte daten.
Ilja
-
Hello,
jetzt hast Du mich doch tatsächlich einen Moment lang verwirrt.
aber:
Beim Erzeugen der ersten Normalform werden i.d.R. mehrwertige Eigenschaften aufgebrochen und in einwertige umgewandelt. Das führt dann zu vertikalen Redundanzen, die sich auch in horizontalen Abhängigkeiten von Nicht-Schlüssel-Elementen zeigen können. Leider sieht man nicht alle Redundanzen auf diese Weise. Dafür muss man tatssächlich etwas über die Daten wissen, nämlich ob eine Spalte einen (voraussichtlich) begrenzten Vorrat an Werten hat, der erheblich kleiner sein wird, als die Anzahl der zu erwartenden Datensätze.Dann wäre es nämlich richtig, für diesen Wertevorrat eine eigene Tabelle anzulegen.
In dem Beispiel http://www.tinohempel.de/info/info/datenbank/normalisierung.htm ist das schön gezeigt für die Abt-Nr. und die Abteilung. Hier sind schon Schlüssel und Bedeutung vorhanden. Für die Orte-Strassen-Kombination der Bundesrepublik gibt es eine ähnliche Abhängikeit. Ein Teil des Schlüssels ist mit der PLZ bereits vorhanden. Durch Ergänzung des Schlüssels wird die Orte-Strassen-Kombination genauso abhängig von diesem, wie die Abteilungsbezeichnung von der Abteilungsnummer.
Auch wenn in den ersten drei Normalisierungsregeln die Datensicht nicht explizit erwähnt wird, ist es nicht verboten, aus einer (Muster-)Datensicht auf die Regeln zurückzuschließen.
Sicher hast Du recht, dass das nicht die absolut abstrahierte Vorgehensweise ist, aber als zusätzliche Möglichkeit vereinfacht sie die Betrachtung.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
yo,
und ich werde mir unsicherer, ob du überhaupt die normalisierungen gelesen und verstanden hast. die ersten drei regeln haben nichts, aber auch gar nichts mit dateninhalten zu tun. ich habe schon mal versucht zu erklären, dass selbst wenn 99% eine spalte den gleichen wert haben, das nicht bedeutet, dass keine normalisierung erfolgte.
Ilja
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Moin!
Wie bring ich das hin, dass ich Name und Wert von Variablen die per GET und POST kommten in einer DB speichern kann, auch wenn es Arrays sind?
Die direkte Antwort auf diese Frage ist serialize() bzw. unserialize().
Aber das ist keine Antwort auf dein Problem. Denn wenn du sowas wie das hier:
id name wert
1 farbe grün
2 option[1] rechts
3 option[2] linksin der DB haben willst, brauchst du nicht die Fähigkeit, ein Array in die DB zu speichern, sondern die Fähigkeit, zu entscheiden, ob deine Variable ein Array ist oder nicht (is_array() weiß das), um dann entsprechend dieser Feststellung die Inhalte des Arrays einzeln aufzudröseln und in die DB zu schieben, oder eben direkt den Variableninhalt des Nichtarrays.
Bedenke aber, dass deine DB-Struktur nicht wirklich ideal ist. Wenn du zu einem Einstellungswert grundsätzlich mehrere Auswahlmöglichkeiten zulassen willst, dann muß sich das in der DB-Struktur widerspiegeln - und das sieht IMO anders aus, als das Speichern von garantierten Einzelwerten.
- Sven Rautenberg
-
Danke für die Antwort
mfg Tobias
-