Database orientati all'API: è gestito dal team di back o API?

Naviga le tue risposte
3

Da quanto ho capito, i database no-SQL differiscono dai database SQL perché consentono agli sviluppatori di progettare le tabelle per adattarle all'utilizzo, piuttosto che adattare il modello. Il che significa che la maggior parte delle volte che se ho un'API che usa Cassandra o Neo4J, Cassandra o Neo4J avranno una vista per servizio API.

Se questo è vero, significa che se ho un'applicazione Spark che riempie il mio database no-SQL, quale team nel progetto dovrebbe essere in teoria responsabile per Cassandra o Neo4J? Per responsabile intendo: creare le tabelle, definire gli standard di creazione delle tabelle, consegnare il database e le tabelle al client ... Se il team Spark si prende cura di questo perché è l'ine che riempie la tabella, quindi che possiede i dati, o è il team dell'API perché gli schemi sono progettati per migliorare la loro applicazione? Immagino che dovranno comunicare, ma chi eseguirà questi compiti?

    
posta Vulpo 27.04.2018 - 01:20
fonte

2 risposte

0

Secondo il mio punto di vista, lo scenario che citi è una situazione comune nelle aziende là fuori.

Un servizio API potrebbe essere progettato da un team di ingegneri del software seguendo determinati requisiti, avendo già un database lì, quindi l'API, una soluzione successiva per utilizzare questi dati.
Potrebbe anche essere progettato allo stesso tempo in cui è stato creato il servizio API.

Per i grandi progetti, il database stesso ha un database (o team) esperto nella tecnologia del database, altamente consapevole di dettagli tecnici ingannevoli, abbastanza per prendere decisioni di progettazione o fornire un sistema di database robusto e ottimale.

Se stiamo parlando di database di dati scientifici, principalmente di calcoli fatti su dati (la scintilla per esempio), forse il team che sa meglio cosa fare con il database è l'ingegneria dei dati / team di scienza dei dati e il team dell'API, questa volta, responsabile della creazione di business logic per "help" su qualsiasi tipo di query, post-elaborazione o reporting complesso da questo database.

Ci può essere anche il caso in cui il database è più simile a una raccolta di registri orientati agli oggetti, da creare / leggere / aggiornare / eliminare, ad esempio un approccio REST al servizio API, quindi, è più probabile che il team API gestisce completamente il database.

Sono d'accordo con @Ewan che dipende dal trucco della tua azienda , come è stato costruito il sistema, chi ha progettato cosa e come gli esperti sono allineati all'interno dei team.

    
risposta data 10.05.2018 - 00:41
fonte
5

L'API dovrebbe nascondere completamente il database. Indipendentemente dagli approcci SQL vs No-SQL.

Ciò significa che:

  • Il DB deve essere compilato tramite chiamate all'API.
  • I chiamanti dell'API non devono sapere quale sia l'implementazione del database

Quale "squadra" è responsabile dipende davvero dal trucco della tua azienda. Ma il design consente agli sviluppatori API (forse questo team include DBA?) Di mantenere il DB come parte dell'API. Piuttosto che il vecchio stile di avere un DB centrale utilizzato da molte applicazioni, dove DB Views e Sprocs erano essenzialmente la sua API

    
risposta data 27.04.2018 - 11:48
fonte

Leggi altre domande sui tag

DDD: decidere quando orientarsi verso l'eventuale coerenza transazionale Come decidere correttamente quale sia l'errore di arrotondamento appropriato per una funzione matematica?