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

Gilt für:SQL ServerAzure 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 nicht mit dem Xmlns="x:schema" -Attribut auf einem Knoten angeben.

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

    Das XML-Massenladen überprüft das XML-Dokument, um zu ermitteln, ob es wohlgeformt ist, um sicherzustellen, dass das XML 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.

    Das XML-Massenladen ignoriert alle Informationen vor und nach dem <Stammelement> im XML-Dokument. 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 im XML-Massenladen 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 das XML-Massenladen 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 verfügen über 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> umschließt:

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

    In diesem Fall ignoriert das XML-Massenladen 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.

    Betrachten Sie eine andere XML-Quelldatendatei, 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-Massenladen ignoriert diese <Order-Elemente> . Wenn Sie jedoch die sql:overflow-field-Anmerkungim Schema verwenden, um eine Spalte als Überlaufspalte zu identifizieren, speichert XML-Massenladen alle nicht verbrauchten 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-Massenladen extrahiert den Zeichenfolgenwert ("NY"), bevor das <City-Element> in die Datenbank eingefügt wird.

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

    Im folgenden XDR-Beispielschema wird dem HireDate-Attribut ein Standardwert zugewiesen:

    <?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 HireDate-Attribut im zweiten <Customers-Element> . Wenn xml bulk load das zweite <Customers-Element> in die Datenbank einfügt, wird der im Schema angegebene Standardwert verwendet.

    <ROOT>  
      <Customers CustomerID="1" HireDate="1999-01-01" Salary="10000" />  
      <Customers CustomerID="2" Salary="10000" />  
    </ROOT>  
    
  • Die sql:url-encode-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 angeben (z. B. SchemaGen = true), werden die Im Zuordnungsschema identifizierten Tabellen erstellt. SchemaGen erstellt jedoch keine Einschränkungen (z. B. die PRIMARY KEY/FOREIGN KEY-Einschränkungen) für diese Tabellen mit einer Ausnahme: Wenn die XML-Knoten, die den Primärschlüssel in einer Beziehung bilden, so definiert sind, dass sie über einen XML-Typ von ID (d. b. type="xsd:ID" für XSD) verfügen und die SGUseID-Eigenschaft für SchemaGen auf True festgelegt ist, dann werden nicht nur Primärschlüssel aus den ID-typisierten Knoten erstellt, sondern auch Primärschlüssel-/Fremdschlüsselbeziehungen werden aus Zuordnungsschemabeziehungen erstellt.

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

  • Wenn Sie die SchemaGen-Eigenschaft (z. B. SchemaGen = true) beim Massenladen angeben, werden nur Tabellen (und keine Ansichten mit freigegebenem Namen) aktualisiert, die angegeben sind.

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

  • Wenn mehrere Beziehungen zwischen Tabellen vorhanden sind, versucht SchemaGen, eine einzelne Beziehung zu erstellen, die alle beteiligten Schlüssel zwischen den beiden Tabellen enthält. Diese Einschränkung kann die Ursache für einen Transact-SQL-Fehler 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. Beispielsweise unterstützt das Massenladen ignoreduplicatekeys=true zusammen mit Keepidentity=false nicht. Bei Keepidentity=false erwartet die Massenlast, dass der Server die Schlüsselwerte generiert. Tabellen sollten eine IDENTITY-Einschränkung für den Schlüssel aufweisen. Der Server generiert keine doppelten Schlüssel, was bedeutet, dass Ignoreduplicatekeys nicht auf true festgelegt werden muss. Ignoreduplicatekeys sollte nur auf TRUE festgelegt werden, wenn Primärschlüsselwerte aus den eingehenden Daten in eine Tabelle hochgeladen werden, die Zeilen enthält und ein Konflikt zwischen Primärschlüsselwerten besteht.