Wadoku.de Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics  
[Register] Register /  [Login] Login 
Neue DB-Struktur  RSS feed
Forum Index » WadokuTeam
Author Message
Admin



Joined: 22/05/2006 21:58:42
Messages: 6
Offline

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?

Dan


[Avatar]

Joined: 24/05/2006 16:58:45
Messages: 1262
Online

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.

無知の知
yoshtec


[Avatar]

Joined: 25/10/2006 01:12:56
Messages: 66
Offline

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.

yoshtec


[Avatar]

Joined: 25/10/2006 01:12:56
Messages: 66
Offline

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?
yoshtec


[Avatar]

Joined: 25/10/2006 01:12:56
Messages: 66
Offline

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.
 Filename  DBSchema1.gif [Disk] Download
 Description  No description given
 Filesize   9 Kbytes
 Downloaded:  990 time(s)

Thomas Latka



Joined: 22/05/2006 23:04:06
Messages: 164
Offline

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.
yoshtec


[Avatar]

Joined: 25/10/2006 01:12:56
Messages: 66
Offline

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.
Thomas Latka



Joined: 22/05/2006 23:04:06
Messages: 164
Offline

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.
yoshtec


[Avatar]

Joined: 25/10/2006 01:12:56
Messages: 66
Offline

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.
Thomas Latka



Joined: 22/05/2006 23:04:06
Messages: 164
Offline

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


[Avatar]

Joined: 24/05/2006 16:58:45
Messages: 1262
Online

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.

無知の知
 
Forum Index » WadokuTeam
Go to: