Newsgroup: it.comp.www.php
Titolo: Consigli per costruzione sito social-commerciale

Salve,
 
non sarò io a farlo ma dovendo affidarmi a terzi vorrei prima di tutto 
avere le idee chiare io anche grazie ai Vostri consigli! :)
 
Il sito sarà una sorta di social legato al mondo commerciale, 
ipotizziamo di creare uno spazio dove gli utenti possano condividere i 
propri gusti commerciali ad esempio le marche e le tipologia di pasta 
che mangiano, quante volte etc.
 
Step successivo i produttori potranno gestire i loro prodotti ed infine 
anche coloro che li vendono potranno inserire i loro punti vendita.
 
Morale della favola pensavo ad un ambito L.A.M.P., essendo un utente 
Debian da anni per me il webserver è solo ed esclusivamente Linux!
 
Entrando nel merido del db pensavo di farne creare due distinti uno 
legato ai prodotti con un accesso tipo backpanel per i produttori, i 
venditori e l'admin in modo che il cuore del sistema ovvero i prodotti 
siano "al sicuro" e di veloce accesso e l'altro social per gli utenti 
finali che dialogherà con il db prodotti.
 
Saluti!
GabrieleMax
 

finali che dialogherà con il db prodotti.
 
Il database è uno: non è che ottieni granché mettendocene due, se non parecchi
grattacapi :-)
 
Come progettare il DB dovrà dirlo il DB Admin, dopo avere discusso a lungo con
qualcuno che abbia familiarità con la lista dei requisiti e le 'user stories',
per esempio "Sono il produttore della Pasta Pista, entro nel sito, vedo questo
e faccio quello", oppure - e questo è parecchio più importante - "sono l'umile
utente, mi collego al sito, cosa vedo? Cosa faccio - e come? E perché mi potrà
piacere farlo?".
 
Dal fatto che se ti piace la Pizza Pazza probabilmente ti interesserà sapere i
punti vendita nei dintorni discenderà la necessità di collegare le tabelle dei
punti vendita e quella dei prodotti (magari georeferenziare i PV - e qualsiasi
utente sarebbe interessatissimo a vedere i prezzi nei vari punti vendita, cosa
che sospetto i venditori non apprezzeranno più di tanto <grin>).
 
Ma sono tutte cose che devono venire fuori dalla fase di analisi, che non devi
fare tu, se no credi che le cose finiranno male :-). BTDTGTTS, come si dice.
 
Di database ne userai sicuramente due: ma perché uno è quello di produzione, e
uno è quello di staging dove farai i test - per esempio simulando un carico di
clienti bello péso, per vedere cosa fanno i tempi di risposta.
 
Leonardo e i suoi 0.02 EUR
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 
 
Lascia stare. Questa "idea" l'ho sentita centinaia di volte, ed è sempre
finita male, per centinaia motivi che non ti sto qui a dire (ma a cui
penso puoi arrivare anche te).
 
Invece di pensare a come far fare a un esperto (che quindi non ha bisogno
di un tuo parere "a sensazione") un lavoro inutile, mi concentrerei sullo
stilare uno studio di fattibilità. Risparmi soldi, tempo e fatica.
 
Ciao!

 Ciao!
 
Saluti!
GabrieleMax
 

 qualcosa non colpirai mai nulla!
 
Ti auguro buona fortuna, ma tieni conto che facebook ha iniziato a 
guadagnare qualcosa dopo che ha passato il miliardo di utenti, mentre 
snapchat sta collassando nonostante fosse "il social network del 
futuro", e twitter fatica a stare a galla.
 
La prima domanda che dovresti farti è: "perchè gli utenti dovrebbero 
usare il mio social invece degli altri?", subito seguita da "e quanti 
utenti posso sperare di avere?"
 
Bye.
 

 finali che dialogherà con il db prodotti. 
 
Non mi è chiaro. Uno "al sicuro" e di veloce accesso l'altro insicuro e di 
accesso lento?
I dati degli utenti in un database insicuro? ma sei sicuro?
Come pensi di differenziare le caratteristiche due db?
sono gestiti da due dbms diversi?
sono in due macchine diverse?
 
