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