<?xml version="1.0" encoding="UTF-8"?>
<commit>
  <added type="array"/>
  <modified type="array">
    <modified>
      <diff>@@ -8,6 +8,7 @@ faq/general.txt 10632 cbe3847c6bdbc06a92b45d8c156a758908342571
 faq/help.txt 10632 cbe3847c6bdbc06a92b45d8c156a758908342571
 faq/index.txt 10632 cbe3847c6bdbc06a92b45d8c156a758908342571
 faq/install.txt 10632 cbe3847c6bdbc06a92b45d8c156a758908342571
+faq/models.txt 10632 cbe3847c6bdbc06a92b45d8c156a758908342571
 faq/usage.txt 10632 cbe3847c6bdbc06a92b45d8c156a758908342571
 howto/custom-template-tags.txt 10415 de0fc1fea341d905e9810fe2586cd4772c3a09a4
 howto/static-files.txt 10415 de0fc1fea341d905e9810fe2586cd4772c3a09a4</diff>
      <filename>STATUS</filename>
    </modified>
    <modified>
      <diff>@@ -3,8 +3,8 @@
 FAQ: Datenbanken und Datenmodelle
 =================================
 
-Wie kann sehen welche SQL-Queries Django ausf&#252;hrt?
---------------------------------------------------
+Wie kann ich sehen, welche SQL-Queries Django ausf&#252;hrt?
+--------------------------------------------------------
 
 Stell sicher, dass die ``DEBUG`` Einstellung auf ``True`` gesetzt ist und f&#252;hre
 dann folgendes aus::
@@ -14,24 +14,22 @@ dann folgendes aus::
     [{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
     'time': '0.002'}]
 
-``connection.queries`` ist nur verf&#252;gbar wenn ``DEBUG`` auf ``True`` steht. Es 
-ist eine Liste von Dictionaries in der Reihenfolge der Queryausf&#252;hrung.
+``connection.queries`` ist nur verf&#252;gbar, wenn ``DEBUG`` auf ``True`` steht.
+Es ist eine Liste von Dictionaries in der Reihenfolge der Queryausf&#252;hrung.
 Jedes Dictionary hat folgende Attribute:
 
     ``sql`` -- Das SQL-Statement
     ``time`` -- Die Ausf&#252;hrungszeit des Statements in Sekunden.
 
-``connection.queries`` includes all SQL statements -- INSERTs, UPDATES,
-SELECTs, etc. Each time your app hits the database, the query will be recorded.
-
-``connection.queries`` beinhaltet alle SQL-Statements wie z.B. INSERT's, 
-UPDATE's oder SELECT's. Jedes mal wenn deine Applikation die Datenbank nutzt
+``connection.queries`` beinhaltet alle SQL-Statements wie z.B. INSERTs, 
+UPDATEs oder SELECTs. Jedes mal, wenn deine Applikation die Datenbank nutzt,
 wird die Abfrage gespeichert.
 
 Kann ich Django mit einer bereits bestehenden Datenbank nutzen?
 ---------------------------------------------------------------
 
-Ja. Siehe dazu :ref:`Integration mit einer bereits bestehenden Datenbank &lt;howto-legacy-databases&gt;`.
+Ja. Siehe dazu :ref:`Integration mit einer bereits bestehenden Datenbank
+&lt;howto-legacy-databases&gt;`.
 
 Wie aktualisiere ich die Datenbank wenn ich ein Datenmodell &#228;ndere?
 -------------------------------------------------------------------
@@ -42,27 +40,27 @@ zur&#252;ckzusetzen::
 
     manage.py reset appname
 
-Dies l&#246;scht alle Tabellen die zu ``appname`` geh&#246;ren und erstellt sie neu.
+Dies l&#246;scht alle Tabellen, die zu ``appname`` geh&#246;ren und erstellt sie neu.
 
-Falls dir bestehende Daten wichtig sind, musst du die 
-``ALTER TABLE``-Statement's manuell in deiner Datenbank ausf&#252;hren. So haben 
-wir es bisher immer gemacht, da das Behandeln von Daten eine sehr empfindliche 
-Arbeit ist, die wir nicht automatisieren wollten. Dennoch wird daran 
-gearbeitet teilweise-automatisierte Datenbank-Aktualisierungen zu erm&#246;glichen.
+Falls dir bestehende Daten wichtig sind, musst du die ``ALTER
+TABLE``-Statements manuell in deiner Datenbank ausf&#252;hren. So haben wir es
+bisher immer gemacht, da das Behandeln von Daten eine sehr empfindliche Arbeit
+ist, die wir nicht automatisieren wollten. Dennoch wird daran gearbeitet,
+teilweise-automatisierte Datenbank-Aktualisierungen zu erm&#246;glichen.
 
-Unterst&#252;tzen Django's Datenmodelle mehrspaltige Primary Keys?
--------------------------------------------------------------
+Unterst&#252;tzen Djangos Datenmodelle mehrspaltige Prim&#228;rschl&#252;ssel?
+---------------------------------------------------------------
 
