Philosophieproblem zum Thema "Verschieben"

[Tom]

Hello,

ich habe eine Liste (Tabelle).
Diese enthält einen lexikalischen Index (Unique).

1
1.1
1.2
1.2.4
1.2.4.3
????
2
2.2.7.8
4.2
4.13.10.1
4.14
4.14.1.2
4.14.2

Dieser kann, weil Beiträge abgelaufen oder sonstwie gelöscht sind, auch Lücken enthalten. Er enthält jedoch _keine__Doubletten_.

Wenn man jetzt einen ganzen Baum verschieben wollte unter einen anderen Punkt, wie müsste man dann vorgehen?

Angenommen, ich wollte jetzt den Punkt 1.2.4 nebst ggf. vorhandener Unterpunkte komplett verschieben wollen nach 4.2, wie würdet Ihr das machen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Angenommen, ich wollte jetzt den Punkt 1.2.4 nebst ggf. vorhandener Unterpunkte komplett verschieben wollen nach 4.2, wie würdet Ihr das machen?

Ich würde das so machen:

Auslesen -> 1.2 durch 4.2 ersetzen -> Abspeichern
Allerdings solltest du vorher sicherstellen, das du keinen vorhandenen Index überschreibst, denn nachträglich wirst du nichts mehr trennen können.

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Wenn man jetzt einen ganzen Baum verschieben wollte unter einen anderen Punkt, wie müsste man dann vorgehen?

Angenommen, ich wollte jetzt den Punkt 1.2.4 nebst ggf. vorhandener Unterpunkte komplett verschieben wollen nach 4.2, wie würdet Ihr das machen?

Das kommt ja darauf an, wie du das bisher umgesetzt hast.

Wenn jeder Punkt seine eigene ID hätte und die Nummerierung automatisch erfolgt, wäre jeder Punkt eindeutig zugeordnet durch Elternelement und die Angabe, das wievielte Kind seiner Eltern er ist.

Also bisher

ID 1    (Punkt 1), Elter: 0, Position: 1
ID 17   (Punkt 4), Elter: 0, Position: 4
ID 42   (Punkt 1.2), Elter: 1, Position: 2
ID 4242 (Punkt 1.2.4), Elter: 42, Postion: 4

neu
ID 4242 Elter: 17, Position: 2

Wenn du für die Position reelle Zahlen nähmest, könntest du beim Dazwischenschieben einfach das arithmetische Mittel der Nachbarn nehmen.

Matthias

[Tom]

Hello Matthias,

Wenn man jetzt einen ganzen Baum verschieben wollte unter einen anderen Punkt, wie müsste man dann vorgehen?

Angenommen, ich wollte jetzt den Punkt 1.2.4 nebst ggf. vorhandener Unterpunkte komplett verschieben wollen nach 4.2, wie würdet Ihr das machen?

Das kommt ja darauf an, wie du das bisher umgesetzt hast.

Wenn jeder Punkt seine eigene ID hätte und die Nummerierung automatisch erfolgt, wäre jeder Punkt eindeutig zugeordnet durch Elternelement und die Angabe, das wievielte Kind seiner Eltern er ist.

Also bisher

ID 1    (Punkt 1), Elter: 0, Position: 1
ID 17   (Punkt 4), Elter: 0, Position: 4
ID 42   (Punkt 1.2), Elter: 1, Position: 2
ID 4242 (Punkt 1.2.4), Elter: 42, Postion: 4

neu
ID 4242 Elter: 17, Position: 2

Wenn du für die Position reelle Zahlen nähmest, könntest du beim Dazwischenschieben einfach das arithmetische Mittel der Nachbarn nehmen.

Ja, das wäre eine Idee.

Ich habe jetzt hier mal die Variante "Unterordnung" skizziert.

  
  
Verschiebe komplett 1.2.4 nach 4.2  
vorher:  
  
1  
1\.1  
1\.2  
1\.2.4    >--------+  
1\.2.4.3  >------+ |  
????     >----+ | |  
2             | | |  
2\.2.7.8       | | |  
4\.2           | | |  
4\.2.3         | | |  
4\.13.10.1     | | |  
4\.14          | | |  
4\.14.1.2      | | |  
4\.14.2        | | |  
              | | |  
              | | |  
nachher:      | | |  
              | | |  
