Teilen über


Richtlinien und Einschränkungen von XML-Massenladen (SQLXML 4.0)

Gilt für: SQL Server Azure SQL-Datenbank

Wenn Sie XML-Massenladen verwenden, sollten Sie mit den folgenden Richtlinien und Einschränkungen vertraut sein:

  • Inlineschemas werden nicht unterstützt.

    Wenn im XML-Quelldokument ein Inlineschema vorhanden ist, wird dieses Schema von XML-Massenladen ignoriert. Sie geben das Zuordnungsschema für XML-Massenladen außerhalb der XML-Daten an. Sie können das Zuordnungsschema für einen Knoten nicht mithilfe des Attributs "xmlns="x:schema" angeben.

  • Es wird überprüft, ob ein XML-Dokument wohlgeformt ist, es wird jedoch nicht überprüft, ob es gültig ist.

    Beim XML-Massenladevorgang wird das XML-Dokument überprüft, um festzustellen, ob es wohlgeformt ist, um sicherzustellen, dass der XML-Code den Syntaxanforderungen der XML 1.0-Empfehlung des World Wide Web Consortium entspricht. Wenn das Dokument nicht wohlgeformt ist, wird die Verarbeitung durch XML-Massenladen abgebrochen und ein Fehler zurückgegeben. Die einzige Ausnahme hierbei stellen Dokumente dar, bei denen es sich um Fragmente handelt (wenn das Dokument beispielsweise kein einzelnes Stammelement aufweist). In diesem Fall wird das Dokument durch XML-Massenladen geladen.

    XML-Massenladen überprüft das Dokument nicht im Hinblick auf XML-Daten oder DTD-Schemas, die in der XML-Datendatei definiert sind oder auf die in der XML-Datendatei verwiesen wird. XML-Massenladen überprüft die XML-Datendatei auch nicht im Hinblick auf das bereitgestellte Zuordnungsschema.

  • Alle XML-Prologinformationen werden ignoriert.

    Beim XML-Massenladevorgang werden alle Informationen vor und nach dem <Stammelement> im XML-Dokument ignoriert. XML-Massenladen ignoriert beispielsweise sämtliche XML-Deklarationen, internen DTD-Definitionen, externen DTD-Verweise, Kommentare usw.

  • Bei einem Zuordnungsschema, das eine Primärschlüssel-Fremdschlüssel-Beziehung zwischen zwei Tabellen (wie etwa zwischen den Tabellen Customer und CustOrder) definiert, muss die Tabelle mit dem Primärschlüssel im Schema zuerst beschrieben werden. Die Tabelle mit der Fremdschlüsselspalte muss später im Schema angezeigt werden. Der Grund dafür ist, dass die Reihenfolge, in der die Tabellen im Schema identifiziert werden, die Reihenfolge ist, in der sie in die Datenbank geladen werden. Das folgende XDR-Schema erzeugt beispielsweise einen Fehler, wenn es in XML-Massenladevorgang verwendet wird, da das Order-Element> vor dem <Customer-Element> beschrieben wird.< Die Spalte CustomerID in der Tabelle CustOrder ist eine Fremdschlüsselspalte, die auf die Primärschlüsselspalte CustomerID in der Tabelle Cust verweist.

    <?xml version="1.0" ?>  
    <Schema xmlns="urn:schemas-microsoft-com:xml-data"   
            xmlns:dt="urn:schemas-microsoft-com:xml:datatypes"    
            xmlns:sql="urn:schemas-microsoft-com:xml-sql" >  
    
        <ElementType name="Order" sql:relation="CustOrder" >  
          <AttributeType name="OrderID" />  
          <AttributeType name="CustomerID" />  
          <attribute type="OrderID" />  
          <attribute type="CustomerID" />  
        </ElementType>  
    
       <ElementType name="CustomerID" dt:type="int" />  
       <ElementType name="CompanyName" dt:type="string" />  
       <ElementType name="City" dt:type="string" />  
    
       <ElementType name="root" sql:is-constant="1">  
          <element type="Customers" />  
       </ElementType>  
       <ElementType name="Customers" sql:relation="Cust"   
                         sql:overflow-field="OverflowColumn"  >  
          <element type="CustomerID" sql:field="CustomerID" />  
          <element type="CompanyName" sql:field="CompanyName" />  
          <element type="City" sql:field="City" />  
          <element type="Order" >   
               <sql:relationship  
                   key-relation="Cust"  
                    key="CustomerID"  
                    foreign-key="CustomerID"  
                    foreign-relation="CustOrder" />  
          </element>  
       </ElementType>  
    </Schema>  
    
  • Wenn das Schema keine Überlaufspalten mithilfe der sql:overflow-Field-Anmerkung angibt, ignoriert xml Bulk Load alle Daten, die im XML-Dokument vorhanden sind, aber nicht im Zuordnungsschema beschrieben werden.

    XML-Massenladen wendet das angegebene Zuordnungsschema an, sobald es im XML-Datenstrom auf bekannte Tags trifft. XML-Massenladen ignoriert Daten, die zwar im XML-Dokument vorhanden, im Schema jedoch nicht beschrieben sind. Angenommen, Sie haben ein Zuordnungsschema, das ein <Customer-Element> beschreibt. Die XML-Datendatei verfügt über ein AllCustomers-Stammtag> (das im Schema nicht beschrieben wird), das alle< Customer-Elemente> einschließt:<

    <AllCustomers>  
      <Customer>...</Customer>  
      <Customer>...</Customer>  
       ...  
    </AllCustomers>  
    

    In diesem Fall ignoriert XML Bulk Load das AllCustomers-Element> und beginnt mit der Zuordnung am< Customer-Element>.< XML-Massenladen ignoriert die Elemente, die zwar im XML-Dokument vorhanden, im Schema jedoch nicht beschrieben sind.

    Ziehen Sie eine weitere XML-Quelldatendatei in Betracht, die Order-Elemente> enthält<. Diese Elemente sind im Zuordnungsschema nicht beschrieben:

    <AllCustomers>  
      <Customer>...</Customer>  
        <Order> ... </Order>  
        <Order> ... </Order>  
         ...  
      <Customer>...</Customer>  
        <Order> ... </Order>  
        <Order> ... </Order>  
         ...  
      ...  
    </AllCustomers>  
    

    Xml-Massenladevorgang ignoriert diese Order-Elemente>.< Wenn Sie jedoch die sql:overflow-field-Anmerkungim Schema verwenden, um eine Spalte als Überlaufspalte zu identifizieren, speichert XML Bulk Load alle nicht verarbeiteten Daten in dieser Spalte.

  • CDATA-Abschnitte und Entitätsverweise werden vor dem Speichern in der Datenbank in das entsprechende Zeichenfolgenäquivalent übersetzt.

    In diesem Beispiel umschließt ein CDATA-Abschnitt den Wert für das City-Element>.< Xml Bulk Load extrahiert den Zeichenfolgenwert ("NY"), bevor es das <City-Element> in die Datenbank einfügt.

    <City><![CDATA[NY]]> </City>  
    

    XML-Massenladen behält Entitätsverweise nicht bei.

  • Wenn in einem Zuordnungsschema der Standardwert eines Attributs angegeben ist, verwendet XML-Massenladen dieses Attribut, auch wenn das Attribut in den XML-Quelldaten nicht enthalten ist.

    Das folgende XDR-Beispielschema weist dem Attribut "HireDate " einen Standardwert zu:

    <?xml version="1.0" ?>  
    <Schema xmlns="urn:schemas-microsoft-com:xml-data"   
            xmlns:dt="urn:schemas-microsoft-com:xml:datatypes"    
            xmlns:sql="urn:schemas-microsoft-com:xml-sql" >  
       <ElementType name="root" sql:is-constant="1">  
          <element type="Customers" />  
       </ElementType>  
    
       <ElementType name="Customers" sql:relation="Cust3" >  
          <AttributeType name="CustomerID" dt:type="int"  />  
          <AttributeType name="HireDate"  default="2000-01-01" />  
          <AttributeType name="Salary"   />  
    
          <attribute type="CustomerID" sql:field="CustomerID" />  
          <attribute type="HireDate"   sql:field="HireDate"  />  
          <attribute type="Salary"     sql:field="Salary"    />  
       </ElementType>  
    </Schema>  
    

    In diesen XML-Daten fehlt das Attribut "HireDate " im zweiten <Customers-Element> . Wenn xml-Massenladevorgang das zweite <Customers-Element> in die Datenbank einfügt, verwendet es den Standardwert, der im Schema angegeben ist.

    <ROOT>  
      <Customers CustomerID="1" HireDate="1999-01-01" Salary="10000" />  
      <Customers CustomerID="2" Salary="10000" />  
    </ROOT>  
    
  • Die sql:url-codierte Anmerkung wird nicht unterstützt:

    Eine in der XML-Dateneingabe angegebene URL wird von Massenladen an diesem Speicherort nicht gelesen.

    Die im Zuordnungsschema angegebenen Tabellen werden erstellt (die Datenbank muss vorhanden sein). Wenn eine oder mehrere Tabellen bereits in der Datenbank vorhanden sind, bestimmt die SGDropTables-Eigenschaft, ob diese bereits vorhandenen Tabellen gelöscht und neu erstellt werden sollen.

  • Wenn Sie die SchemaGen-Eigenschaft (z. B. SchemaGen = true) angeben, werden die im Zuordnungsschema identifizierten Tabellen erstellt. SchemaGen erstellt jedoch keine Einschränkungen (z. B. die EINSCHRÄNKUNGEN FÜR PRIMÄRSCHLÜSSEL/FREMDSCHLÜSSEL) für diese Tabellen mit einer Ausnahme: Wenn die XML-Knoten, die den Primärschlüssel in einer Beziehung darstellen, als XML-Typ der ID (d. h. type="xsd:ID" für XSD) definiert sind und die SGUseID-Eigenschaft für SchemaGen auf "True" festgelegt ist, Dann werden nicht nur Primärschlüssel aus den ID-typierten Knoten erstellt, sondern Primärschlüssel-/Fremdschlüsselbeziehungen werden aus Zuordnungsschemabeziehungen erstellt.

  • SchemaGen verwendet keine XSD-Schema-Facets und -Erweiterungen, um das relationale SQL Server-Schema zu generieren.

  • Wenn Sie die SchemaGen-Eigenschaft (z. B. SchemaGen = true) beim Massenladevorgang angeben, werden nur Tabellen (und keine Ansichten des freigegebenen Namens) aktualisiert.

  • SchemaGen stellt nur grundlegende Funktionen zum Generieren des relationalen Schemas aus kommentierten XSD bereit. Der Benutzer muss die generierten Tabellen ggf. manuell ändern.

  • Wenn zwischen Tabellen mehrere Beziehungen vorhanden sind, versucht SchemaGen, eine einzelne Beziehung zu erstellen, die alle zwischen den beiden Tabellen beteiligten Schlüssel enthält. Diese Einschränkung kann die Ursache eines Transact-SQL-Fehlers sein.

  • Beim Massenladen von XML-Daten in eine Datenbank muss mindestens ein Attribut oder ein untergeordnetes Element im Zuordnungsschema vorhanden sein, das einer Datenbankspalte zugeordnet ist.

  • Wenn Sie Datenwerte mithilfe von XML-Massenladen einfügen, müssen die Werte im Format (-)CCYY-MM-DD((+-)TZ) angegeben werden. Dies ist das XSD-Standardformat für das Datum.

  • Einige Eigenschaftenflags sind mit anderen Eigenschaftenflags nicht kompatibel. Das Massenladen unterstützt z. B. "Ignoreduplicatekeys=true " zusammen mit Keepidentity=false nicht. Wenn Keepidentity=false, erwartet die Massenlast, dass der Server die Schlüsselwerte generiert. Tabellen sollten eine IDENTITÄTseinschränkung für den Schlüssel aufweisen. Der Server generiert keine doppelten Schlüssel, was bedeutet, dass ignoreduplicatekeys nicht auf "true" festgelegt werden müssen. Ignoreduplicatekeys sollten nur auf "true " festgelegt werden, wenn Primärschlüsselwerte aus den eingehenden Daten in eine Tabelle hochgeladen werden, die Zeilen enthält und ein Konfliktpotenzial für Primärschlüsselwerte besteht.