Ich möchte hier mal die Frage eröffnen, wie unsere neue DB-Strutkur aussehen sollte. Bisher ist alles in einer flachen Tabelle, mit mehrfachen Redundanzen und ohne Referenzen.
Bei der DB-Struktur sollte man sich von dem TEI-XML-Standard http://www.tei-c.org/P5/Guidelines/DI.html inspirieren lassen. Ich kopiere mal ein mögliches bereits leicht abgewandeltes TEI-XML hier rein:

<entry id="43658"> 
<form> 
  <orth>殻</orth> 
  <orth>から</orth> 
  <orth>カラ</orth> 
  <pron>から</pron> 
</form> 
<senses> 
  <sense> 
      <trans> 
        <nomen genus="f">Hülse</nomen> 
        <context>von Bohne</context> 
      </trans> 
      <trans> 
        <nomen genus="f">Hülle</nomen> 
      </trans> 
      <trans> 
        <nomen genus="f">Schale</nomen> 
        <context>von Korn, Nuss, Ei, Muschel etc.</context> 
      </trans> 
  </sense> 
  <sense usage="übertr."> 
      <trans> 
        das eigene <nomen genus="n">Schneckenhaus</nomen> 
      </trans> 
      <trans> 
        <nomen genus="m">Schutzpanzer</nomen> 
      </trans> 
  </sense> 
  <sense> 
      <trans> 
        abgeworfene <nomen genus="f">Haut</nomen> 
        <context>z.B. einer Schlange</context> 
      </trans> 
      <trans> 
        leerer Chitinpanzer 
        <context>z.B. einer Larve</context> 
      </trans> 
  </sense> 
  <sense domain="Kochk."> 
      <trans> 
        <nomen genus="n">O·kara</nomen> 
        <context>Reste von der Tōfu-Produktion</context> 
        <context>gekocht od. gebraten als Nebengericht gegessen</context> 
      </trans> 
  </sense> 
  <sense> 
      <trans> 
        <nomen genus="m">Leichnam</nomen> 
      </trans> 
      <trans> 
        sterbliche <nomen genus="mpl">Überreste</nomen> 
      </trans> 
  </sense> 
</senses> 
</entry>

Das würde also dafür sprechen, dass man neben der Entry-Tabelle folgende Tabellen hat:
- form, hier mit 4 Einträgen, jeder mit Fremschlüssel auf Entry
- sense, hier mit 5 Einträgen, jeder mit Fremdschlüssel auf Entry
- trans, hier mit ca. 10 Einträgen, jeder mit Fremdschlüssel auf Sense

Feedback? Anregungen?

Auf die Schnelle sieht das gut aus.

Allerdings stellt sich die Frage, welche Felder aus der TEI-Definition noch unterstützt werden sollen. Je nachdem sind eventuell zusätzliche Tabellen notwendig.
Insbesondere für die <trans>-Felder sehe ich da einiges an Arbeit
Achja und <etym> und <def> usw., welche ja schon so ähnlich im Wiki stehen, bräuchten z.B. auch Tabellen.

1. wie viele ORTH Felder kann es wirklich geben?
(Die Frage stellt sich, ja immer, ob man evtl. entweder Speicherplatz durch spaltenbasiertes Speichern (also NULL values in spalten), oder Prozessorzeit durch zeilenbasiertes Speichern verschwendet. Denn das was Zeilenbasiert ist, muss nacher durch Joins wieder zusammengefügt werden, ist aber in der Anzahl sehr flexibel)

2. Kann es mehrere PRON felder geben die womöglich auch noch zu bestimmten ORTH Feldern assoziert werden müssen?

3. Welche Attribute gibt es bei dem SENSE Eintrag? hier sind nur "usage" und "domain" anwesend. Wie flexibel muss das sein? Kann ein Eintrag auch direkt mehrere Attribute haben?


Im Moment wäre mein Ansatz eher so:
Man konzentriert sich auf die Werte, die man wirklich braucht, und zwar so wie wir (also Wadoku Instanz) sie brauchen. Man modelliert sich seine Welt, für die Datenbank und schreibt dann verschiedene Transformmechanismen wie man die Daten hinterher rausgeben möchte (TEI, edict, edict xml, ander Binäre Formate etc.).

