Dilemma informatico e toposo

Situazione:

il cliente ha 4 db di nominativi da quattro fonti: amazon marketplace, facebook, ecommerce e gestionale del negozio fisico

i db andrebbero gestiti unitariamente al fine di attività analitiche e campagne di newsletter e sms

la parte relativa alla gestione dovrebbe essere automatizzata una volta per tutte

la parte relativa all'invio di newsletter e sms dovrebbe avvenire con un software professionale ma che possa essere gestito da un impiegato che non sia un informatico

https://cdn.barstoolsports.net/wp-co...03239199_n.jpg

Fai un file excel

Inviato dal mio PRA-LX1 utilizzando Tapatalk

https://cdn.barstoolsports.net/wp-co...03239199_n.jpg
.................................................. .....................................https://i.imgur.com/l17FgZd.png

https://orig00.deviantart.net/4243/f...misaki_chi.gif

Citazione:

---

Originariamente Scritto da NoNickName

Situazione:

il cliente ha 4 db di nominativi da quattro fonti: amazon marketplace, facebook, ecommerce e gestionale del negozio fisico

i db andrebbero gestiti unitariamente al fine di attività analitiche e campagne di newsletter e sms

la parte relativa alla gestione dovrebbe essere automatizzata una volta per tutte

la parte relativa all'invio di newsletter e sms dovrebbe avvenire con un software professionale ma che possa essere gestito da un impiegato che non sia un informatico

https://cdn.barstoolsports.net/wp-co...03239199_n.jpg

---

Fatti un server SQL express con db ben fatto, così i dati sono gestiti bene, poi valuti la strada da prendere per le newsletter.
Usi access lo colleghi e fai qualche maschera di gestione.
Ti fai un programma di gestione in c#
Lo colleghi ad un server web e usi un prodotto professionale a pagamento.

Secondo me sono le possibilità che hai.

è una collega?

Per la privacy non può

Per le mailing list io uso Mailchimp, editor facile ma potente, free fino a tot invii poi si paga a scaglioni
Per unire i DB fanne uno nuovo con tutti i campi necessari e poi select into XXX from db1 union select into XX from db2 etc etc

Metti SAP, fai un job di import dalle varie fonti e poi una BSP per gestire il database via web, isi :smuggeek:

Sono qui solo per dire che la signa di Nonickname, unita alla foto toposa, è spettacolare! :asd:

Dipende dal budget del cliente :uhm:

Per analitica e gestione, se intendi sempre relativamente al direct marketing, una volta sincronizzati e unificati i contatti te lo fa direttamente la piattaforma di invio. Basterebbe impostare dei job ogni giorno che estraggano i nuovi contatti :uhm: non dovrebbe servire nessun tipo di data integration vera e propria. Poi se vuoi mandare anche sms credo tu debba evitare sia robe tipo Mailchimp/Mailup ecc. sia l'invio in proprio (phpList), e capire i costi di piattaforme più evolute (es. magnews.it) :uhm: edit: ah per la creazione della newsletter non so magnews come funziona, in generale di solito ti mettono a disposizione un editor più o meno evoluto che anche un impiegato con medie conoscenze informatiche può usare. Però per fare una cosa fatta bene di solito ci si lavora in più persone (di nuovo, dipende dal cliente).

Se sta roba ti è utile poi ti mando fattura

Ti direi di mantenere le tabelle separate in un unico db e poi fatti una vista aggiungendo un campo che indichi la provenienza del record

le campagne di sms sono tipo i lavavetri al semaforo, con la differenza che che almeno puoi bloccare i mittenti e segnalarli come spam.

Tu faresti un nuovo db a parte? In ogni caso è la piattaforma di invio che deve gestire la presenza o meno degli utenti. Ad esempio se un cliente decide di non ricevere più la newsletter clicca nel footer e si disiscrive. La piattaforma (facciamo finta Mailchimp) lo cancella. Come recepisci questa info indietro? Riesportando ogni tot il db da Mailchimp?

Tra l'altro va gestita bene anche la disiscrizione a norma GDPR

infatti. ascolta il para che ne sa

Citazione:

---

Originariamente Scritto da Moloch

le campagne di sms sono tipo i lavavetri al semaforo, con la differenza che che almeno puoi bloccare i mittenti e segnalarli come spam.

---

this, extramadonna

Mah... io una roba simile l'ho fatta per uso interno.
Invio mail, sms e gestisco i client di 3 "succursali"

Ed ho usato MSQL per il DB, IIS per il server, ASP/JAVASCRIPT come linguaggio di scripting e HTML/CSS per il sito.
Essendo "internal use" ho dovuto fare una cosa veloce, funzionale anche se non bellissima stilisticamente parlando.
E sta li in funzione da qualche anno senza neanche 1secondo di Downtime.

Citazione:

---

Originariamente Scritto da KymyA