Ma soprattutto: cosa intendi per sicuro?
 
Ciao e buon lavoro

 ha scritto:

Hai già scritto cosa fare tu, dove sarebbero i punti su cui
chiedere consiglio?
 
 
 

 Bye.
 
Saluti!
GabrieleMax
 

 
 
Ripeto, e lo dico per te: è 'na ca**ata.
 
Non bisogna pensare: fai uno studio sui potenziali clienti, quelli che
ti danno il cash. Non si tirano su businesses tanto per fare, solo perché
c'è un'idea, si tira su un'attività perché c'è un qualche tipo di
domanda. E' la ca**o di base.
 
Anche tu fossi nella condizione di non doverti preoccupare dei soldi,
pensa al tuo tempo: potresti impiegarlo in cose assai più prolifiche.
 
Se poi vuoi andare avanti oh, in bocca al lupo.
Però la mia risposta alla tua domanda iniziale rimane uguale.
 
Ciao!

 Ciao e buon lavoro
 
Saluti, grazie per il tempo dedicatomi e tengo ancora a precisare che i 
miei sono solo pensieri quindi posso ovvimanente anche aver palesato 
immani cavolate a livello tecnico.
 
GabrieleMax
 

 la stessa per entrambi.
 
Pensare a una divisione per permettere in futuro di ubicare una parte dei dati 
in un server apposito è giusta, in questo modo nel momento del cambiamento
il software avrà una necessità molto ridotta se non nulla di aggiornamento. 
Per contro non puoi fare una query con tabelle di due db diversi 
in previsione che siano su macchine diverse.
Il ché è limitante e richiede maggiore programmazione e riduci la scalabilità.
 
Io, in un progetto sperimentale, lo eviterei, perché se l'idea è davvero 
buona e redditizia dovrai sicuramente farlo rifare da capo da professionisti 
tra cui te nel tuo ruolo abituale (se ti va di risparmiare).
 
Non ti offendere, ma in solitaria non si possono più creare un certo tipo di sw.
Sono richiesti esperti in grafica (desk e mobile), esperti di usabilità, 
un paio di programmatori lato server, uno per quel troiaio di js, 
consulenze su hw, db...
Guarda quel troiaio immondo di eBay, in realtà una volta ingranato venti anni fa
dovevano buttarlo via e farlo come si deve e invece hanno continuato ad 
aggregare ciarpame su altro ciarpame.
 
Tornando noi, ti consiglio un solo db, studiati le caratteristiche dei vari 
dbms  relazionali e noslq e poi scegli, da qui un consiglio ce l'avrai sempre.

 aggregare ciarpame su altro ciarpame.
 
Hai sollevato un argomento importante.
 
Se Gabriele è proprio deciso ad andare avanti, allora la proof of 
concept la farei con un singolo DB, senza pensare troppo a prestazioni, 
scalabilità, sicurezza, ecc.
 
Io, onestamente, andrei su MongoDB perchè è più flessibile, anche se 
"perdi" l'integrità referenziale.
 
Nel momento in cui la piattaforma ingrana va comunque messo in conto di 
doverla riscrivere. O per intero o pezzo per pezzo.
 
A quel punto si può iniziare a parlare di architettura: scegliere i DB 
(plurale) in base alle esigenze di ogni componente, scegliere i server, 
il layer di orchestration, il monitoring, le politiche di backup.
 
È abbastanza inutile pensare a queste cose prima ancora di sapere quanti 
utenti ci saranno, quanto traffico fanno, quante aziende clienti 
potranno accedere, quanti prodotti caricheranno, cosa chiederanno di 
implementare, ecc.
 
Bye.
 

 dbms  relazionali e noslq e poi scegli, da qui un consiglio ce l'avrai sempre.
 
Grazie per il tempo dedicato alle risposte ed anche per tutti i consigli! :)
 
Saluti!
GabrieleMax

 Bye.
 
Saluti!
GabrieleMax

 rivisitazioni.
 
Attento a non confondere quello che vedi con quello che c'è sotto.
 
Per esempio, mi pare fosse Twitter, ha cambiato tutto il backend almeno 
due volte, passando da Ruby a Java a Scala e da Postgres a Mongo a 
Cassandra (o qualcosa del genere), mantenendo l'interfaccia quasi identica.
 
Facebook ha scritto una VM apposta (HHVM) e creato un linguaggio (Hack), 
oltre a un framework per il frontend (React) e diverse altre cose.
 
Se ci fai caso, a ogni minima modifica dell'interfaccia di qualcosa di 
minimamente famoso c'è una sollevazione popolare, con petizioni, 
raccolte firme e campagne di boicottaggio.
 
Mentre se cambi il DB o il linguaggio di programmazione non se ne 
accorge nessuno.
 
Ecco perchè preferisco fare il backender che il frontender :P
 
Bye.

 dovrei iniziare una seria ricerca!
 
Perfetto. Con 2000 euro puoi partire con la tua idea e se funziona: preparati.
 
Per rimanere in ambito db io in genere uso postgres e mysql perché sono 
belli "legnosi" e mi permettono di avere consistenza (mysql un po' meno). 
I NoSQL hanno proprio la caratteristica di non offrire vincoli alla struttura 
dei singoli record e la consistenza dei dati è demandata al tuo software, 
quindi delirio (non perché lo scrivi te o gli indiani, ma proprio perché è 
facile perdersi per chiunque).
Però in certi compiti è perfetto, perché velocissimo e di conseguenza 
scala bene, basta dargli un bel po' di ram.
 
L'unica cosa riguarda il "rinunciare alla sicurezza", Alessandro si riferiva 
a una demo. So che lo sai, ma meglio essere ridondanti.

 a una demo. So che lo sai, ma meglio essere ridondanti.
 
Vero, mi rendo conto che non ho spiegato bene, e la sicurezza è importante.
 
Mi riferivo soprattutto al fatto di non mettersi a creare utenti 
separati o DB separati sul DB-server, perchè complicano solo la vita.
 
Crea un database con un utente (non "root senza password" come di 
default in MySQL :D) e gestisci i permessi lato PHP.
 
Bye.

 seria! :D
 
-.-
 
 

 
 
Se la differenza di prezzo a pari qualità gliela paghi te, penso non
obietterebbe a prendere italiani :)
 
Ciao!

 Ciao!
 
Saluti.
GabrieleMax
 
 

 
 
Senza contare che probabilmente in Italia si prendono i 7mila, passano
il lavoro in india a 2mila, e l'avanzo se lo tengono senza aver fatto
nulla.
 
 
Ciao!

 nemmeno provarci...
 
Un qualsiasi "sogno" per definizione richiede un impegno da "sogno", appunto.
Altrimenti non è un sogno.
 
 

 nulla.
 
Allo stesso modo in india possono prendere i 7 mila e girare il lavoro
sempre in india od in cina a 1000 euro, "e l'avanzo se lo tengono
senza aver fatto nulla". Nessuno può sapere come opereranno... 
 
 


 
... ma grazie al meraviglioso mondo di Internet ognuno può cercare,
valutare e mettere sotto contratto chiunque nel mondo, così italiani e
indiani che "rigirano" lavori se la prendono in saccoccia.
 
Ciao!

 senza aver fatto nulla". Nessuno può sapere come opereranno...
 
Come già detto non sono uno sprovveduto in ambito informatico, realizzo 
siti internet da quando c'era il modem a 14.4, ovvio oggi è tutta 
un'altra storia ci mancherebbe volessi confrontare il web di 22 anni fa 
con quello di oggi ma se mi dai dei files in php, un database sql, 
qualche script riesco a capire se questi sono fatti male, discretamente 
benem, etc. e capisco anche se e quando mi dovessero sparare un prezzo 
allucinante semplicemente per una query che tiri su dei dati da una 
stupida tabella con 4 campi in croce!
 
Il motivo per cui io mi "limito" a dirigere i lavori o quantomeno a dare 
delle linee guida è perchè non ho materialmente tempo per scrivere le 
pagine e almeno inizialmente solo per provarci non ho intenzione di 
spendere 7mila euro.
 
Saluti.
GabrieleMax