object/Array in Datenbank speichern (ohne serialize)
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
anbieten
array
beispiel
bewohner
code
dach
datenbank
datum
fenster
forum
http
index
objekt
problem
sinn
string
suche
tabelle
url
wissen
-
Hallo.
Ich möchte ein beliebiges Object/Array in der Datenbank speichern und von der Datenbank abrufen können.
am liebsten wären mir 2 funktionen à la saveObj(Object,id) und getObj(Object,id)
Allerdings möchte ich die Daten einzeln speichern und nicht einfach das Object als text.
Beispiel:
class gebäude{ public $mitDach; public $anzahlFenster public $bewohner = array() } ... jetz mal angenommen ich habe 2 Objecte.... Haus = {mitDach= true, anzahlFenster=7, bewohner={"franz","Max","Trude"} }; Auto= {mitDach= false, anzahlFenster=4, bewohner={"franz"} };
gespeichert stelle ich mir das in etwa so vor:
Tabelle "Gebäude" ID______mitDach_______anzahlFenster________bewohner 1 true 7 1 2 false 4 2 Tabelle "Gebäude_bewohner" ID______value 1 franz 1 Max 1 Trude 2 franz
Ich möchte mir das lästige tabellen-erstellen erleichtern.
Also zB sollte die Funktion schlau genug sein zwischen text,Zahlen und boolean zu unterscheiden
und mehrdimensionale arrays verarbeiten können.
Bei google wurde ich nicht fündig.
Aber so etwas oder was ähnliches gibt es doch bestimmt schon oder?
Beitrag zuletzt geändert: 14.2.2013 22:12:41 von simuliertes -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
simuliertes schrieb:
klar! und zwar genau hier bei google!
... Bei google wurde ich nicht fündig.
Aber so etwas oder was ähnliches gibt es doch bestimmt schon oder?
also ich glaube, mich elcht ein knutsch.
das einfachste ist was man dir anbieten kann, ist doch serializieren und zwar (genau) so.
was soll daran verkehrt sein?? so ein schwachfug!
Beitrag zuletzt geändert: 15.2.2013 1:43:34 von czibere -
czibere schrieb:
simuliertes schrieb:
klar! und zwar genau hier bei google!
... Bei google wurde ich nicht fündig.
Aber so etwas oder was ähnliches gibt es doch bestimmt schon oder?
also ich glaube, mich elcht ein knutsch.
das einfachste ist was man dir anbieten kann, ist doch serializieren und zwar (genau) so.
was soll daran verkehrt sein?? so ein schwachfug!
Äh, ja danke für die eierlegendewollmilchsau.
Ich denke irgendwas hast Du ziemlich falsch verstanden.
Um mal bei meinem Beispiel zu bleiben..
stell Dir vor ich habe (sagen wir) 2000 objecte des typs "gebäude" serializiert und in der db abgelegt.
Jetzt möchte ich wissen wie wieviele bewhoner durchschnittlich in jedem gebäude wohnen.
Well...
Ich könnte alle 2000 Objekte deserializieren und dann jeweils ['bewohner'] holen und den durchschnitt nehmen.
Sinnvoller wäre es wenn "bewohner" in einer tabellenspalte existieren.
Nur mal als beispiel.
Was ist DARAN schwachfug? -
simuliertes schrieb:
bitte bitte! ich liebe dieses vieh ;)
... Äh, ja danke für die eierlegendewollmilchsau.
Ich denke irgendwas hast Du ziemlich falsch verstanden.
kann mich nicht beklagen. eventuell ich konnte meine gedanken nicht 'greifend' rüberbringen.
Um mal bei meinem Beispiel zu bleiben..
ich nehme es an, dass es schon bis zu dir durchgedrungen ist, dass (my)sql nicht nur
stell Dir vor ich habe (sagen wir) 2000 objecte des typs "gebäude" serializiert und in der db abgelegt.
Jetzt möchte ich wissen wie wieviele bewhoner durchschnittlich in jedem gebäude wohnen.
SELECT * FROM <table>
kann ;) und "bewohner" existieren - auch serialisiert - in einer 'quasi'spalte. ich habe dein array nachgebaut und in eine db gequetscht. die ersten paar einträge sehen demnach so aus (mit zufallsdaten natürlich):
also ich sehe hier definitiv die spalten 'Dach', 'Fenster', 'Bewohner'. nur! halt horizontal angeordnet. (kein problem für mysql ;)a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:9;s:8:"Bewohner";a:1:{i:0;s:9:"lfiAxbLMT";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:4;s:8:"Bewohner";a:1:{i:0;s:5:"OuHqm";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:9;s:8:"Bewohner";a:2:{i:0;s:6:"SoHsZO";i:1;s:6:"vxVgat";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:6;s:8:"Bewohner";a:2:{i:0;s:5:"gyoXD";i:1;s:9:"lpnkqgNzR";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:7;s:8:"Bewohner";a:4:{i:0;s:11:"tSJByjPuMRz";i:1;s:5:"SMgZv";i:2;s:8:"wkevCgNf";i:3;s:6:"boGvkl";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:10;s:8:"Bewohner";a:3:{i:0;s:8:"brxwLVSt";i:1;s:7:"IYunxcR";i:2;s:8:"FNjckWQn";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:6;s:8:"Bewohner";a:3:{i:0;s:6:"tlIVYb";i:1;s:10:"JCxQRIefjV";i:2;s:7:"wSqvpub";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:6;s:8:"Bewohner";a:1:{i:0;s:10:"nSeTVMGYud";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:5;s:8:"Bewohner";a:1:{i:0;s:9:"wmiHRMbtz";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:6;s:8:"Bewohner";a:1:{i:0;s:7:"buVcBDY";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:3;s:8:"Bewohner";a:4:{i:0;s:6:"ylwdUv";i:1;s:5:"BDUwm";i:2;s:5:"bnRqx";i:3;s:9:"ZIiqKuGEh";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:8;s:8:"Bewohner";a:1:{i:0;s:7:"WKUJwnv";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:10;s:8:"Bewohner";a:3:{i:0;s:10:"eyqnumhTDr";i:1;s:6:"BlSqDM";i:2;s:6:"UDITyK";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:8;s:8:"Bewohner";a:2:{i:0;s:5:"BqFDW";i:1;s:11:"NJRgClcifXu";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:8;s:8:"Bewohner";a:1:{i:0;s:9:"AeYEkyGxz";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:2;s:8:"Bewohner";a:1:{i:0;s:11:"CLYvZMqXkfp";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:9;s:8:"Bewohner";a:2:{i:0;s:11:"mjgRFYnHaZE";i:1;s:8:"NBbodlcJ";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:5;s:8:"Bewohner";a:3:{i:0;s:9:"NaXfVysoY";i:1;s:9:"PAeOIgbrt";i:2;s:7:"CYNPGxa";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:1;s:8:"Bewohner";a:4:{i:0;s:6:"ODjpbI";i:1;s:6:"LNTYhH";i:2;s:10:"tgmNznIfHj";i:3;s:7:"TQEpyBz";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:2;s:8:"Bewohner";a:5:{i:0;s:5:"EsqFi";i:1;s:11:"ZAHGBwQqhoK";i:2;s:5:"htTdZ";i:3;s:6:"JLqfQU";i:4;s:5:"AxbTF";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:4;s:8:"Bewohner";a:2:{i:0;s:7:"heuEdZF";i:1;s:10:"wGIpVAYLri";}} a:3:{s:4:"Dach";b:0;s:7:"Fenster";i:3;s:8:"Bewohner";a:5:{i:0;s:8:"slEUQZTP";i:1;s:9:"yqlaZLkCz";i:2;s:8:"aoOwCcxK";i:3;s:7:"ErFVMIy";i:4;s:9:"qIlMbBpci";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:8;s:8:"Bewohner";a:3:{i:0;s:9:"xYZVlGCPv";i:1;s:8:"OykjLKXv";i:2;s:11:"fouZPpvGsta";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:6;s:8:"Bewohner";a:2:{i:0;s:5:"oJvcd";i:1;s:7:"QHhrIoE";}} a:3:{s:4:"Dach";b:1;s:7:"Fenster";i:10;s:8:"Bewohner";a:5:{i:0;s:10:"nhGwjCApZi";i:1;s:5:"WmBuS";i:2;s:8:"ykJnmVME";i:3;s:10:"NodqSUGHXC";i:4;s:6:"qYbXMi";}}
Well...
NÖÖÖ! aus der vorigen behauptung folgt direkt am fuße, dass du nicht deserialisieren musst!
Ich könnte alle 2000 Objekte deserializieren und dann jeweils ['bewohner'] holen und den durchschnitt nehmen.
Sinnvoller wäre es wenn "bewohner" in einer tabellenspalte existieren.
Nur mal als beispiel.
Was ist DARAN schwachfug?
klar ;) wenn du alle schikanen von allen möglichkeiten brauchst, dann kommst du um das herumproggen nicht herum (weil die von dir erträumte funktionaltät ist - meines wissens nach - nicht vorhanden)! reichen dir allerdings gewisse möglichkeiten, dann kannst wohl serialsierte daten in einer db mit mysql begegnen. ich habe in meiner nachbau nur 200 daten, die aber reichen für die beweltigung deines gerade vorgegebenen problems - und nicht nur!
hier kannst meine - ich nenne es mal (großkotzig) - studie ;) - über das prob 'serialisierte daten in datenbanken mit queries beweltigen' ansehen. die zwei queries sind als anreiz auch mit dabei ;)
in dem beispiel ist 'nur' enthalten:
1. suche haus mit dach, 10 fenstern, 5 bewohnern, der 2. bewohnern heißt: 'W...'
2. berechne durchschnitt der bewohnern pro wohneinheit (eigentlich deine vorgabe vorhin ;)
[beide beispiele sind mit php+deserialisieren um die 15 bis 20 fach langsamer! bei 2000+ datensätzen quälend - eventuell]
zum schluss: was ist daran schwachfug? (ist normal ja eh nicht, das ist nur die redewendung.) mysql - auch wenn von vielen nicht bewust - ist 100 bis 1000 mal schneller als jeder apache-php gespann (eben! weil mysql auch rechnen und text verarbeiten kann [sehr sehr schnell] ;)
Beitrag zuletzt geändert: 16.2.2013 3:54:38 von czibere -
czibere schrieb:
simuliertes schrieb:
bitte bitte! ich liebe dieses vieh ;)
... Äh, ja danke für die eierlegendewollmilchsau.
Ich denke irgendwas hast Du ziemlich falsch verstanden.
kann mich nicht beklagen. eventuell ich konnte meine gedanken nicht 'greifend' rüberbringen.
Mmmmhhh... ich gebe zu das wird's eher gewesen sein.
Ich gbe zu SQL ist nicht gerade meine stärke.
Sehe ich das richtig das das allerdings nur ohne gzencode() && base64_encode() funktioniert?
Wenn ja, stichwort sql-injection und sonderzeichen Falls ein Wert ein string von einer Benutzereingabe ist?
(Ich vermute das war der sinn von gzencode())
edit:
Ich denke ich weiss die Antwort schon, ich müsste halt alle strings vor dem speichern "gzencodet" im Array/Object ablegen.
SQL ist es ja egal ob ich nach "franz" oder "GH5TR" suche...
(weil die von dir erträumte funktionaltät ist - meines wissens nach - nicht vorhanden)!
Ja, nee.
Das es sowas seitens php gibt hatte ich auch nicht erwartet.
Ich hatte eher daran gedacht das irgend jemand vielleicht schon eine funktion geschrieben hat die rekursiv ein Object/Array durchsucht und je nach typ (Array/string/integer/boolean) einigermassen sinnvoll in eine datenbank packt (und bei bedarf auch erstellt).
Aber das hat sich ja erledigt...
Beitrag zuletzt geändert: 17.2.2013 19:09:16 von simuliertes -
simuliertes schrieb:
Das ist überhaupt nicht der Sinn von gzencode!
(Ich vermute das war der sinn von gzencode())
Das was du meinst ist mysql_real_escape_string(). -
hackyourlife schrieb:
simuliertes schrieb:
Das ist überhaupt nicht der Sinn von gzencode!
(Ich vermute das war der sinn von gzencode())
Das was du meinst ist mysql_real_escape_string().
Ui, kleiner "Versprecher", ich meinte base64_encode (sonderzeichen!)
edit:
Ich hatte angenommen das czibere
base64_encode
verwendet um sql-injection+sonderzeichen zu umgehen und
gzencode
um das ganze nicht zu gross werden zu lassen....
Beitrag zuletzt geändert: 17.2.2013 19:16:09 von simuliertes -
simuliertes schrieb:
Woher leitest du das ab? Wie kommst du überhaupt auf den Gedanken?
Ich hatte angenommen das czibere
base64_encode
verwendet um sql-injection+sonderzeichen zu umgehen und
gzencode
um das ganze nicht zu gross werden zu lassen....
Falls du cziberes Datensätze ala
meinst: er hat dazu selbst geschrieben:lfiAxbLMTmit zufallsdaten natürlich
-
hackyourlife schrieb:
Woher leitest du das ab? Wie kommst du überhaupt auf den Gedanken?
czibere schrieb:
das einfachste ist was man dir anbieten kann, ist doch serializieren und zwar (genau) so.
-
zwei kleine Anmerkungen zum Thema:
1. Diese Art der Lösung entfernt sich vom klassischen Relationalen Datenbankmodell.
2. Es können Einschränkungen hinsichtlich der Portabilität (z.B. Datenmigration) auftreten.
mfg,
timebandit -
simuliertes schrieb:
ja das war meine ursprüngliche idee. die habe ich dann auf deine anforderung - die datenbank direkt abfragen zu können - aber dann so abgeendert. das ist die neuere, 'queryable' version ;) [die natürlich auch für gespeicherte objekte gilt.]]
...czibere schrieb:
das einfachste ist was man dir anbieten kann, ist doch serializieren und zwar (genau) so.
einen sicherheitsmechanismus habe ich aus zeitgründen nicht ansatzweise eingebaut! (ja nicht einmal nachgedacht.)
timebandit schrieb:
definiere klassich in dieser beziehung. 'kundenwünsche' sind meistens UNklassisch.
zwei kleine Anmerkungen zum Thema:
1. Diese Art der Lösung entfernt sich vom klassischen Relationalen Datenbankmodell.
2. Es können Einschränkungen hinsichtlich der Portabilität (z.B. Datenmigration) auftreten.
dieses problem hat man öfters, als einem lieber wäre. suche danach in foren. allein hier bei lima gibt es beispiele in scharen. -
czibere schrieb:
timebandit schrieb:
definiere klassich in dieser beziehung. 'kundenwünsche' sind meistens UNklassisch.
zwei kleine Anmerkungen zum Thema:
1. Diese Art der Lösung entfernt sich vom klassischen Relationalen Datenbankmodell.
2. Es können Einschränkungen hinsichtlich der Portabilität (z.B. Datenmigration) auftreten.
dieses problem hat man öfters, als einem lieber wäre. suche danach in foren. allein hier bei lima gibt es beispiele in scharen.[/quote]
damit du mich nicht missverstehst:
Ich finde deinen Lösungsansatz gelungen.
Mein Hinweis bezieht sich eher darauf, dass bei deiner objektorientierten Ausarbeitung größere Probleme auftauchen können, als das ohnehin bei "normalen" Datenbanken bereits der Fall sein kann.
Zumindest sollte man mögliche Schwierigkeiten mit in Betracht ziehen.
mfg,
timebandit -
timebandit schrieb:
serialsierte daten werden massenweise in datenbanken abgelegt, so dass man hier keine erhöhte gefahr kalkulieren muss. allerdings! jetzt schuldest uns schon 2 definitionen: klassisch und normal!!??
..., dass bei deiner objektorientierten Ausarbeitung größere Probleme auftauchen können, als das ohnehin bei "normalen" Datenbanken bereits der Fall sein kann.
Zumindest sollte man mögliche Schwierigkeiten mit in Betracht ziehen.
auf dedizierten servern gibt es keine. bei hostern wie lima, die gezwungener massen einiges sperren müssen wohl (sieh 1. beispiel [geht bei lima nicht], 2. beispiel [ist ja bei lima]).
Beitrag zuletzt geändert: 17.2.2013 23:29:11 von czibere -
czibere schrieb:
allerdings! jetzt schuldest uns schon 2 definitionen: klassisch und normal!!??
normal wurde von mir bewußt in Anführungszeichen gesetzt und bedarf daher keiner eigenen Definition.
Unter klassischer Relationaler Datenbank verstehe ich jenes Datenbankmodell, welches seit mehr als 40 Jahren existiert und im Unterschied zur objektorientierten Datenbank keine Objekte in den Tabellen kennt.
Vor- und Nachteile beider Modelle möge jeder selbst beurteilen.
mfg,
timebandit
-
timebandit schrieb:
also wenn ich jetzt 'eine debile person' in anführungszeichen habe, ist sie dann normal? ;)
... normal wurde von mir bewußt in Anführungszeichen gesetzt und bedarf daher keiner eigenen Definition.
Unter klassischer Relationaler Datenbank verstehe ich jenes Datenbankmodell, welches seit mehr als 40 Jahren existiert und im Unterschied zur objektorientierten Datenbank keine Objekte in den Tabellen kennt.
ähhmmm ... also nochmals (wegen der verdauung)!:
"... und im Unterschied zur objektorientierten Datenbank keine Objekte in den Tabellen kennt."
also wenn das RDBMS (in unserem fall mysql) das irgendwie mitkriegt, das das hierH4sIAAAAAAAAA11Wy44bNxD02V9B7FkQ7Di5yCcj2cAGHCdBHneKbEkdDMkxH4KAIP+eqqa0UrLAYmdn+Oiurqrun3ff7Z6+/11af9q92/3ddm93T+HpPf7yoeTW6whdIl99u3vqXPg+7t5u3775z8/b65ZXdtarpVTllndvvvlm9/S5VElO1zaSiwXfXNPufJK+cSVlbS5Krz704s7axyrVd+++juLksnGjDZfFlf2iX4c4zz8+Ob+uvorvW/dFgjv4oIs2deeyjLX7qt75uHEHqVVxXT4OfOY5ay1b9wfOlIvTtEpEKDhQquQ40sZ1W+KiBrzqvEaWxec+6tZ9yjN+ZpPPGkfmXt26P/WC61LBCc63NuQsFefmsplpdJ6HoPG641hcg/+7b44LO3Ku2O5kpK37DfvEO8MeH7ApykGzdi1Z2vb1a8a+lhyl8rJeUuHDAJaju4StK4/M/uKqrFWTofZwBi7X7BBreQy1id+6Z3UnzcGJVnx3x+olALWzIq6PeJBF9ACcXAmjVsMHWEVpDU9hbJDf4ny+Jqso6cgRldArj7QAxB8IyLzAr3hQbDgxt+477mAivuNOJCgVW6UmvEZSGsaCswZBeCa4Z+Tdy7IgfCsL/sXXDSJJhFAH49jjK8DskieCGyNfkgVL8aFrVDFegUkfUZEqe2xfyzqW4lqouhcWH7zYGLqgkD+AVn3CI4iwgyFy9Aj84BEN06pK2q0LwEIiBPysbet+Ka3jjOaX0T0+AW4EMbbu56jFTjpWQQhhNL8vTBr3IaFSkdyKuEvS3o2NyJ9ZgJRGHMCO/FbAHkrCvcFYRaQuUoNCCOOowDXharV6ic79z97KdvLEr5+krKfqWx9U5QIAUZQGFgE3iXcmUzpcc0KGlQzakCY8tI0WlLGuJy+xktPfM754GsEtfkRTz6xqlilf5EI7eMDydozlyrMvbin7UkmRJrnpfkyuUF8ar2UrazGBXV0iR2j9C6JNgBsZd8UzbKMroi4GrSmkuQNEfT00wRIK6o4diBS6ALwb/CIi0MMHsKsZx4EiMBcTHYD+AHRad2NZiKMn2xyYhfJDcfkliAzOAFAu4G2kFUCLJRBNC1tXpovC4LRwKjAjpAL3Iks1zozBILlpAuEnENvXcCLxwabni1HVNG6CnirhVo2IJJc8kjTAjeTBNZIaGxBJIahuQncTwbQ8sPeLMe7hWmCwGpEB8/MCxlZfjSG312ZBQo7QKtWYOhMw8ZSHvAUhmYcwBiCyYgEBhukUZJ6tdld3N+gA+a+sfXZ/jYbWkaEtYAX2aMJX90w7yLwszhXm32IKQTsQNABQmALF4k/WnKYb2y19pQkhW3q4QQJd1yNgAyET84K7IEWP+kWEgSVghSVzZPfz1jB+QiJhQHRq7gSnhGvnvjEcQfquSV4cXva+3RsgzmCSOMKc6lyC8YV9ATbYhwVHZl5t6Opod88BAdA6gdJnOVISB2WPowpokBumT3nDp+5NKFgN4FMAEowPwAdP97xpnklnI6ZW67R++pSPW/ejR9N0+4XW1gmJNdsfUOjKADPeVwMk0BVgPBlqmQV58edJREKKABaPnbxg4cl0BT1mtCCAiRBYY1PWGW7bXlrBQ7vc3DvlvRtV4VQwXX2CYcxohcIljIz2OlAwNZoopokF6fp7y4KOp0QxRyQ/h4sjyDfPRUZhGc36LSKdBoBdau6Ag/Ls1yR7QNT+Kv14m29YeE+KHODb/dZybmMOEmMKMLwD+7F2M1/Ns/fhCEwBvlelcswRPlUdrMGDTyilMXNjs3UWe6T4SruySh83PI4Qdo1GmxjgoNYTcp8SHDabkTliYw5NACOkReK5elYXjfDB7xHPZUrWD9rugrZbTXuAIOtJlxfxPFBw9q9hvktkIzQoq9xXmGeZA+Yy+959hoHwzNYTWfG/7Kx6kRrmNSfD+2KiJeEfBivMa8Lmw2VmgCDwjToe5WCzHynBlgZfUshK5/rJ623g4YyxdhsqH+2N7LCZ4UO2JtQQWb8NTpjvgo2fNsvBGco185Pt6I8d4w7x/7yFhZ4qRAdukqhiumXDQPvhOl2jkQVN6ISNUiHnXz+9/+dfVeAaJjYMAAA=
(ist genau das objekt im 1. beispiel) ein objekt ist, dann ist ein wunder geschehen!
Vor- und Nachteile beider Modelle möge jeder selbst beurteilen.
ja, vor allem diejenigen, die sich mit der matherie (O)ODBMS auskennen ;)
wenn der TE nichts gegen das schließen einzuwenden hat, bitte das hir zuzumachen, bevor alle philosophen hier noch tonnen von gulden verdienen (in etwa um sonst).
-
czibere schrieb:
wenn der TE nichts gegen das schließen einzuwenden hat, bitte das hir zuzumachen, bevor alle philosophen hier noch tonnen von gulden verdienen (in etwa um sonst).
jo, nix dagegen.
Meine Frage ist beantwortet. (THnks btw) -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