Es scheint für mich im Moment zwei Vorteile zu haben:

1. Man kann so etwas in mehren kleinen Schritten durchführen (Schemaevulotionsbasiert) und muss nicht alle Daten auf einen Schlag in ein Komplett anderes Format transformieren, mit dem wenig Erfahrung existiert.

2. Man ist sehr flexibel was die spätere Ausgabe anbetrifft.

Mein größter Kritikpunkt am TEI ist:
Wenn man schon anfangen muss, das TEI zu erweitern, dann bewegt man sich wieder vom TEI weg. Es scheint dann also als ob das TEI nicht flexibel genug ist, die Anforderungen direkt zu erfüllen. Ergo kann man auch etwas eigenes machen und versuchen die Probleme die beim TEI auftreten, gar nicht erst auftreten zu lassen, bzw. erst dann zu lösen wenn man die Daten als Paket herausgeben möchte.

Sollte man nicht lieber in dem SENSE Attribut nur eine genormte Liste zur verfügung stellen? So dass man z.B. alle Wörter finden kann die zur Domäne "Kochkunst" gehören, ohne dass man auch noch "Kochk.", "Kochen", ... mit durchsuchen muss?

Ohne den Vorschlag davor müsste das Schema aber eher so aussehen: (Siehe Bild)

Weiterhin ist mir noch nix dazu eingefallen wie man folgendes in die DB Packen kann ohne dass man es total zerstückelt:
<trans>
das eigene <nomen genus="n">Schneckenhaus</nomen>
</trans>

Es geht da vor allem um das NOMEN Markup element.

Die DB-Struktur ist ein Anfang, lass uns daran weiterarbeiten.
Erstmal nur kurz: Ich habe unter Links einen aktuellen SQL-Dump hochgeladen. Wer will, kann sich den ja mal anschauen. Der ist aber noch total flach, also nur eine Tabelle. Bislang werden alle Index daraus programmatisch generiert.

Der Dump ist super.

Kannst Du mir vielleicht noch die anderen Index-Tabellen und wie Du die erzeugst irgendwie zukommen lassen. Dazu wäre dann noch die SQL Anfragen, die immer asugeführt werden (z.B. bei der Suche) praktisch.

Dann kann ich die Daten schon mal in eine andere Form bringen (alles per Mysql SQL script soweit möglich) und kann mir Gedanken über Indexe auf der Struktur machen sowie schon mal ein bisschen Performance-profiling.

Vielleicht kann man ja mal nen Sourcen Verwaltungssystem andenken wie Subversion, dann kann man sowas auch versionssicher speichern und effizient teilen.

Ich bin jetzt auf der Suche nach eine SVN/CVS Respository, wie Sourceforge oder Co. Gibts Präferenzen oder Erfahrungen? Ich möchte ungern eines selber aufsetzen, sondern eher die Infrastruktur von existierenden verwenden, incl. Bugtracking und Co.

Mir ist ein SVN lieber, denn der Umgang mit binärdateien ist um einiges effizienter.
Ich könnte bei uns über die Uni eins zur Verfügung stellen. Allerdings ohne Bugtracking.

Ja super, dann fagen wir doch damit an. Fürs Bugtracking finden wir vielleicht noch was anderes.
Kannst du das in die Wege leiten?

Nunja, da fuers Wiki Confluence verwendet wird, wuerde sich fuers Bugtracking ja JIRA, welches auch recht gute Kritiken hat, aus dem gleichen Hause anbieten. Sonst gibt es genug andere wie z.B. Bugzilla oder Trac, welches wiederum auch ein Wiki eingebaut hat....

Dieses Bugtracking koennte man nicht nur fuer die technische Seite sondern auch fuer die inhaltliche Seite nutzen. Das bietet auch fuer Editoren Vorteile, wenn man z.B. Fachbegriffe an den entsprechenden Experten zur Uberpruefung, Korrektur usw. verweisen kann. Feste workflows, usw.