Linq to SQL o Linq to Entities 4.0 supportano il tipo di dati hierarchyid

Question

È un modo di utilizzare linq to SQL/Entities 4.0 per funzionare con il tipo di dati della gerarchia?

Answer 1

Nessuno della famiglia Microsoft di ORM può attualmente utilizzare i tipi definiti dall'utente CLR (che include i tipi incorporati hierarchyid e geospaziali) come tipi di colonna.

se si utilizzano questi nel database, si hanno due soluzioni:

1. Aggiungi una colonna calcolata alla tabella gerarchia con l'espressione CAST(hid AS varbinary892)). È necessario assicurarsi di includere questa colonna nella query ogni (incluse le stored procedure) che viene utilizzata da Linq. Quindi, aggiungere questa colonna alla mappatura delle entità.

   A questo punto, è possibile estendere classe parziale dell'entità di aggiungere il "vero" hierarchyid colonna come sua proprietà con l'aggiunta di un riferimento alla Microsoft.SqlServerTypes e utilizzando i BinaryReader/BinaryWriter classi per convertire i dati BLOB da/per SqlHierarchyId.

   Nota che non è possibile scrivere query Linq su questa colonna. Se provi, ricevi un errore "traduzione non supportata". Pertanto, tieni presente che questa è una soluzione alternativa limitata a.

2. L'altra opzione, e quella che generalmente preferisco, è quella di non utilizzare la colonna hierarchyid da L2S/EF. Aggiungi una chiave di autoincro surrogata surrogato separatamente alla tabella della gerarchia e considera lo hierarchyid come dettaglio di implementazione. Utilizzare UDF e viste per implementare query gerarchiche che richiedono solo l'ID surrogato come parametro.

   Questo suona come un dolore, ma non è poi così male se si lavora in questo modo dall'inizio. Prima che Microsoft introducesse il tipo hierarchyid, stavo usando un adattamento della gerarchia di percorso materializzata di Dennis Forbes, che era basata su una lista di adiacenze e manteneva il percorso come una sorta di denormalizzazione. hierarchyid rende questo molto più facile da fare.

   Purtroppo non ho un esempio funzionante completo di tutto ciò che è necessario fare per mantenere le associazioni corrette tra un elenco hierarchyid e adiacenza, ma se si legge Dennis's article dovrebbe essere un buon inizio. Non implementare il percorso materializzato, utilizzare invece hierarchyid, ma leggere le sezioni sull'implementazione delle gerarchie di autocontrollo con i trigger.

   Se Microsoft implementa il supporto per hierarchyid nei propri ORM, sarebbe facile rimuovere l'elenco di adiacenza e passare esclusivamente a una soluzione basata su hierarchyid. Ma dal momento che la gestione delle gerarchie basate su hierarchyid richiede un gran numero di stored procedure per mantenere in ogni caso (poiché non si ottengono gli ID "automatici"), si dovrebbe familiarizzare con la scrittura di molte UDF SQL e astrazioni di stored procedure attorno alle query gerarchiche.

Answer 2

In una parola, no. Non direttamente, comunque. Si potrebbe essere in grado di work around it similarly to geospatial types, però. Non ho provato

Answer 3

Utilizziamo una soluzione simile a quella di Aaronaught con Linq a SQL.

Dobbiamo creare colonne calcolate

TreeId.ToString() 

per il hierarchyid-colonna corrente e

[TreeId].[GetAncestor](1).ToString() 

per il genitore di diretta.

Abbiamo anche creato una vista che esclude la colonna gerarchico e trascina questa vista sul diagramma Dbml e imposta le associazioni alle tabelle di riferimento.

La maggior parte delle funzionalità gerarchiche deve tuttavia essere in forma di stored procedure.