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