1             | | |  
1\.1           | | |  
1\.2           | | |  
2             | | |  
2\.2.7.8       | | |  
4\.2.1    <----|-|-+  
4\.2.1.3  <----|-+  
????     <----+  
4\.2.3  
4\.13.10.1  
4\.14  
4\.14.1.2  
4\.14.2  
  

Die hat die Lücke genutzt...

Um 1.2.4 ff auf 4.2 einzufügen postuliere ich mal. Bitte auf logische Fehler prüfen.

Dazu muss man dann wohl auf die Lücke hoffen.
Anderenfalls müsste der vorher dort befindliche Teilbaum auch verschoben werden.

Dazu müssten alle Elemente des Teilbaums um (mindestens) 1 hochgeschoben werden.

Wenn also 4.2 schon belegt ist, müsste aus

4.2.x -> 4.3.x werden
4.3.x -> 4.4.x usw.

solange 4.x.x vorhanden sind.

Ich versuche, diese Funktionen alle als Stored Routines/Procedures abzubilden.

Das Index-Feld ist in Wirklichkeit ein Binärer Index (2 Bytes pro Stufe), daher leicht sortierbar. Die "gepunktete Dezimaldarstellung" dient hier nur unserem Verständnis.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[T-Rex]

Wie schon Matthias sagte, kommt es natürlich drauf an wie du es bis jetzt umgesetzt hast.

Ich hätte erstmal eine Tabelle gemacht wo jeder Punkt als Datensatz abgespeichert ist. Zudem hat jeder Datensatz noch eine Verbindung zu seinem Elternelement, da es nur ein direktes Elternelement geben kann.

Ergo würde es so aussehen:
ID | NR | LINK_ID
1 | 1 | NULL
2 | 1.1 | 1
3 | 1.2 | 1
4 | 1.2.4 | 3

etc...

somit müsstes du nur die LINK_ID ändern.

Gruß
1 | T-Rex | Vater

[Matthias Apsel]

Om nah hoo pez nyeetz, T-Rex!

Ich hätte erstmal eine Tabelle gemacht wo jeder Punkt als Datensatz abgespeichert ist. Zudem hat jeder Datensatz noch eine Verbindung zu seinem Elternelement, da es nur ein direktes Elternelement geben kann.

somit müsstes du nur die LINK_ID ändern.

Ja, das ist ja dasselbe, was ich schrieb. Die Bezeichnung der konkreten Nummerierung hat in der DB nichts verloren. Sie ergibt sich aus parent und nth-child.

Matthias

[Linuchs]

Zudem hat jeder Datensatz noch eine Verbindung zu seinem Elternelement, da es nur ein direktes Elternelement geben kann.

Hangt von der Anwendung ab. Wenn die Texte als Bausteine in mehreren Kapiteln oder verschiedenen Dokumenten vorkommen (ich habe so eine Anwendung) sollte man vielleicht zwei Tabellen haben, eine für die Textbausteine und eine für die Struktur.

Linuchs

[Tom]

Hello,

Zudem hat jeder Datensatz noch eine Verbindung zu seinem Elternelement, da es nur ein direktes Elternelement geben kann.

Hangt von der Anwendung ab. Wenn die Texte als Bausteine in mehreren Kapiteln oder verschiedenen Dokumenten vorkommen (ich habe so eine Anwendung) sollte man vielleicht zwei Tabellen haben, eine für die Textbausteine und eine für die Struktur.

Hab ich doch. Dies ist nur die Struktur.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello T-Rex,

Wie schon Matthias sagte, kommt es natürlich drauf an wie du es bis jetzt umgesetzt hast.

Ich hätte erstmal eine Tabelle gemacht wo jeder Punkt als Datensatz abgespeichert ist. Zudem hat jeder Datensatz noch eine Verbindung zu seinem Elternelement, da es nur ein direktes Elternelement geben kann.

Ergo würde es so aussehen:
ID | NR | LINK_ID
1 | 1 | NULL
2 | 1.1 | 1
3 | 1.2 | 1
4 | 1.2.4 | 3

somit müsstes du nur die LINK_ID ändern.

Ich müsste auch in allen bisherigen Children die Link-ID zum (neuen) Parent ändern.

Verschieben ist leider doppelt so schlimm, wie Einfügen, denn es ist Einfügen an neuer Position und Löschen an der alten. Das gibt mindestens vier Stellen zum Ändern.

