Udostępnij za pośrednictwem


Wskazówki i ograniczenia ładowania zbiorczego XML (SQLXML 4.0)

Dotyczy:programu SQL ServerAzure SQL Database

W przypadku korzystania z ładowania zbiorczego XML należy zapoznać się z następującymi wytycznymi i ograniczeniami:

  • Schematy wbudowane nie są obsługiwane.

    Jeśli masz wbudowany schemat w źródłowym dokumencie XML, ładowanie zbiorcze XML ignoruje ten schemat. Należy określić schemat mapowania dla ładowania zbiorczego XML zewnętrznych danych XML. Nie można określić schematu mapowania w węźle przy użyciu atrybutu xmlns="x:schema".

  • Dokument XML jest sprawdzany pod kątem prawidłowo sformułowanego dokumentu, ale nie jest weryfikowany.

    Ładowanie zbiorcze XML sprawdza dokument XML, aby określić, czy jest poprawnie sformułowany, aby upewnić się, że kod XML jest zgodny z wymaganiami składniowymi rekomendacji XML 1.0 konsorcjum World Wide Web Consortium. Jeśli dokument nie jest poprawnie sformułowany, ładowanie zbiorcze XML anuluje przetwarzanie i zwraca błąd. Jedynym wyjątkiem jest to, gdy dokument jest fragmentem (na przykład dokument nie ma jednego elementu głównego), w takim przypadku ładowanie zbiorcze XML załaduje dokument.

    Ładowanie zbiorcze XML nie weryfikuje dokumentu w odniesieniu do żadnego schematu XML-Data lub DTD zdefiniowanego lub przywoływnego w pliku danych XML. Ponadto ładowanie zbiorcze XML nie weryfikuje pliku danych XML względem dostarczonego schematu mapowania.

  • Wszystkie informacje prologu XML są ignorowane.

    Ładowanie zbiorcze XML ignoruje wszystkie informacje przed elementem głównym< i po >nim w dokumencie XML. Na przykład ładowanie zbiorcze XML ignoruje wszelkie deklaracje XML, wewnętrzne definicje DTD, zewnętrzne odwołania DTD, komentarze itd.

  • Jeśli masz schemat mapowania, który definiuje relację klucza podstawowego/klucza obcego między dwiema tabelami (takimi jak Klient i CustOrder), tabela z kluczem podstawowym musi zostać opisana jako pierwsza w schemacie. Tabela z kolumną klucza obcego musi pojawić się w dalszej części schematu. Przyczyną tego jest to, że kolejność, w jakiej tabele są identyfikowane w schemacie, jest kolejność, która służy do ładowania ich do bazy danych. Na przykład następujący schemat XDR spowoduje wystąpienie błędu podczas ładowania zbiorczego XML, ponieważ <element Order> został opisany przed elementem <Customer> . Kolumna CustomerID w CustOrder jest kolumną klucza obcego, która odwołuje się do kolumny klucz podstawowy CustomerID w tabeli Cust.

    <?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>  
    
  • Jeśli schemat nie określa kolumn przepełnienia przy użyciu adnotacji sql:overflow-field , ładowanie zbiorcze XML ignoruje wszystkie dane, które znajdują się w dokumencie XML, ale nie zostało opisane w schemacie mapowania.

    Ładowanie zbiorcze XML stosuje schemat mapowania określony za każdym razem, gdy napotka znane tagi w strumieniu danych XML. Ignoruje dane znajdujące się w dokumencie XML, ale nie zostały opisane w schemacie. Załóżmy na przykład, że masz schemat mapowania, który opisuje <element Klient> . Plik danych XML ma <tag główny AllCustomers> (który nie jest opisany w schemacie), który otacza wszystkie <elementy klienta> :

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

    W takim przypadku ładowanie zbiorcze XML ignoruje <element AllCustomers> i rozpoczyna mapowanie elementu <Customer> . Ładowanie zbiorcze XML ignoruje elementy, które nie zostały opisane w schemacie, ale znajdują się w dokumencie XML.

    Rozważmy inny plik danych źródłowych XML zawierający <elementy zamówienia> . Te elementy nie są opisane w schemacie mapowania:

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

    Ładowanie zbiorcze XML ignoruje te <elementy zamówienia> . Jeśli jednak używasz adnotacji sql:overflow-field w schemacie, aby zidentyfikować kolumnę jako kolumnę przepełnienia, obciążenie zbiorcze XML przechowuje wszystkie nieprzekonsumowane dane w tej kolumnie.

  • Sekcje CDATA i odwołania do jednostek są tłumaczone na ich odpowiedniki ciągów przed ich przechowywaniem w bazie danych.

    W tym przykładzie sekcja CDATA opakowuje wartość elementu <City> . Ładowanie zbiorcze XML wyodrębnia wartość ciągu ("NY"), zanim wstawi <element City> do bazy danych.

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

    Ładowanie zbiorcze XML nie zachowuje odwołań do jednostek.

  • Jeśli schemat mapowania określa wartość domyślną atrybutu, a dane źródłowe XML nie zawierają tego atrybutu, ładowanie zbiorcze XML używa wartości domyślnej.

    Poniższy przykładowy schemat XDR przypisuje wartość domyślną do atrybutu HireDate :

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

    W tych danych XML brakuje atrybutu HireDate z drugiego <elementu Customers> . Gdy ładowanie zbiorcze XML wstawia drugi <element Customers> do bazy danych, używa wartości domyślnej określonej w schemacie.

    <ROOT>  
      <Customers CustomerID="1" HireDate="1999-01-01" Salary="10000" />  
      <Customers CustomerID="2" Salary="10000" />  
    </ROOT>  
    
  • Adnotacja sql:url-encode nie jest obsługiwana:

    Nie można określić adresu URL w danych wejściowych XML i oczekiwać, że ładowanie zbiorcze odczytuje dane z tej lokalizacji.

    Tabele zidentyfikowane w schemacie mapowania są tworzone (baza danych musi istnieć). Jeśli co najmniej jedna tabela już istnieje w bazie danych, właściwość SGDropTables określa, czy te istniejące tabele mają zostać usunięte i utworzone ponownie.

  • Jeśli określisz właściwość SchemaGen (na przykład SchemaGen = true), tworzone są tabele, które są identyfikowane w schemacie mapowania. Ale SchemaGen nie tworzy żadnych ograniczeń (takich jak ograniczenia KLUCZ PODSTAWOWY/KLUCZ OBCY) w tych tabelach z jednym wyjątkiem: Jeśli węzły XML, które stanowią klucz podstawowy w relacji, są zdefiniowane jako mające typ XML identyfikatora (czyli type="xsd:ID" dla XSD ) i właściwość SGUseID jest ustawiona na true dla schemaGen, następnie nie tylko klucze podstawowe tworzone na podstawie typowanych węzłów identyfikatora, ale relacje klucza podstawowego/klucza obcego są tworzone na podstawie relacji schematu mapowania.

  • SchemaGen nie używa aspektów schematu XSD i rozszerzeń do generowania relacyjnego schematu programu SQL Server.

  • Jeśli określisz właściwość SchemaGen (na przykład SchemaGen = true) w przypadku ładowania zbiorczego, zostaną zaktualizowane tylko tabele (a nie widoki nazwy udostępnionej).

  • Narzędzie SchemaGen udostępnia tylko podstawowe funkcje generowania schematu relacyjnego z adnotacjami XSD. W razie potrzeby użytkownik powinien ręcznie zmodyfikować wygenerowane tabele.

  • Jeśli istnieje więcej niż jedna relacja między tabelami, narzędzie SchemaGen próbuje utworzyć jedną relację zawierającą wszystkie klucze zaangażowane między dwiema tabelami. To ograniczenie może być przyczyną błędu Transact-SQL.

  • Podczas zbiorczego ładowania danych XML do bazy danych musi istnieć co najmniej jeden atrybut lub element podrzędny w schemacie mapowania, który jest mapowany na kolumnę bazy danych.

  • W przypadku wstawiania wartości daty przy użyciu ładowania zbiorczego XML wartości muszą być określone w formacie (-)CCYY-MM-DD((+-)TZ. Jest to standardowy format XSD daty.

  • Niektóre flagi właściwości nie są zgodne z innymi flagami właściwości. Na przykład ładowanie zbiorcze nie obsługuje wartości Ignoreduplicatekeys=true razem z parametrem Keepidentity=false. Gdy keepidentity=false, obciążenie zbiorcze oczekuje, że serwer wygeneruje wartości kluczy. Tabele powinny mieć ograniczenie TOŻSAMOŚCI dla klucza. Serwer nie wygeneruje zduplikowanych kluczy, co oznacza, że nie ma potrzeby ustawiania wartości Ignoreduplicatekeys na true. Ignorowaneklucze powinny być ustawione na wartość true tylko w przypadku przekazywania wartości klucza podstawowego z danych przychodzących do tabeli zawierającej wiersze i istnieje możliwość konfliktu wartości klucza podstawowego.