nicht angemeldet
Mehrere Tabellen: Sätze zur Adresse zählen
Hallöle,
pro Adresssatz kann ich in mehreren Tabellen Datensätze haben:
ADRESSE
id nname vname
-- ----- ------
11 Meyer Alfred
ANWESEMHEIT
id adress_id stunde
-- --------- ------
99 11 5
98 11 6
97 11 7
GESPRAECHSPARTNER
id besucher_id aussteller_id
-- ----------- -------------
55 11 4711
56 11 0815
EVENTWUENSCHE
id adress_id event_id
-- --------- --------
22 11 3215
23 11 6921
Nun suche ich _ein_ SQL-Kommando, das mir folgendes Ergebnis liefert (anz = Anzahl):
adress_id anz_stunden anz_partner anz_events
--------- ----------- ----------- ----------
11 3 2 2
Habe es mit LEFT JOIN probiert, aber da potenziert sich die Anzahl der Datensätze unkontrolliert, die Summen sind zu hoch.
Muss ich wirklich für dieses Problem drei SQL-Kommandos absetzen? Mit der Konsequenz, sie per PHP-Code wieder zusammenzutragen?
Auch wenn ich mich oute: Die Lösung sollte mit MySQL Version 3.23.58 verträglich sein.
Kalle
-
yo,
pro Adresssatz kann ich in mehreren Tabellen Datensätze haben:
ADRESSE
id nname vname
11 Meyer Alfred
der name dieser tabelle ist ein wenig verwirrend, da letztlich dort personen (kunden ?) stehen. eventuell ist es nur ein auszug der tabelle, aber trotzdem habdelt es sich eher um personen und weniger um adressen
ANWESEMHEIT
id adress_id stunde
99 11 5
98 11 6
97 11 7das sieht so aus, als wenn es sich um "von bis" zeiten handelt, und man könnte diese in einem datensatz zusammenfügen anstelle jede stunde festzuhalten. mich wundert, dass es kein datum gibt.
GESPRAECHSPARTNER
id besucher_id aussteller_id
55 11 4711
56 11 0815EVENTWUENSCHE
id adress_id event_id
22 11 3215
23 11 6921anwesenheit, gesprächspartner und eventwünsche könnte man eventuell zu einer tabelle (Treffen) zusammenfassen, falls sie alle in einer 1:1 beziehung stehen, sprich zu einem treffen ein gesprächparnter und ein eventwunsch. ist aber nur eine vermutung von mir, da müsste man dein umgebung besser kennen.
adress_id anz_stunden anz_partner anz_events
11 3 2 2
Habe es mit LEFT JOIN probiert, aber da potenziert sich die Anzahl der Datensätze unkontrolliert, die Summen sind zu hoch.
ist auch klar, weil die beziehungen fehlen, sprich zu welcher stunde hat er welchen gesprächpartner gehabt oder welche eventwünsche in welcher stunde. da diese beziehungen fehlen, nimmt er einfach alle möglichen kombinationen bei deinen join. wenn du wie oben bereits angesprochen alles in eine tabelle bekommst und es sich um 1:1 beziehungen handelt, dann löst sich das problem von ganz alleine.
nun aber genug genörgelt, zurück zu deiner abfrage. eine mögliche lösung, die mir spontan einfällt, ist der UNION operator, wobei ich mir bei mysql nicht sicher bin, aber welcher version es unterstützt wird. unterabfragen sollten es auch können, diese gehen aber definitiev erst ab 4.1+.
aber bevor man eine lösung ausarbeitet, vielleicht solltest du noch mal über die fehlenden beziehungen nachdenken.
Ilja
-
hi,
eine mögliche lösung, die mir spontan einfällt, ist der UNION operator, wobei ich mir bei mysql nicht sicher bin, aber welcher version es unterstützt wird. unterabfragen sollten es auch können, diese gehen aber definitiev erst ab 4.1+.
UNION ab 4.0.0, siehe http://dev.mysql.com/doc/refman/4.1/en/union.html
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; } -
Hallo Ilja,
nun aber genug genörgelt, zurück zu deiner abfrage. eine mögliche lösung, die mir spontan einfällt, ist der UNION operator, wobei ich mir bei mysql nicht sicher bin, aber welcher version es unterstützt wird. unterabfragen sollten es auch können, diese gehen aber definitiev erst ab 4.1+.
UNION wäre wohl das Mittel der Wahl, gibt es in MySQL leider erst ab 4.0.0. Kalle kann einem leid tun.
@Kalle: Ist das der Server, auf dem noch PHP3 im Einsatz ist?
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz,
@Kalle: Ist das der Server, auf dem noch PHP3 im Einsatz ist?
Gutes Gedächtnis. PHP-Version 3.0.18 und MySQL 3.23.58
Vorgestern ist die Personentabelle abgekackt (wie heißt das gebildet auf lateinisch?) und der Provider hat erstmal das einigermaßen aktuelle phpmyadmin auf Version 2.1.0 zurückgesetzt. War aber nicht der Grund für die Kacke.
Jetzt kann ich nicht mal mehr SQL-Kommandos eingeben.
Aber es kann ja auch auf einem anderen Server mit PHP 4.3.10 und MySQL 4.1.9-log laufen.
Nur die schönen, bequemen Dinge schneiden mir den Rückweg nach Dresden ab.
Kalle
-
-
der name dieser tabelle (ADRESSE) ist ein wenig verwirrend, da letztlich dort personen (kunden ?) stehen.
Ja, ist ein Überbleibsel aus alter Zeit. Es handelt sich um Personensätze, die jedoch auch eine Anschrift haben.
ANWESEMHEIT
id adress_id stunde
99 11 5
98 11 6
97 11 7das sieht so aus, als wenn es sich um "von bis" zeiten handelt
Nein, in den Mittagspausen und Abendstunden müssen die Personen nicht anwesend sein. Es macht Sinn, jede Anwesenheits-Stunde einzeln zu benennen, denn jede Stunde kann einzeln verplant werden.
mich wundert, dass es kein datum gibt.
Weil es sich um eine zweitägige Veranstaltung handelt. Die Zeiteinheiten 1-19 sind definitiv am 21.6., die 20-33 am 22.6. Dazu gibt es eine weitere Tabelle mit Datum und Uhrzeiten zwecks leserlichem Druck im Terminplan.
anwesenheit, gesprächspartner und eventwünsche könnte man eventuell zu einer tabelle (Treffen) zusammenfassen, falls sie alle in einer 1:1 beziehung stehen, sprich zu einem treffen ein gesprächparnter und ein eventwunsch. ist aber nur eine vermutung von mir, da müsste man dein umgebung besser kennen.
Der Gesprächs- und Eventwunsch steht ZUNÄCHST ohne Zeitangabe im Raum. Es ist Aufgabe des Programms, zwischen Besuchern und Ausstellern eine gemeinsame freie Zeiteinheit zu finden, bei Events sind noch max. Teilnehmerzahlen zu berücksichtigen. Bei Treffern wird die gefundene Stunde in den Wunschsatz eingefügt.
aber bevor man eine lösung ausarbeitet, vielleicht solltest du noch mal über die fehlenden beziehungen nachdenken.
Welche Beziehung fehlen (nach dieser Erklärung) noch?
Kalle
-
yo,
Ja, ist ein Überbleibsel aus alter Zeit. Es handelt sich um Personensätze, die jedoch auch eine Anschrift haben.
ok, ich würde der tabelle trotzdem einen personenbezogenen namen geben, aber das ist geschmackssache.
Nein, in den Mittagspausen und Abendstunden müssen die Personen nicht anwesend sein. Es macht Sinn, jede Anwesenheits-Stunde einzeln zu benennen, denn jede Stunde kann einzeln verplant werden.
ok...
mich wundert, dass es kein datum gibt.
Weil es sich um eine zweitägige Veranstaltung handelt. Die Zeiteinheiten 1-19 sind definitiv am 21.6., die 20-33 am 22.6. Dazu gibt es eine weitere Tabelle mit Datum und Uhrzeiten zwecks leserlichem Druck im Terminplan.
naja, selbst dann würde ich es in zeiträume zusammen fassen. es bildet die realität besser ab, kunde a hat ein treffen mit firma b von dann bis dann. meiner meinung nach würde das programm dann auch leichter feststellen können, ob sich zeiträume überlagern. mit zahlen von 1-33 wird es schwieriger.
Der Gesprächs- und Eventwunsch steht ZUNÄCHST ohne Zeitangabe im Raum. Es ist Aufgabe des Programms, zwischen Besuchern und Ausstellern eine gemeinsame freie Zeiteinheit zu finden, bei Events sind noch max. Teilnehmerzahlen zu berücksichtigen. Bei Treffern wird die gefundene Stunde in den Wunschsatz eingefügt.
selbst wenn es sich um wünsche handelt, dann sollte man die beziehungen nicht aus den augen verlieren. wenn ich das richtig verstanden habe, dann gibt es zu jedem treffen eines users genau einen gesprächspartner und ein wunsch. das würde ich versuchen, alles in eine tabelle unterzubringen. und zwar handelt es sich da um die beziehungstabelle von events und adressen (du siehst wie fürchterlich der name adressen hier wirkt).
also ein adresse (kunde) kann an mehreren events teilnehmen. und ein event kann von mehreren adressen ausgewählt werden. das ist eine klassische n:m beziehung und muss durch eine weitere beziehungstabelle dargestellt werden. und in dieser beziehungstabelle steht dann der gesprächspartner (wunschpartner) und sein eventwunsch. da du die stunden aufteilst (nicht von bis) musst du diese auslagern, ansonsten würde sie auch genau da mit rein gehören. aber was nörgeln wir immer über das db design herum. meistens läßt es sich ja sowieso nicht ändern.
Welche Beziehung fehlen (nach dieser Erklärung) noch?
das problem hat doch der join schon aufgezeigt. user 11 hat nach deinem beispiel 3 stundeneinheiten ausgewählt. aber welcher gesprächspartner gehört zu welcher stunde und welcher wunsch ?
zurück zu deiner abfrage. da du weder UNION noch unterabfragen seinsetzen kannst (armer Hund, wie Vinzenz schon sagte), sieht es düster aus. ich muss darüber noch mal in ruhe nachdenken. das geht aber im moment nur teilweise, weil nun das "perfekte dinner" im fernsehen anfängt und meine freundin das immer sieht und mich da immer mit fragen und aussagen einbezieht.....
Ilja
-
Hi Ilja,
danke, dass du dich mit meinem Problem auseinandersetzt. Ich brauche wirklich das Gespräch mit Gleichgesinnten, bin schon voll betriebsblind in meinem LHO (Lonely Home Office).
Das System ist "im Rennen". Pferde (Konzepte) können jetzt nicht mehr ausgetauscht werden. Die Messe ist Mitte Juni, das System MUSS laufen. Trotzdem DANKE für konzeptionelle Anregungen, kann ich im nächsten Jahr gut gebrauchen.
ok, ich würde der tabelle trotzdem einen personenbezogenen namen geben, aber das ist geschmackssache.
Das habe ich auch, sprengt aber den Rahmen meiner Anfrage hier. Die alten Tabellennamen (aber identischer Aufbau) in mehreren Datenbanken unterscheiden sich und stehen in einem zweidimensionalen assoziativen PHP- Array:
$db = array (
array (
...
,'personen' => 'tm_adressen'
...
)
,
array (
...
,'personen' => 'bfp_adressen'
...
)
);In PHP spreche ich die ORIGINAL-Personentabelle an mit
".$db[0]['personen']." AS per1
die KOPIE mit
".$db[1]['personen']." AS per1aber das löst nicht mein Problem, sorry.
Weil es sich um eine zweitägige Veranstaltung handelt. Die Zeiteinheiten 1-19 sind definitiv am 21.6., die 20-33 am 22.6. Dazu gibt es eine weitere Tabelle mit Datum und Uhrzeiten zwecks leserlichem Druck im Terminplan.
naja, selbst dann würde ich es in zeiträume zusammen fassen. es bildet die realität besser ab, kunde a hat ein treffen mit firma b von dann bis dann. meiner meinung nach würde das programm dann auch leichter feststellen können, ob sich zeiträume überlagern. mit zahlen von 1-33 wird es schwieriger.
Das Pogramm plant die Paarungen, es darf in keinem Fall zu Überlagerungen kommen. Ein Besucher kann niemals gleichzeitig im Workshop sitzen und zu Mittag essen.
ZUM VERSTÄNDNIS:
Besucher und Aussteller melden sich rechtzeitig an, bekommen in Schritt 2 Fragebögen und kreuzen ihre Wünsche an (Gesprächspartner und Events).Jeder Wunsch erzeugt im System einen Datensatz und wird später auf Erfüllbarkeit überprüft.
Die kleinste Planungseinheit ist ein Slot (Zeiteinheit), vergleichbar mit dem Stundenplan in der Schule. Zwar ist z.B. ein Besucher IM STÜCK von Slot 2 bis Slot 19 (am ersten Tag) anwesend, kann aber in jedem Slot einen eigenständigen Gesprächstermin mit einem Aussteller (genau 1 Slot) haben ODER in einem Workshop (1 bis 2 Slots) sitzen ODER zu Mittag speisen (genau 2 Slots, auch als EVENT geführt).
Ja, auch das Mittagessen wird geplant, weil jedes der zwei Restaurants 350 Plätze bietet bei ca. 1200 Personen.
selbst wenn es sich um wünsche handelt, dann sollte man die beziehungen nicht aus den augen verlieren. wenn ich das richtig verstanden habe, dann gibt es zu jedem treffen eines users genau einen gesprächspartner und ein wunsch.
Der Wunsch, dass Besucher B_01 den Aussteller A_55 sprechen möchte, ergibt einen Eintrag in der Tabelle "kontakte", zunächst mit dem Slot=0, also noch KEINE Buchung, sondern ein Wunsch.
Der Wunsch, dass Besucher B_01 die Teilnahme am Event E_12 (Erdgas - die Alternative für den Fuhrpark), E_15 (Innovationen im Automobilbau) und E_01 (Mittagessen) wünscht, gibt entsprechende Einträge in der Tabelle "eventbuchungen" mit Slot=0.
Der Besucher B_01 kann weitere Wünsche haben. Im Extremfall sogar mehr, als seine Anwesenheit in Slots zulässt. Das Programm kann nur freie Slots zu Terminen machen.
das würde ich versuchen, alles in _eine tabelle_ unterzubringen. und zwar handelt es sich da um die beziehungstabelle von events und adressen (du siehst wie fürchterlich der name adressen hier wirkt).
Mmh, den Sinn kann ich nicht erkennen. Im Gegenteil: 2003 hatte ich noch Gesprächs- und Eventwünsche in einer Tabelle. Das war ein heilloses Durcheinander.
also ein adresse (kunde) kann an mehreren events teilnehmen. und ein event kann von mehreren adressen ausgewählt werden. das ist eine klassische n:m beziehung und muss durch eine weitere beziehungstabelle dargestellt werden.
GENAU. Das ist die Tabelle "eventbuchungen".
und in dieser beziehungstabelle steht dann der gesprächspartner (wunschpartner) und sein eventwunsch. da du die stunden aufteilst (nicht von bis) musst du diese auslagern, ansonsten würde sie auch genau da mit rein gehören. aber was nörgeln wir immer über das db design herum. meistens läßt es sich ja sowieso nicht ändern.
NICHT VERSTANDEN, was du meinst.
Die Gespräche zwischen Besuchern und Ausstellern sind eine 1:1 Beziehung. Also ganz anders als die Events. Auch hier noch Sonderformen (mehrere Aussteller-Mitarbeiter können gleichzeitig getrennte Gespräche führen und mehrere Besucher, die als Gruppe ein gemeinsames Gespräch mit einem Aussteller führen. Okay, also 1:n).Kalle
-
yo,
Das System ist "im Rennen". Pferde (Konzepte) können jetzt nicht mehr ausgetauscht werden. Die Messe ist Mitte Juni, das System MUSS laufen.
gut lassen wir am besten die ganze diskussion um das design der datenbank und konzentrieren uns mehr auf die abfragen, wobei sich natürlich die schwierigkeit mancher abfragen auf das design bezieht.
Die kleinste Planungseinheit ist ein Slot (Zeiteinheit), vergleichbar mit dem Stundenplan in der Schule.
jetzt wo du das thema schule anspricht, muss ich trotzdem noch mal auf das design der daten eingehen, weil zu meiner ausbildung wir genau dieses beispiel mit einem stundenplan entwickelt haben. es ist sehr mit deiner umgebung vergleichbar, klassen wären in deinem falle besucher, lehrer wohl aussteller (schade, dass man in der schule keine wunschlehrer angeben kann), bzw. events, zeiträume als Unterrichtsstunden (slots). auch dort gab es vorgaben, dass keine entität (klasse, lehrer oder raum) zur gleichen zeit (schulstunden und bei dir slots) zweimal eingetragen wurde. das kann man recht leicht über unique constraints lösen. wichtig ist aber vor allem, dass die entitäten klasse, lehrer, räume alle zusammen in -> einer <- beziehungstabelle miteinander verknüpft wurden, was letztlich nicht anderes als den unterichtsplan abgebildet hat.
und genauso könnte man deine umgebung ansehen, dann würde in einer tabelle alle termine abgebildet werden, was auch die abfragen erleichtert. auch unterschiedliche pausen könnten man dort festhalten.
Der Wunsch, dass Besucher B_01 den Aussteller A_55 sprechen möchte, ergibt einen Eintrag in der Tabelle "kontakte", zunächst mit dem Slot=0, also noch KEINE Buchung, sondern ein Wunsch.
ok, soweit kann ich folgen.
Der Wunsch, dass Besucher B_01 die Teilnahme am Event E_12 (Erdgas - die Alternative für den Fuhrpark), E_15 (Innovationen im Automobilbau) und E_01 (Mittagessen) wünscht, gibt entsprechende Einträge in der Tabelle "eventbuchungen" mit Slot=0.
ich verstehe, eventwünsche sind also keine wünsche eines besuchers mit einem gesprächparnter, sondern eigenständige termine. ich dachte zuerst, man sucht sich einen gesprächspartner aus und äußert dazu einem wunsch. dann braucht man natürlich auch keine beziehung zwischen gesprächspartner und eventwünsche, wie ich ursprünglich angenommen habe.
Der Besucher B_01 kann weitere Wünsche haben. Im Extremfall sogar mehr, als seine Anwesenheit in Slots zulässt. Das Programm kann nur freie Slots zu Terminen machen.
hört sich schwer danach an, der besucher kann erst mal alle wünsche äußern und dann sehen, welche treffen er bekommmen kann und dann erst seine zeit entsprechend plant.
Mmh, den Sinn kann ich nicht erkennen. Im Gegenteil: 2003 hatte ich noch Gesprächs- und Eventwünsche in einer Tabelle. Das war ein heilloses Durcheinander.
schwer zu beurteilen, woran das chaos gelegen hat. wie auch immer, ich habe jetzt deine umgebung besser verstanden, das dauert bei mir in aller regel im ein wenig länger. mein verstand arbeitet einfach langsamer, wie ein zug, der erst einmal auf touren kommen muss, aber dann schießt er oftmals über das ziel hinaus.... ;-)
und in dieser beziehungstabelle steht dann der gesprächspartner (wunschpartner) und sein eventwunsch. da du die stunden aufteilst (nicht von bis) musst du diese auslagern, ansonsten würde sie auch genau da mit rein gehören. aber was nörgeln wir immer über das db design herum. meistens läßt es sich ja sowieso nicht ändern.
NICHT VERSTANDEN, was du meinst.
einfach wieder verwerfen, ich bin da immer noch davon ausgegangen, dass für einen termin besucher, aussteller und event zusammen gehören. dies ist aber nicht der fall. ich erinnere mich wieder dunkel an dich, du bildest eine messe ab ?
Die Gespräche zwischen Besuchern und Ausstellern sind eine 1:1 Beziehung. Also ganz anders als die Events. Auch hier noch Sonderformen (mehrere Aussteller-Mitarbeiter können gleichzeitig getrennte Gespräche führen und mehrere Besucher, die als Gruppe ein gemeinsames Gespräch mit einem Aussteller führen. Okay, also 1:n).
nein, sowohl zwischen [besucher und aussteller] und [besucher und events] sind beides n:m beziehungen. ein besucher kann mehrere aussteller sprechen wollen und ein aussteller kann mehrere besucher haben. genauso verhält es sich mit den events. dass ein besucher nur einen aussteller und ein event zur gleichen zeit besuchen kann, das ist ein anderes thema, es bleibt aber eine n:m beziehung, die du abbilden musst. gerade wenn es sich um wünsche der besucher handelt, da du ja gesagt hast, dass diese sich zeitlich auch erst einmal überlappen können.
ich habe mir noch mal deine beispieldatensätze mit alfred meyer angeschaut und verstehe deine situation nun besser. ich habe immer zwischen beziehungen gesucht, zu welchen slot (stunde) er denn nun das event besucht oder den wunschpartner sprechen will. wenn ich das aber richtig verstehe, dann hälst du in der einen tabelle fest, wann er da ist und in den anderen beiden welchen aussteller, bzw. event er besuchen will, wobei noch offen ist, wann genau er das in seiner zeit, die ihm zur verfügung steht, macht. puhh langer satz....
ok, wovon ich immer spreche, ich halt der terminplan, der in einer tabelle abgebildet wird, quasi das ergebnis, dass bei all den besuchern, ausssteller und events durch dein programm errechnet werden soll. was du aber erst einmal abbilden willst, ist der zustand, um überhaupt erst enmal den terminplan entwickeln zu können. ich bin manchmal wirklich schwer von begriff.
genug der langen vorrede, das problem ist, dass es bei deinem JOIN trotzdem zu den angesprochenen problemen in meinem ersten posting kommt, weil eben die tabellen nicht miteinander in beziehung stehen. sie geben zwar an, welcher besucher welche events oder aussteller sprechen will, läßt aber den zeitpunkt offen. durch diese fehlende verbindung der zeit, ordnet der join quasi zu jedem slot, den der besucher angibt, alle events und ausstellerbesuche zu. da versteckt sich deine potenzierung.
wie löst man das problem nun ? UNION wäre eine lösung, wird aber durch die version deines dbms ausgeschlossen. ausserdem würde der UNION operator die einzelnen informationen auch in mehreren datensätze liefern und du willst es ja in einem abbilden. unterabfragen wäre da die erste wahl, aber diese gehen auch nicht. ärgerlich, aber vielleicht kann man tricksen.
wir müssen den JOIN wagen und die besagte potenzierung rausbekommen. eventuell kann uns dabei der DISTINCT Operator hilfreich sein. das funktioniert aber nur, wenn ein besucher, nicht mehr als einmal den gleichen zeitslot, aussteller oder eventwunsch äußern kann.
SELECT tab1.adress_id,
COUNT(DISTINCT tab1.stunde) AS 'Stunden',
COUNT(DISTINCT tab2.aussteller_id) AS 'Aussteller',
COUNT(DISTINCT tab3.event_id) AS 'Events'
FROM anwesenheit AS tab1, gespraechsparnter AS tab2, eventwuensche AS tab3
AND tab1.adress_id = tab2.besucher_id
AND tab1.adress_id = tab1.adress_id
GROUP BY tab1.adress_id
ORDER BY 1du kannst in der WHERE klausel den besucher auf id 11 einschränken, wenn es gewünscht ist und dir das GROUP BGY und ORDER BY sparen. ich habe erst mal alle besucher ins boot genommen. schau mal, was dabei raus kommt.
Ilja
-
yo,
du kannst in der WHERE klausel den besucher auf id 11 einschränken, wenn es gewünscht ist und dir das GROUP BGY und ORDER BY sparen.
natürlich nur das ORDER BY sparen und nicht auch noch das GROUP BY.....
Ilja
-
Hallo, Ilja,
erst einmal herzlichen Dank, dass du sich sooo intensiv mit meiner Lösung beschäftigt hast.
War jetzt ein paar Tage auf einer anderen "Baustelle", deshalb die späte Reaktion.
SELECT tab1.adress_id,
COUNT(DISTINCT tab1.stunde) AS 'Stunden',
COUNT(DISTINCT tab2.aussteller_id) AS 'Aussteller',
COUNT(DISTINCT tab3.event_id) AS 'Events'
FROM anwesenheit AS tab1, gespraechsparnter AS tab2, eventwuensche AS tab3
AND tab1.adress_id = tab2.besucher_id
AND tab1.adress_id = tab1.adress_id
GROUP BY tab1.adress_id
ORDER BY 1Mein Freund ist DISTINCT.
Dein Engagement ist mit jetzt ein Essen wert. Wohnst du vielleicht zufällig in der Gegend Darmstadt - Heidelberg?
Kalle
-
yo,
Dein Engagement ist mit jetzt ein Essen wert. Wohnst du vielleicht zufällig in der Gegend Darmstadt - Heidelberg?
nun ja, lebe in berlin und trinke pils.....
Ilja
-
yo,
Dein Engagement ist mit jetzt ein Essen wert. Wohnst du vielleicht zufällig in der Gegend Darmstadt - Heidelberg?
nun ja, lebe in berlin und trinke pils.....
Hmm, mal sehen was sich machen lässt. Maile mir bitte
- Stadtteil
- Strasse, Hausnr.
- Name
Kalle
-
yo,
Dein Engagement ist mit jetzt ein Essen wert. Wohnst du vielleicht zufällig in der Gegend Darmstadt - Heidelberg?
nun ja, lebe in berlin und trinke pils.....
Hmm, mal sehen was sich machen lässt. Maile mir bitte
- Stadtteil
- Strasse, Hausnr.
- Name
und natürlich deine Pilssorte (dass ich das vergessen konnte)
Kalle
-
yo,
vielen dank für das angebot, wenn wir beide in einer stadt wohnen würden, hätte ich es auch angenommen. vielleicht ja mal irgendwann, wenn du in berlin bist...
Ilja
-
yo,
vielen dank für das angebot, wenn wir beide in einer stadt wohnen würden, hätte ich es auch angenommen. vielleicht ja mal irgendwann, wenn du in berlin bist...
Hey, nicht so schnell aufgeben. Wofür habe ich Kumpels? Einer sitzt in Neukölln. Echter Bierkenner. Würde nie auf die Idee kommen, dir einen Weinfreund vorbeizuschicken.
Kalle
-
-
-
-
-
-
-
-