Ich habe hier nun mal einen anderen Weg ausprobiert, bzw. bin noch dabei. Das Verschieben macht mir aber wieder einen Denkknoten...

Die Aufgabe soll also ausschließlich durch Änderungen im Index-Feld (hier als gepunktete Dezimalform dargestellt) stattfinden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tobias Hahner]

Hallihallo!

Für mich sieht das Konstrukt gewaltig nach einer Anwendung für das nested sets Modell aus.
Selbst, wenn Deine bisherige Arbeit das so nicht vorgesehen hatte, lässt es sich ja relativ einfach nachrüsten, indem Du die Zuordnungen einfach in einer Extratabelle auslagerst und mit der Payload-Tabelle verknüpfst.

Ich hatte vor einer gefühlten Ewigkeit mal ein paar Funktionen gebastelt, mit deren Hilfe ich problemlos einzelne Äste ausschneiden und einfügen konnte. Hier mal der entsprechende Auszug aus meinem Testskript (Vorsicht: in meinem Test ist nur die reine Funktionalität abgebildet, um das Escaping müsste man sich noch kümmern. Ausserdem wird noch die Mysql- Version genutzt, mysqli hatte ich da noch nicht zur Verfügung...)

  
// Für die bessere Lesbarkeit der eigentlichen Funktionalität sind die MySQL- Zugriffsfunktionen hier stark abgekürzt:  
  
function g($r) {  
                // g wie "get"  
		return mysql_fetch_assoc($r);  
	}  
  
function m($q) {  
                // m wie "mysql_query"  
		return mysql_query($q);  
	}  
  
function AddToBranch($was,$worin) {  
                // hängt ein Blatt an einen Ast an  
		$q = "SELECT * FROM settest WHERE name='$worin';";  
		$r = m($q);  
		$s = g($r);	// s['id'], s['name'], ...  
		//echo '<pre>'; var_dump($s); echo '</pre>';  
		  
		$LFT = $s['lft']; $RGT = $s['rgt'];  
		$q = "UPDATE settest SET rgt=rgt+2 WHERE rgt>=$RGT;";  
		$r = m($q);  
		  
		$q = "UPDATE settest SET lft=lft+2 WHERE lft>$RGT;";  
		$r = m($q);  
		  
		$lft = $RGT; $rgt = $RGT+1;  
		$q = 'INSERT INTO settest (name,lft,rgt) VALUES (\''.$was.'\','.$lft.','.$rgt.');';  
		$r = m($q);  
		//echo mysql_insert_id();  
	}  
  