Mah... io una roba simile l'ho fatta per uso interno.
Invio mail, sms e gestisco i client di 3 "succursali"

Ed ho usato MSQL per il DB, IIS per il server, ASP/JAVASCRIPT come linguaggio di scripting e HTML/CSS per il sito.
Essendo "internal use" ho dovuto fare una cosa veloce, funzionale anche se non bellissima stilisticamente parlando.
E sta li in funzione da qualche anno senza neanche 1secondo di Downtime.

---

> mySQL
> IIS
> ASP

Cioè, usi anche qualcosa che non è lammerda o hai l'esclusiva?

Mi tocca quotare il collega MDK :sisi:
Soprattutto ASP e IIS :uhoh:

Citazione:

---

Originariamente Scritto da gnappinox1

Mi tocca quotare il collega MDK :sisi:
Soprattutto ASP e IIS :uhoh:

---

In effetti si dai, mySql l'ho buttato li solo per aggiungere alla failanza di Kymya

kymya linux di qua e di là e poi usa tutta roba merdasoft

A me per uno degli ultimi progetti per un cliente grosso, all'ultimo momento mi hanno rifilato un db mysql "perchè su AWS quello abbiamo" dopo che avevo fatto tutti gli script per MSSQL...

puveretoh! :trollface:

i db, che si gestiscano unitamente o meno sono dinamici anche nel senso di una cancellazione o modifica del dato utente

per cui il vero problema non sono le newsletter o gli sms quanto la possibilità di gestire unitamente quattro db dinamici, dopodichè il refresh si può fare anche ogni 6 ore ma l'importante che tutto il software funzioni senza intoppi

la questione del gdpr me la smazzo io, non è un problema

Citazione:

---

Originariamente Scritto da Mdk

> mySQL
> IIS
> ASP

Cioè, usi anche qualcosa che non è lammerda o hai l'esclusiva?

---

Disse quello che usa PHP :bua:

Citazione:

---

Originariamente Scritto da Leizar

Disse quello che usa PHP :bua:

---

Vuoi mettere PHP con ASP?
Apache con IIS?

Citazione:

---

Originariamente Scritto da NoNickName

i db, che si gestiscano unitamente o meno sono dinamici anche nel senso di una cancellazione o modifica del dato utente

per cui il vero problema non sono le newsletter o gli sms quanto la possibilità di gestire unitamente quattro db dinamici, dopodichè il refresh si può fare anche ogni 6 ore ma l'importante che tutto il software funzioni senza intoppi

la questione del gdpr me la smazzo io, non è un problema

---

Non capisco, i database sono dinamici per definizione, per il resto ripeti il punto di vista di un cliente (tutto deve funzionare, e grazie al cazzo :asd: ). Quindi? Non capisco cosa significa unitariamente, e cosa intendi per analytics. Se vuoi fare business intelligence su dati più o meno omogenei dovrai forse impostare un nuovo database che estragga ogni tot delle tabelle, non credo tu possa collegare un Business Objects direttamente a database diversi (che io sappia eh, ma non sono esperto). Se invece parli solo di direct marketing devi semplicemente esportare i nuovi clienti ogni tot verso la piattaforma di direct marketing. Non è che se un cliente si cancella dalla newsletter devi andare a toccare i suoi dati nei db facebook/amazon ecc. :uhm:

Citazione:

---

Originariamente Scritto da Mdk

Vuoi mettere PHP con ASP?
Apache con IIS?

---

Se è asp.net assolutamente sì.

Asp classico è roba che usavo all'itis quando ancora si facevano i sito con front page :asd:

Citazione:

---

Originariamente Scritto da Mdk

> mySQL
> IIS
> ASP

Cioè, usi anche qualcosa che non è lammerda o hai l'esclusiva?

---

Non è MySQL ma Microsoft SQL ...
..cmq fotteuncazzo visto che non sono un programmatore. Ma l'ho fatto comunque. SUCAMI_STA_FANTASTICA_MINCHIA

Citazione:

---

Originariamente Scritto da Para Noir

kymya linux di qua e di là e poi usa tutta roba merdasoft

---

Se in azienda hanno deciso per Nav (Microsoft), Office365 (Microsoft) etcetc non è colpa mia eh!

Ma tu non sei un EDP? Non dovresti essere tu che consigli cosa prendere? :uhm: comunque NAV non è male, se non devi gestire la produzione che devi aggiungere pacchetti custom a go go (almeno era così anni fa)

Citazione:

---

Originariamente Scritto da Para Noir

Ma tu non sei un EDP? Non dovresti essere tu che consigli cosa prendere? :uhm: comunque NAV non è male, se non devi gestire la produzione che devi aggiungere pacchetti custom a go go (almeno era così anni fa)

---

