1. Riformulare la domanda
Il tuo esempio suggerisce che i dati vengono letti solo sul lato Drupal, con la sincronizzazione unidirezionale. Penso che questo sia il fattore più importante da considerare qui, perché in effetti qualsiasi soluzione implementerai sarà una variante di archiviazione remota, sincronizzazione e memorizzazione nella cache locale, anche se la memorizzazione nella cache locale finirà per essere entità nel database Drupal.
Quindi la domanda, anziché essere "archiviazione locale vs archiviazione remota" sarà:
- Dovresti memorizzare i dati nella cache locale;
- Dovresti memorizzare nella cache i dati come entità effettive e utilizzare Feed (o simili) per sincronizzare i dati regolarmente; O
- Se si utilizza un modulo personalizzato che fornisce la sincronizzazione e la memorizzazione nella cache.
Un articolo che potrebbe interessarti è " Entità remote in Drupal 7 ".
2. Memorizzazione nella cache dei dati
In generale, la memorizzazione nella cache dei dati è una buona idea:
Sei protetto da interruzioni degli altri servizi o timeout nella connessione;
La presenza dei dati nel database Drupal velocizzerà le operazioni;
Avere i tuoi dati presenti nel tuo database Drupal significa che avrai maggiori probabilità di ottenere l'integrazione con altri moduli, come Views (anche se questo non è garantito).
L'unico vantaggio di non memorizzare nella cache i dati è che non si ottengono mai dati non aggiornati, il che in alcuni casi è preferibile, a volte è preferibile non visualizzare dati piuttosto che dati non aggiornati. Non vedo questo come un vantaggio nell'esempio che hai dato, quindi focalizzerò questa risposta su una soluzione che prevede la memorizzazione nella cache locale.
3. Entità locali + sincronizzazione
Se scegli l'opzione di avere entità locali e sincronizzarle da solo, torniamo alle tue domande originali:
3.1 Nodi vs entità personalizzate
La definizione di cosa sia esattamente un nodo è abbastanza aperta. La pagina della documentazione sui nodi suggerisce che i nodi stanno "postando" che sono "memorizzati" sul tuo sito, nessuno dei quali si applica ai tuoi dati;
Come sviluppatore di Drupal mi aspetterei che se qualcosa è un nodo, dovrei essere in grado di manipolarlo sul sito stesso;
Come utente Drupal, mi aspetto allo stesso modo che i nodi possano essere modificati;
Questo numero di Drupal 8 https://drupal.org/node/2019031 suggerisce che il concetto di "sola lettura" è uno che si applicherebbe a livello di entità, piuttosto che a livello di bundle. Se questo dovesse mai essere implementato, ne trarrai beneficio andando su questa strada.
Riassumendo: i tuoi dati vengono letti e archiviati in remoto ha più senso utilizzare un tipo di entità personalizzato per rappresentare i tuoi dati.
3.2 Sincronizzazione
Per la seconda parte, i due moduli principali per questo sono, come suggerisci, Feed e Migrate .
La differenza tra Feed e Migrate è che Feed è creato per l'importazione regolare di contenuti, mentre Migrate è creato per il porting unico di contenuti da un luogo a un altro. Migrare supporta l'aggiornamento dei dati esistenti, tuttavia, dato che entrambi i moduli sono ben supportati, è più sensato utilizzare il modulo che è stato creato per l'attività in corso - I feed sono una corrispondenza migliore.
Avendo usato entrambi i moduli (Feed per la sincronizzazione, Migrazione per la migrazione), non trovo che i Feed siano più disordinati di Migrate. Migrare ha richiesto più codice personalizzato nella mia esperienza, anche se la migrazione di interi siti è più complessa dell'importazione di singoli tipi di contenuto, quindi è difficile confrontare.
4. Modulo personalizzato per archiviazione remota, sincronizzazione + memorizzazione nella cache
Esistono numerosi moduli che possono essere di aiuto in questo compito.
Hai menzionato il modulo Dati servizi Web e altri hanno menzionato il modulo Dati . Un'altra opzione da considerare è il modulo API di entità remota . Si noti che l'unico di quelli con cui ho esperienza è il modulo dati.
Il modulo dati dei servizi Web non ha ancora una versione, il che potrebbe indicare che il codice non è ancora stabile, l'API potrebbe cambiare e così via. Non supporta le query sul campo di entità (in base alla sua pagina del progetto) e una rapida esplorazione del repository di codice non mostra alcuna prova del supporto di Views, quindi non sarà possibile utilizzare Views per visualizzare le entità;
Il modulo Dati è più orientato, secondo la mia esperienza, ai non sviluppatori che hanno dati in una tabella e vogliono esporli alle viste. Ho trovato la versione di Drupal 6 molto frustrante da usare, anche se da allora potrebbe essere cambiata;
Il modulo API Remote Entity sembra abbastanza promettente: supporta il recupero e la memorizzazione nella cache di entità remote e ha il supporto Views. È solo in versione alpha, quindi l'API potrebbe ancora cambiare. A prima vista, sembra che non disponga nemmeno del supporto Entity Field Query e supporta solo un tipo di servizio remoto, quindi dovresti implementare il tuo.
Conclusione
Dato che nessuno dei moduli di archiviazione remota supporta query sul campo di entità, l'utilizzo di entità + feed effettivi è la soluzione che ti darà la migliore integrazione con il tuo sito Drupal.
Se il supporto di Views è sufficiente e non sei preoccupato per la potenziale integrazione con altri moduli tramite Query sul campo Entity, utilizzare l'API Entità remota potrebbe essere la strada da percorrere, tuttavia dovrai implementare la tua interfaccia remota.