function InsertBefore($was, $wovor) {  
		$q = "SELECT * FROM settest WHERE name='$wovor';";  
		$r = m($q);  
		$s = g($r);  
		$LFT = $s['lft']; $RGT = $LFT+1;  
		  
		$q = "UPDATE settest SET lft=lft+2 WHERE lft>=$LFT;";  
		$r = m($q);  
		  
		$q = "UPDATE settest SET rgt=rgt+2 WHERE rgt>=$LFT;";  
		$r = m($q);  
		  
		$q = "INSERT INTO settest (name,lft,rgt) VALUES ('$was',$LFT,$RGT);";  
		$r = m($q);  
	}  
	  
	function DeleteItem($was) {  
		// lft und rgt ermitteln  
		$q = 'SELECT lft,rgt FROM settest WHERE name=\''.$was.'\';';  
		$s = g(m($q));  
		$LFT = $s['lft']; $RGT = $s['rgt'];  
		$q = "DELETE FROM settest WHERE lft BETWEEN $LFT AND $RGT;";  
		$r = m($q);  
		$minus = $RGT-$LFT+1;  
		$q = "UPDATE settest SET lft=lft-$minus WHERE lft>$RGT;";  
		$r = m($q);  
		$q = "UPDATE settest SET rgt=rgt-$minus WHERE rgt>$RGT;";  
		$r = m($q);  
	}  
	  
	function AppendItem ($was,$wohin) {  
		// hängt ein bereits bestehendes Item (Blatt oder Ast) an ein anderes (auch Blatt oder Ast) an  
		// und löscht es von seiner ursprünglichen Position  
		  
		// lft und rgt vom zu verschiebenden Element holen  
		$r=m("SELECT lft,rgt FROM settest WHERE name='$was';");  
		$set=g($r); $BaumLft=$set['lft']; $BaumRgt=$set['rgt'];  
		  
		// GRösse des zu verschiebenden Elements  
		$gr=$BaumRgt-$BaumLft+1;  
		  
		// lft und rgt vom Zielelement holen  
		$r=m("SELECT lft,rgt FROM settest WHERE name='$wohin';");  
		$set=g($r); $TargetLft=$set['lft']; $TargetRgt=$set['rgt'];  
		  
		// im Zielelement Platz schaffen  
		m("UPDATE settest SET lft=lft+$gr WHERE lft>=$TargetRgt;");  
		m("UPDATE settest SET rgt=rgt+$gr WHERE rgt>=$TargetRgt;");  
		  
		// Korrektur für den Fall, dass der Baum an eine Position VOR seiner alten verschoben wird. Dann ist nämlich der Baum selbst beim Lückeschaffen betroffen gewesen  
		if (($BaumLft > $TargetLft)&&($BaumRgt > $TargetRgt)) {  
			$BaumLft = $BaumLft+$gr; $BaumRgt = $BaumRgt+$gr;  
		}  
		  
		// Element an seine neue Position verschieben  
		m("UPDATE settest SET lft=$TargetRgt+lft-$BaumLft, rgt=$TargetRgt+rgt-$BaumLft WHERE lft BETWEEN $BaumLft AND $BaumRgt;");  
		  
		// entstandene Lücke wieder schliessen  
		m("UPDATE settest SET lft=lft-$gr WHERE lft>$BaumLft;");  
		m("UPDATE settest SET rgt=rgt-$gr WHERE rgt>$BaumRgt;");  
	}  
	  
	function MoveItemBefore($was, $wohin) {  
		// verschiebt ein Blatt oder einen Ast von seiner ursprünglichen Position VOR das Target  
		  
		// lft und rgt vom zu verschiebenden Baum bestimmen  
		$r=m("SELECT lft,rgt FROM settest WHERE name='$was';");  
		$set=g($r); $BaumLft=$set['lft']; $BaumRgt=$set['rgt'];  
		// lft und rgt vom Target bestimmen  
		$r=m("SELECT lft,rgt FROM settest WHERE name='$wohin';");  
		$set=g($r); $TargetLft=$set['lft']; $TargetRgt=$set['rgt'];  
		//Grösse des Baums bestimmen  
		$gr=$BaumRgt-$BaumLft+1;  
		// vor dem Target eine Lücke schaffen:  
		m("UPDATE settest SET lft=lft+$gr WHERE lft>=$TargetLft;");  
		m("UPDATE settest SET rgt=rgt+$gr WHERE rgt>=$TargetLft;");  
		  
		// Korrektur für den Fall, dass der Baum an eine Position VOR seiner alten verschoben wird. Dann ist nämlich der Baum selbst beim Lückeschaffen betroffen gewesen  
		if ($BaumLft > $TargetLft) {  
			$BaumLft = $BaumLft+$gr; $BaumRgt = $BaumRgt+$gr;  
		}  
		  
		// den zu verschiebenden Baum an seine neue jetzt freie Position verschieben  
		m("UPDATE settest SET lft=$TargetLft+lft-$BaumLft, rgt=$TargetLft+rgt-$BaumLft WHERE lft BETWEEN $BaumLft AND $BaumRgt;");  
		// die entstandene Lücke an der ursprünglichen Position des Baums wieder schliessen  
		m("UPDATE settest SET lft=lft-$gr WHERE lft>$BaumLft;");  
		m("UPDATE settest SET rgt=rgt-$gr WHERE rgt>$BaumRgt;");  
		// das sollte es gewesen sein.  
	}  

Vielleicht kannst Du damit ja was anfangen. Falls nicht, bitte einfach ignorieren ;-)

Beste Grüsse,
    Tobias Hahner

[Tom]

Hello Tobias,

Für mich sieht das Konstrukt gewaltig nach einer Anwendung für das nested sets Modell aus.

Das ist auf jeden fall eine Alternative.

Und das "normale" hierarchische Modell mit Parent und Children in der Datenbank habe ich auch schon durch.