No... sono solo il resp.IT... per motivi che non ti sto a spiegare la scelta (costi implementazione, soprattutto) era tra NAV e SAP.
E si... la produzione era gestita da un software fatto ad hoc (un guanto, praticamente) che s'interfacciava con il gestionale. Tutto realtime. Ovviamente fatto da me.
Le cose che faceva il mio programma sto cazzo di nav se le sogna. (ottimizzazione tagli, movimentazione magazzino, priorità, calcolo tolleranze da di.ba., abbinamento sotto-prodotti, smarcamento con lettore barcode, etc..etc.. Non posso dare tutti i dettagli altrimenti si capisce dove lavoro)

Citazione:

---

Originariamente Scritto da KymyA

Non è MySQL ma Microsoft SQL ...
..cmq fotteuncazzo visto che non sono un programmatore. Ma l'ho fatto comunque. SUCAMI_STA_FANTASTICA_MINCHIA

---

Ah ok, quindi è effettivamente lammerda, ho fatto bene a menzionarlo

Te preferisci MariaDB? NoDB?

Citazione:

---

Originariamente Scritto da KymyA

No... sono solo il resp.IT... per motivi che non ti sto a spiegare la scelta (costi implementazione, soprattutto) era tra NAV e SAP.
E si... la produzione era gestita da un software fatto ad hoc (un guanto, praticamente) che s'interfacciava con il gestionale. Tutto realtime. Ovviamente fatto da me.
Le cose che faceva il mio programma sto cazzo di nav se le sogna. (ottimizzazione tagli, movimentazione magazzino, priorità, calcolo tolleranze da di.ba., abbinamento sotto-prodotti, smarcamento con lettore barcode, etc..etc.. Non posso dare tutti i dettagli altrimenti si capisce dove lavoro)

---

Notevole :snob:

Citazione:

---

Originariamente Scritto da Para Noir

Notevole :snob:

---

perculi? eh? :D

come avevo abbattuto gli errori di produzione con il mio programma non ne avete idea.
mostrava pure all'utente i kit da inserire insieme al prodotto e ne richiedeva il puntamento del barcode prima di far uscire l'etichetta dell'imballo.
avevo anche implementato una personalizzazione dell'etichetta per articolo, cliente, macchina, etc..etc..
Oltre alla stampa in automatico del foglietto di istruzioni a seconda del modello/variante dell'articolo
E, per superare i limiti del linguaggio della stampante (Zebra) ho anche implementato un MIO linguaggio... ad esempio un comando che, dato il rettangolo dove stampare e la stringa, utilizzasse il font più "coprente". O un altro comando per cambiare stampante a runtime, così da stampare l'etichetta da una parte e magari l'etichetta VOID su un'altra stampante..
VALLO A FARE IN NAV
tanta roba, giuro...

no ero serio :asd: per dove lavoravo prima una roba così CUSTOM sarebbe costata al cliente almeno 3k euro, per dire :asd: io lavoravo su gestionale proprietario, e dei collegi su roba MS. Quello che so è che NAV e AX sono come delle cipolle, tu compri il nucleo e tutti gli altri strati li devi aggiungere, specie per il mercato italiano per cui non sono fatti :asd:

Citazione:

---

Originariamente Scritto da Para Noir

Non capisco, i database sono dinamici per definizione, per il resto ripeti il punto di vista di un cliente (tutto deve funzionare, e grazie al cazzo :asd: ). Quindi? Non capisco cosa significa unitariamente, e cosa intendi per analytics. Se vuoi fare business intelligence su dati più o meno omogenei dovrai forse impostare un nuovo database che estragga ogni tot delle tabelle, non credo tu possa collegare un Business Objects direttamente a database diversi (che io sappia eh, ma non sono esperto). Se invece parli solo di direct marketing devi semplicemente esportare i nuovi clienti ogni tot verso la piattaforma di direct marketing. Non è che se un cliente si cancella dalla newsletter devi andare a toccare i suoi dati nei db facebook/amazon ecc. :uhm:

---

per db dinamici intendo dire che non si tratta di accorpare 4 db ma di sincronizzare 4 db in un unico db che poi rilevi anche le modifiche che avvengano sui 4 db

dopodichè se ritieni si possa esportare i db verso la piattaforma di marketing è un altro conto, magari Hootsuite lo sa fare

Ma Hootsuite non fa né newsletter né sms, è solo gestione social a quanto ne so :uhm: non sono sicuro che abbia senso recepire all'indietro anche le modifiche dei 4db originari. Una volta che hai avuto il consenso da una persona per ricevere attività di marketing diretto (newsletter e sms ecc.) secondo me poi devi gestirlo solo dalla piattaforma stessa (e non c'entra niente con i social, dove non targetti le singole persone). Ci sono siti dove puoi gestire tutto dal sito, ma in questo caso con 4 fonti diventa impensabile gestire le preferenze di marketing per ogni utente da ogni singolo punto di origine :uhm: o capisco male io o il cliente ha un'idea del cazzo

Mai capito noSQL...