Memorizzazione dei dati in 2 diversi sistemi / strutture di database

Question

Memorizzazione dei dati in 2 diversi sistemi / strutture di database

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

2

La mia azienda è un rivenditore online e utilizziamo una piattaforma di e-commerce homebrew. Nell'ultimo anno circa, abbiamo collaborato con un fornitore di software di contabilità, poiché la nostra soluzione homebrew non è stata in grado di produrre report in base alle esigenze o soddisfare in altro modo le richieste di banche e investitori.

Siamo partiti con il software, ma mi chiedo se sia il nostro approccio. Attualmente, archiviamo un set completo di dati nel database collegato alla nostra piattaforma di e-commerce. Ogni notte inviamo le necessarie chiamate API per sincronizzare le nostre entità nel software di contabilità (ordini, ordini di acquisto, fatture, ecc.) E ogni mattina ho creato script che convalidano che i dati siano corretti tra i due sistemi. Questo sistema collettivo è stato un incubo, poiché qualsiasi piccola console verso la piattaforma di e-commerce si abbatte in modi violenti e orribili per il sistema B. Ne consegue una tonnellata di lavoro da parte mia per apportare correzioni su base giornaliera.

Esiste un modo corretto per affrontare questo problema? Oppure il problema sta davvero a monte, nella nostra decisione di duplicare i dati tra i due sistemi. Qualcuno ha fatto qualcosa di simile?

È stata una esercitazione antincendio non-stop per 3 mesi, e ogni consiglio sarebbe molto apprezzato.

data e-commerce

posta aaronsnyder 20.06.2013 - 20:24

fonte

3 risposte

Leggi altre domande sui tag data e-commerce

Recupero complesso di oggetti di dominio Come faccio a sapere quando dovrei impacchettare le mie lezioni in Ruby?

score 1 · Answer 1

La descrizione generale dell'architettura non suggerisce "cattiva". Non penso che qualcosa del genere sia addirittura raro avere schemi / database separati per ogni funzione aziendale (la contabilità è separata dalle vendite / marketing) in quanto rispetta determinati principi e responsabilità di proprietà dei dati.

Il problema che sembra che tu stia avendo è che il sito di ecomm è troppo disconnesso dalla sincronizzazione di mappatura che coordina con il sistema accnt.

La sincronizzazione della mappatura è sviluppata utilizzando codice condiviso / riutilizzato o è completamente divergente, forse prodotta in una lingua diversa e in esecuzione in un contesto / ambiente operativo diverso (ad esempio ecomm principale in Php, mentre mapping-sync è in Perl ?

Probabilmente la sincronizzazione della mappatura non sta prendendo decisioni sui dati, ma semplicemente trasformandoli e trasmettendoli. È possibile mantenere questo processo meglio allineato con il lato ecomm analizzando i bit ecomm rilevanti che descrivono le strutture e i vincoli dei dati e generando i bit collegabili per il lato sync di mappatura, in modo tale che qualsiasi modifica al lato di ecomm sarà quasi automaticamente si rifletta nella sincronizzazione della mappatura.

score 0 · Answer 2

Perché duplicare i dati oggi ed età quando puoi semplicemente passare a un'architettura orientata ai servizi? Chiedere al sistema contabile di mettere un servizio Web sui propri dati, quindi chiamare il sistema quando ha bisogno di determinate informazioni e viceversa. Non memorizzare affatto le entità nel tuo database. Se è necessario fare riferimento a un record dal sistema di contabilità, memorizzare una chiave o un token. Quindi, lascia che il livello di servizio / controller si occupi di riassemblare i dati effettuando chiamate al servizio web per compilare i pezzi mancanti.

score 0 · Answer 3

Devi modificare le tue procedure di sviluppo e controllo qualità.

Hai una dipendenza dalla contabilità per l'e-commerce. Che va bene Ma ciò significa che non sei più libero di apportare modifiche al sistema di e-commerce senza considerare il sistema di contabilità.

Le modifiche apportate al sistema di e-commerce ora devono essere valutate e testate per il loro effetto sugli script di sincronizzazione e sul sistema di contabilità PRIMA che entrano in produzione.