Das Problem, sowohl bei nested Sets, als auch beim klassischen hierarchischen Modell ist immer die Sperrung der Tabelle während der Änderungen, da man immer mehrere Statements benötigt, um den gesamten Vorgang abzuschließen.

Ich möchte hier (für mich) mal Vor- und Nachteile gegeneinander abwägen.
In meinem "Very-Long-Index-Modell" fehlt dazu nur noch das Verschieben.

Wobei ich denke, dass es in den beiden anderen Modellen auch Probleme mit der Anzeigereihenfolge gibt, wenn ein Parent mehrere Children hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Das Problem, sowohl bei nested Sets, als auch beim klassischen hierarchischen Modell ist immer die Sperrung der Tabelle während der Änderungen, da man immer mehrere Statements benötigt, um den gesamten Vorgang abzuschließen.

So, wie ich das vorgeschlagen habe, benötigst du für das Verschieben eines beliebig langen Teilbaumes genau eine Änderung. Der Teilbaum muss ein anderes Elternelement bekommen.

Matthias

[Tom]

Hello,

Om nah hoo pez nyeetz, Tom!

Das Problem, sowohl bei nested Sets, als auch beim klassischen hierarchischen Modell ist immer die Sperrung der Tabelle während der Änderungen, da man immer mehrere Statements benötigt, um den gesamten Vorgang abzuschließen.

So, wie ich das vorgeschlagen habe, benötigst du für das Verschieben eines beliebig langen Teilbaumes genau eine Änderung. Der Teilbaum muss ein anderes Elternelement bekommen.

Und wo landet der dann, wenn das Elternelement schon Kinder hatte?
Da muss ja geregelt bleiben, an welcher Position die Kinder in der Subliste erscheinen sollen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Das Problem, sowohl bei nested Sets, als auch beim klassischen hierarchischen Modell ist immer die Sperrung der Tabelle während der Änderungen, da man immer mehrere Statements benötigt, um den gesamten Vorgang abzuschließen.

So, wie ich das vorgeschlagen habe, benötigst du für das Verschieben eines beliebig langen Teilbaumes genau eine Änderung. Der Teilbaum muss ein anderes Elternelement bekommen.

Und wo landet der dann, wenn das Elternelement schon Kinder hatte?
Da muss ja geregelt bleiben, an welcher Position die Kinder in der Subliste erscheinen sollen.

Wenn die Reihenfolge nicht wichtig ist, gilt die, in der sie von Datenbank ausgespuckt werden.
Anderenfalls musst du noch die Position festlegen. Siehe meine erste Antwort.

Matthias

[Tom]

Hello Matthias,

Und wo landet der dann, wenn das Elternelement schon Kinder hatte?
Da muss ja geregelt bleiben, an welcher Position die Kinder in der Subliste erscheinen sollen.

Wenn die Reihenfolge nicht wichtig ist, gilt die, in der sie von Datenbank ausgespuckt werden.
Anderenfalls musst du noch die Position festlegen. Siehe meine erste Antwort.

Dann habe ich also nichts verkehrt verstanden.
Ich hatte ja schon mal so ein System gebaut und da gab es immer noch eine Spalte "Position". Und wenn es kollisionen gab, musste man auch vorher alle Kinder verschieben.

Ich will es ja nun mal mit dem VLI versuchen.
Es läuft ja auch schon alles recht gut und die Geschwindigkeitsvorteile beim Lesen, Filtern usw. wind einfach gut. Und auch zum Einfügen benötigt man, wenn nicht verschoben werden muss, nur ein simples Statement. Da muss man also nicht tiefer über TOCTTOU oder Transactions nachdenken.

Ob sowas für die Praxis taugt, will ich ja gerade herausfindne. Aber bisher sieht es sehr nach "KISS" aus. Das gefällt mir.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Dann habe ich also nichts verkehrt verstanden.
Ich hatte ja schon mal so ein System gebaut und da gab es immer noch eine Spalte "Position". Und wenn es kollisionen gab, musste man auch vorher alle Kinder verschieben.

Das lässt sich vermeiden, wenn position kein integer ist.

Matthias

[Tom]

Hello Matthias,

Das lässt sich vermeiden, wenn position kein integer ist.

*Grübel*

Das ist ja mein VLI im Prinzip auch nicht, denn der wird auch nach varbinary-String sortiert.

