[Wikide-l] Re: mediawiki-bausteine als navigationselemente

So Feb 29 11:43:18 UTC 2004

Am Sonntag, 29. Februar 2004 06:16 schrieb Timwi:
> Ivo Köthnig wrote:
> > Da sieht man, dass du selten Artikel schreibst.
>
> Bitte versuche doch, dir solche herablassenden Kommentare zu sparen. Ich
> versuche hier, faktisch zur Diskussion beizutragen, und nicht die
> anderen Kinder zum Weinen zu bringen. ;-)

Wer weint denn hier? :-))

> >>>Abgesehen davon muss so ein Feature auch so
> >>>implementiert sein, dass der alte Name eine Weile gesperrt ist, damit
> >>> ihn sich niemand aneignet, während alle anderen noch realisieren
> >>> müssen, dass Coma nun ein Dorftrottel ist...
> >>
> >>Das ist ja wohl auch trivial, in dem man den alten Benutzernamen einfach
> >>als neuen Account registriert und dann nicht verwendet.
> >
> > Sag mal will du mich nicht verstehen oder bist du dazu unfähig?
>
> Bitte beruhige dich etwas. Ich bin sicher nicht unfähig, aber vielleicht
> drückst du dich nicht klar genug aus. Du wolltest doch, daß der alte
> Benutzername unbenutzbar wird? Also leg einfach einen unbenutzbaren
> Account unter diesem Namen an. Was ist daran falsch?

Das Problem ist: Jemand will seinen Account-Namen ändern und alle Signaturen 
und jedes andere Vorkommen seines Namens sollen sich mitändern! Ich glaube 
ausser Dir ist das jedem hier klar geworden.

Du fällst ständig in einen Rechtfertigungsmodus zurück, indem du nicht dieses 
Problem vor Augen hast, sondern nur ein Teilproblem und präsentierst eine 
völlig unzureichende Lösung...

> >>Wenn es zu einfach ist, seinen Benutzernamen zu ändern, dann machen die
> >>Leute das ständig. Es ist wichtig, Benutzernamen mit Personen (bzw.
> >>Persönlichkeiten) verbinden zu können, aber wenn die Benutzernamen sich
> >>ständig ändern, geht das nicht mehr. Man weiß dann vorne und hinten
> >>nicht mehr, wer wer ist.
> >
> > Genau deshalb habe ich ja auch gesagt, dass der alte Account einen Monat
> > lang gesperrt bleiben soll. Das kann man ja auch leicht dahingehend
> > ausbauen, dass der neue mindestens einen Monat bestand haben muss...
>
> Selbst bei nur einem neuen Namen pro Benutzer pro Monat gäbe es
> immernoch ein heiloses Durcheinander. Bei mehr als 30 Benutzern wäre das
> schließlich mehr als eine Namensänderung pro Tag.

Dann sind es halt 2 Monate und beim nächsten mal muss man ein halbes Jahr 
warten. Ist deine Fanatsie so begrenzt, dass du jetzt den Zeitraum in Frage 
stellen musst. Du solltest Wissen dass man Software an der Stelle leicht 
anpassen kann.