-Nein, es werden lediglich einspaltige Primary Keys unterst&#252;tzt.
+Nein, es werden lediglich einspaltige Prim&#228;rschl&#252;ssel unterst&#252;tzt.
 
-Dies spielt in der Praxis jedoch keine gro&#223;e Rolle, da du die Einzigartigkeit 
-auch durch andere Bedingungen (mithilfe der ``unique_together`` Modeloption 
-oder durch das Erstellen der Bedingungen direkt in der Datenbank) durchsetzen 
-kannst. Einspaltige Primary Keys werden z.B. f&#252;r das spezifizieren der 
-zu editierenden oder l&#246;schenden Datens&#228;tze in der Administrationsoberfl&#228;che 
+Dies spielt in der Praxis jedoch keine gro&#223;e Rolle, da du die Einzigartigkeit
+auch durch andere Bedingungen (mithilfe der ``unique_together`` Modeloption
+oder durch das Erstellen der Bedingungen direkt in der Datenbank) durchsetzen
+kannst. Einspaltige Primary Keys werden z.B. f&#252;r das Spezifizieren der zu
+editierenden oder zu l&#246;schenden Datens&#228;tze in der Administrationsoberfl&#228;che
 ben&#246;tigt.
 
-Wie kann ich Datenbank-spezifische Optionen, wie z.B. den MyISAM Tabellentyp, zu meinen CREATE TABLE-Statements hinzuf&#252;gen? 
+Wie kann ich Datenbank-spezifische Optionen, wie z.B. den MyISAM-Tabellentyp, zu meinen CREATE TABLE-Statements hinzuf&#252;gen? 
 ---------------------------------------------------------------------------------------------------------------------------
 
 Wir versuchen Spezialf&#228;lle im Django-Code (z.B. Datenbank-spezifische 
@@ -73,7 +71,7 @@ den ``CREATE TABLE``-Statements in der Datenbank ausgef&#252;hrt.
 
 Wenn du beispielsweise MySQL verwendest und MyISAM als Tabellentyp 
 spezifizieren willst, musst du eine SQL-Startdatei mit folgendem Inhalt 
-anlegen:
+anlegen::
 
     ALTER TABLE myapp_mytable ENGINE=MyISAM;
 
@@ -85,19 +83,19 @@ Warum belegt Django immer mehr Arbeitsspeicher?
 -----------------------------------------------
     
 Dies sollte normalerweise nicht passieren. Wenn deine Django-Prozesse grundlos
-immer mehr Speicher belegen und diesen nicht wieder freigeben, solltest du 
-pr&#252;fen ob die ``DEBUG``-Einstellung auf ``False`` steht. Sollte ``DEBUG`` 
-auf ``True`` gesetzt sein speichert Django eine Kopie jedes ausgef&#252;hrten 
+immer mehr Speicher belegen und diesen nicht wieder freigeben, solltest du
+pr&#252;fen ob die ``DEBUG``-Einstellung auf ``False`` steht. Sollte ``DEBUG`` auf
+``True`` gesetzt sein, speichert Django eine Kopie jedes ausgef&#252;hrten
 SQL-Statements.
 
 (Die Queries werden in ``django.db.connection.queries`` gespeichert. Siehe
-`Wie kann ich die SQL-Queries sehen, die Django ausf&#252;hrt?`_.)
+`Wie kann ich sehen, welche SQL-Queries Django ausf&#252;hrt?`_.)
 
-Setze ``DEBUG`` auf ``False`` um das Problem zu beheben.
+Setze ``DEBUG`` auf ``False``, um das Problem zu beheben.
 
 Falls du die Query-Liste manuell in einer deiner Funktionen leeren m&#246;chtest, 
 kannst du einfach die ``reset_queries()``-Funktion ausf&#252;hren::
 
     from django import db
     db.reset_queries()
-    
\ No newline at end of file
+    </diff>
      <filename>faq/models.txt</filename>
    </modified>
  </modified>
  <removed type="array"/>
  <parents type="array">
    <parent>
      <id>beac5a0f97fd02ec96e2ed5c18add0207d674fe5</id>
    </parent>
  </parents>
  <author>
    <name>Horst Gutmann</name>
    <email>zerok@zerokspot.com</email>
  </author>
  <url>http://github.com/zerok/django-docs-de/commit/ee21d8ce8354d5f429b1b398f186d6f1e8ab3323</url>
  <id>ee21d8ce8354d5f429b1b398f186d6f1e8ab3323</id>
  <committed-date>2009-04-28T13:22:25-07:00</committed-date>
  <authored-date>2009-04-28T13:22:25-07:00</authored-date>
  <message>faq/models.txt updated</message>
  <tree>8396c81c4ca34c7673acf30286aaf8f30e2b6bea</tree>
  <committer>
    <name>Horst Gutmann</name>
    <email>zerok@zerokspot.com</email>
  </committer>
</commit>