Da das nirgends angezeigt wird und parallel eine konsistente ID mitgeführt wird (die wird NIE NIEMALS geändert), könnte ich ja auch einfach den direkt dafür verwenden.

Aber dann bleibt immer noch die Einrückungstiefe. Diese Information muss auch irgendwoher kommen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Das Problem, sowohl bei nested Sets, als auch beim klassischen hierarchischen Modell ist immer die Sperrung der Tabelle während der Änderungen, da man immer mehrere Statements benötigt, um den gesamten Vorgang abzuschließen.

Mit PDOs Transaktionen kann man das elegant lösen.

[Whouzuo]

Hello,

ich habe

...eine falsche Überschrift gewählt. Du hast kein Philosophie-Problem. ;)

Dieser kann, weil Beiträge abgelaufen oder sonstwie gelöscht sind, auch Lücken enthalten. Er enthält jedoch _keine__Doubletten_.

Besser hervorheben geht so: "_keine Doubletten_".

Angenommen, ich wollte jetzt den Punkt 1.2.4 nebst ggf. vorhandener Unterpunkte komplett verschieben wollen nach 4.2, wie würdet Ihr das machen?

*ontopic switch* So wie die anderen geschrieben haben: jeder Eintrag hat einen Link zu seinem Parent. Nur das ermöglicht eine saubere Abbildung in einer mit Relationen arbeitenden Datenbank.

[Tom]

Hello,

ich habe

...eine falsche Überschrift gewählt. Du hast kein Philosophie-Problem. ;)

Dieser kann, weil Beiträge abgelaufen oder sonstwie gelöscht sind, auch Lücken enthalten. Er enthält jedoch _keine__Doubletten_.

Besser hervorheben geht so: "_keine Doubletten_".

Wer sagt das außer Dir?

Angenommen, ich wollte jetzt den Punkt 1.2.4 nebst ggf. vorhandener Unterpunkte komplett verschieben wollen nach 4.2, wie würdet Ihr das machen?

*ontopic switch* So wie die anderen geschrieben haben: jeder Eintrag hat einen Link zu seinem Parent. Nur das ermöglicht eine saubere Abbildung in einer mit Relationen arbeitenden Datenbank.

In einer _Datenbank_ vielleicht schon.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Whouzuo]

Hello,

ich habe

...eine falsche Überschrift gewählt. Du hast kein Philosophie-Problem. ;)

Dieser kann, weil Beiträge abgelaufen oder sonstwie gelöscht sind, auch Lücken enthalten. Er enthält jedoch _keine__Doubletten_.

Besser hervorheben geht so: "_keine Doubletten_".

Wer sagt das außer Dir?

Die Tatsache, dass das eigentlich alle so machen. Wenn du _wirklich_ beide Worte _einzeln_ hervorheben willst (was aber in diesem Fall imho nicht wirklich sinnig ist), dann so:"_keine_ _Doubletten_"

[M.]

Mahlzeit,

Die Tatsache, dass das eigentlich alle so machen.

Ich nicht. Definiere "alle".

[Whouzuo]

Mahlzeit,

Die Tatsache, dass das eigentlich alle so machen.

Ich nicht. Definiere "alle".

Alle Wichtigen. ;)

[M.]

Mahlzeit,

Alle Wichtigen. ;)

Du findest das witzig, oder?

[Whouzuo]

Mahlzeit,

Alle Wichtigen. ;)

Du findest das witzig, oder?

Genauso wenig witzig ich wie ich dein "definiere alle" finde. Es war doch wohl klar, was ich gemeint habe: mein subjektiver Eindruck ist, dass so ziemlich jeder auf die Art hervorhebt, wie ich sie beschrieben habe. Wenn hier jemand das anders sieht - bitte. Ich werde jetzt sicher keine Studien dafür bemühen...

[M.]

Mahlzeit,

Genauso wenig witzig ich wie ich dein "definiere alle" finde.

Das sollte auch nicht witzig sein sondern ein ganz einfasch Frage. Die hast du aber nicht beantwortet.

Es war doch wohl klar, was ich gemeint habe:

Nein. Oder glaubst du ich frage nach, wenn es klar wäre?

mein subjektiver Eindruck ist, dass so ziemlich jeder auf die Art hervorhebt, wie ich sie beschrieben habe.

Dann hast du eine gestörte Wahrnehmung.