> Ich habe eins davon gesehen (http://meta.wikipedia.org/wiki/Wikitax),
> bin davon aber wirklich nicht sonderlich vom Hocker gerissen. Was ist so
> sonderlich anders, wenn man statt ''...'' halt [/.../] benutzt. Kommt
> aufs Gleiche raus. Die vorgeschlagene Syntax zum Einrücken ist Overkill
> (wer muß schon rechts einrücken) und komplizierter als einfach ':'.

Es benutzt immer die gleiche Klammerung. Das ist leichter erlernbar. Jeder der 
eckige Klammern sieht, weis genau, da ist etwas ausgezeichnet. Bei unserer 
Syntax muss man das ganze Markup kennen... Abgesehen davon kann das die 
Software aus dem gleichen Grund leichter parsen.

> Davon abgesehen, hast du meine Frage nicht beantwortet. Was ist denn
> jetzt an unserer momentanen Syntax uneinheitlich?

Zum Beispiel die Verwendung von {{}} solchen Klammern für den Media-Wiki 
bezug. Zum Beispiel die Verwendung von ~~~~ für Signatur. Zum Beispiel 
<nowiki></nowiki> (ich dachte wir wollen kein XML). Genauso <math> und 
</math>. Und dann natürlich noch '',''',==,=== usw.

Da ist überhaupt nichts einheitlich. Das ist ein sammelsurium von "Das 
brauchen wir grade", lasst es uns einfach mal so machen, egal ob es ins 
bisherige Schema passt.

> Aha. Du gibst also selbst zu, daß es zwei Möglichkeiten gibt:
> (1) Die Syntax ist prima maschinell parsebar. Warum dann eine neue
>      einführen?
> (2) Die Syntax ist nicht maschinell parsebar. Dann würde eine Umstellung
>      also einen Teil der Artikel vorübergehend unleserlich machen und
>      unnötigen Arbeitsaufwand verursachen.

Schon wieder das Rechtfertigungsschema: Ich habe die Antwort auf (1) doch 
schon längst gegeben. Das war ja der Grund für diese Teildiskussion.

Und warum man den 2. Fall erst recht beheben sollte ist doch wohl auch klar. 
Oder willst Du eine Software haben, die ständig undefinierte Sachen 
produziert.

> > Am Ende landen wir sowieso bei etwas, was ähnlich zu XML ist
> > und wir werden nur noch logisch formatieren...
>
> Hm, da bin ich mal gespannt. :-) Bis dahin mache ich mal lieber mit der
> einfachen und schnellen Wiki-Syntax weiter, hmkay? :-)

Also deine Argumentation ist lustig. Bei RDBMS, einem riesen Monster von 
komplizierter Software (die garantiert 100erte von Bugs enthält) bestehst du 
auf dessen Verwendung, noch dazu unter dem Performance-Argument (und nach wie 
vor lasse ich nur das Argument des einfacheren Designs der 
MediaWiki-Software, Datensicherheit und vielleicht gerade mal so noch 
Skalierbarkeit gelten).

Aber wenn es um XML geht, was ja fast zu unserem Zweck erfunden wurde und 
unter dem Gesichtspunkt der Einfachheit entwickelt wurde, da ist es dir dann 
zu kompliziert. Noch dazu wo es schon schnelle, einfache Parser für soetwas 
gibt, die uns die halbe Arbeit abnehmen könnten.

> > Es kann nie Schaden die Software zu dokumentieren und auch zu erklären,
> > warum man bestimmte Dinge so macht, wie man sie macht.
>
> Andererseits gibt es aber auch einige Dinge, die einfach
> selbstverständlich sind; vorausgesetzt, es sind hinreichend erfahrene
> Leute dabei. Was natürlich bei einer so extrem offenen Community wie
> Wikipedia nicht immer ganz der Fall ist.

Das Problem dabei ist: Für den einen ist es selbstverständlich, der andere hat 
keine Ahnung davon. Und an anderer Stelle ist es umgekehrt. Ohne dass es 
wirklich fruchtet, aber genau deshalb wird jedem Informatikstudenten von 
Anfang an nahe gelegt die Software zu dokumentieren. Undokumentierte Software 
ist spätestens nach 5 Jahren unwartbar, weil dann keiner mehr exisitiert, der 
sie versteht. Abgesehen davon ist genau dass auch ein Grund, warum das Rad 
ständig neu erfunden wird in dieser Branche.

> Für Web-Anwendungen, die Daten verwalten, verwendet man halt ein RDBMS.
> Das ist halt so. Das hat sich bewährt, rohe Dateien nicht. Ich verstehe
> eigentlich auch gar nicht, warum so viele Leute das in Frage stellen.
> Wozu gäbe es denn sonst RDBMSe?

RDBMSe gibts zur Verwaltung von großen strukturierten Datenbeständen. Die gab 
es auch schon lange vor dem Web, damit hat es überhaupt nichts zu tun. Das 
Web ist nur ein neuer Anwendungsfall, aber auch dort eigentlich nur für 
"große strukturierte Datenbestände", wie z.B. Kundendatenbanken...

Ich erkläre es auch nochmal hier: Wir haben zwar große Datenbestände, aber 
unsere Artikel sind höchstens ein bissel verlinkt. Und wir müssen sie maximal 
nach ein paar Kriterien sortieren. Der einzige Grund für ein RDBMS hier sind 
die eher Nebensächlichen Vorteile, die ein DBMS noch zu bieten hat. Zum 
Beispiel, dass viele Personen gleichzeitig drauf zugreifen können, und 
bestimmte Dinge betreffs Datensicherheit. Schon bei der Skalierbarkeit glaube 
ich nicht mehr so recht an mySQL oder Postgre.

> > Wenn die Developer das kapieren würden, könnten sie sich eine Menge
> > unnützer Diskussionen ersparen...
>
> Vielleicht. Auf der anderen Seite kann man sich aber fragen, ob die
> Leute, die diese Art von Diskussionen lostreten, überhaupt dabei sein
> sollten. (Nicht, weil sie vielleicht etwas nicht wissen, sondern
> vielmehr, weil sie glauben, etwas zu wissen ("Dateien sind besser!
> RDBMSe sind Mist!") und von diesem Glauben nicht abzubringen sind.) Mir
> ist schon klar, daß die Diskussion "RDBMS vs. Textdateien" ein
> Extrembeispiel ist, und bei subtileren Dingen ist Dokumentation
> natürlich schon wichtig.

Also ich denke ich weiß schon worüber ich da rede, schließlich habe ich das 
studiert. Ich mag mich in der Praxis da nicht so gut auskennen, weil ich mich 
mit Datenbanken nun nicht primär beschäftigt habe, aber ich kenne die Vor- 
und Nachteile vom theoretischen Standtpunkt durchaus. Und im Gegensatz zu 
manch selbsternannten mySQL-Guru weiß ich auch ungefähr, was da intern in 
einer Datenbank abgeht.

Wenn ihr statt SQL lieber Relationale Algebra verwenden würdet (und intern 
wird eine Abfrage (keine Anweisung!, wie z.B. schreib dies und dass dort hin) 
immer insowas umgewandelt), könnte ich Euch auch genau sagen, welcher 
Ausdruck schneller als der andere ist. Abgesehen davon kann man an der Stelle 
von Hand optimieren, was der SQL-Parser nur sehr sehr bedingt kann. Die Frage 
an der Stelle wäre höchstens noch, ob wir so kompliezierte Abfragen haben 
oder nicht. Wenn nicht, lohnt sich der Aufwand auch nicht. Abgesehen davon, 
kann es natürlich auch sein, dass mySQL gar keine direkten Abfragen in dieser 
Form zuläßt? Dass wissen dann höchstens wieder die Gurus.

> Ernsthaft: Datenbankschemadesign ist wohl eher sowas, wo man nicht sagen
> kann, "das ist wegen soundso und deshalb dies und jenes". Es ist
> vielmehr etwas, das so mit der Erfahrung kommt. Man kann vielleicht
> sagen, "Wir brauchen einen Index, um die Daten effizient abrufen zu
> können", aber gleichzeitig will man ja auch nicht zu viele Indizes. Das
> gleiche gilt für verschiedene andere Aspekte (welche Spalten in einer
> Tabelle, welche Datentypen, welche Zusammenhänge). Es gibt sehr viel
> mehr "Grundregeln" (z.B. möglichst wenig Spalten variabler Länge) und
> sehr viel weniger spezifische Entscheidungen ("ich verwende hier X statt
> Y weil blahblah").

Warum man welchen Datentyp verwendet finde ich nun auch nicht besonders 
spannend. Aber das Grunddesign (wozu ist welche Tabelle gut und was steht 
drind) muss man schon erklären. Meine Erfahrung ist auch die, dass man beim 
Schreiben einer ausfürlchen Dokumentation wie von selbst viele Schwachstellen 
findet, weil man nochmal intensiver über sein Design/Code reflektiert.

> Ich kann dir aber wohl sagen: Die zwei Hauptprobleme, die ich mit der
> momentanen Datenbank sehe, sind (1) die Aufteilung in 'cur' und 'old',
> und (2) viel zu häufige Verwendung von Textdatentypen (VARCHAR und
> BLOB), wenn Ganzzahlen (INT) ausreichen. Brions Vorschlag löst nur das
> erste.

Die Trennung von cur und old hat zumindest den Vorteil, dass cur klein ist und 
man das noch runterladen kann. :-). Aber im Bedarfsfall sollte eine einfache 
SQL-Abfrage auch eine Cur-Tabelle generieren können.

--Ivo Köthnig