Ti supporto molto volentieri (sempre entro i miei limiti che sono molti) e non hai nienteNiente false modestie, si capisce che ne sai e mi fa piacere discuterne con te :D
di cui scusarti. Esperto ???
La premessa fatta all'inizio della mia precedente risposta era per capire se doveva essere un'esempio per il tuo libro,Mi sono espresso male intendevo dare qualche spunto, indicazione ma non inserirlo nell'esempio di database, il database deve essere funzionale alla spiegazione degli aspetti più importanti.
e nel caso secondo me sarebbe stato sufficente il classico esempio della rubrica telefonica arrichita magari da funzioni
che non trovi negli esempi in giro che tentano di spiegare un database, anche per differenziarti da quelli che tu chiami
"banali" (tua citazione post di apertura).
Ti semplificherebbe la vita nel parlare di relazioni una a uno o uno a molti, chiavi primarie, indici, ecc... volendo spiegare
un database (questo vuoi ottenere, giusto?), avendo scelto come esempio un "piccolo gestionale" secondo me ti sei un
pochino complicato la vita, nel senso che non puoi prescindere dall'inserire certe informazioni e certe relazioni per renderlo
un minimo funzionale, anche se poi parli di importare listini e altre funzioni che non sono proprio minimali.
Rispondendo alle tue osservazioni:
Tabella clienti - per quanto riguarda le informazioni di contatto (telefoni, email, fax, ecc...) per me vanno inserite in questa
tabella essendo quelle di base per avere un minimo di informazioni del cliente, eventuali altre figure da contattare (magazzino,
ufficio acquisti, ecc...) dovresti prevedere una rubrica contatti legata ai clienti/fornitori, ma penso che esuli dal tuo intento.
Ti assicuro che questo è il minimo, il gestionale che uso nell'azienda in cui lavoro solo l'anagrafica clienti è composta da dieci
form di informazioni da compilare, ma prevede un sistema di semplificazione quando si codifica un nuovo cliente.
Tabella ordini - a me hanno sempre insegnato che non va usato l'ID se non in certi casi, presumo tu faccia riferimento a questoGiuro che non l'ho mai visto io ho sempre visto il "numero" (text) di ordine che era anche chiave primaria (PK)
quando parli di numero e chiave primaria. Uno è l'ID che identifica in modo univoco l'ordine, ma nell'uso pratico dei gestionali si
usa una numerazione "personale" o se vuoi convenzionale, per esempio tipo questa 15/0056 che identifica anno e numero ordine.
Il totale inserito in testata è il totale dell'intero ordine, quello nelle righe è il totale della singola riga.Ridondante non c'entra, mi sono espresso male anche qui, devo stare più attento a quello che scrivo altrimenti se non riesco a farmi capire da te che ne sai figurati da chi non ne sa :rolleyes:
Non è una ridondanza il totale riga singola e dato da prezzo_unitarioxscontoxquantità_venduta. Senza la quantità come
fai a calcolare i totali?
Per qunto riguarda i campi calcolati il discorso è lungo se inserirli o meno in una tabella.E no questa non te la abbuono, non te la puoi cavare così :violent: Spiegati
Le righe omaggio sono di due tipi "Sconto Merce" è l'iva te la paghi tu o "Omaggio" è l'iva la paga il cliente.Giusto non ho pensato che se hai un campo REAL non puoi infilarci TEXT (in realtà SQLite fa proprio così ma noi dobbiamo insegnare...)
Unità di Misura all'interno della descrizione? Non ho capito.Ma se ti ho fatto l'esempio...
Per quanto riguarda l'identificazione del fornitore, quello che tu hai citato è lo stesso sistema che utilizziamo in azienda da noiOhhh finalmente qualcosa che combacia, anche se vedo che manca il trattino :rotfl:
e che io ho adottato.Il fornitore è identificato da tre lettere prese dalla ragione sociale dello stesso, per esempio:
Ragione Sociale = Fornitore Beni
Abbrevazione Fornitore = FOB
il campo noi lo chiamiamo Abbrevazione Fornitore ed è conposto da quattro caratteri, ma ne usiamo normalmente tre.
Con questo sistema Abbreviazione Fornitore+Riferimento Articolo (o Codice Articolo) identifichi in modo univoco
l'articolo.
A proposito di database...finisco qui o rischiamo di essere sbattuti fuori per intasamento del database del Forum... ;D
@ Gianluigi
Ho letto, passo dopo passo, tutta la discussione svolta fino ad oggi ed ho resistito a parteciparvi. Dopo l'uiltima lettura non ce l'ho fatta più ed eccomi qua.
Anche se non mi sento ferrato in materia di DB, penso di dire ugualmente la mia, poi deciderai tu. Il libro infatti è tuo e tu solo sai come dovrà essere organizzato.
La mia esperienza sulla strutturazione dei DB ha impattato qualche anno fa con i DB SQLite, perchè quello non è un vero e proprio globo da DB. Ho cercato all'epoca di applicare tante delle nozioni conosciute per costruire il mio DB in ContabFam e ricordo di avere preso tanti pesci in faccia che ancora, odorandomi, ne sento le maleodoranti esalazioni.
Ho dovuto rinunciare a chiavi primarie e secondarie, nonchè a indici. Ho dovuto per forza di cose impiantare una chiave univoca per singola tabella coincidente col codice ID della stessa. L'unica organizzazione che ho potuto dare è stata quella della relazionalità, legando le tabelle fra di loro soltanto concettualmente: richiamando di volta in volta quelle colonne che mi interessavano.
A parte SQLite, pensando ad ambienti operativi legati a singoli pc, non mi pare che fino ad oggi, ne siano consentiti altri. Diversamente, in ambienti operativi di tipo Server, le cose cambiano perchè esistono anche MySQL, PostgreSQL, Firebird, ODBC.
Quindi, se permetti, ti esorterei a valutare a quale ambiente operativo tu voglia destinare il tuo libro e poi decidere sul tipo di struttura di DB a cui orientarti. Purtroppo se il tuo indirizzamento dovesse rimanere sull'ambiente operativo di singolo pc, allora l'unica bestia strutturale che ti rimane è quell'idecoroso SQLite3.
Perchè indecoroso? Perchè a parte le citazioni riportate sopra, gestisce tutte le colonne di una tabella nel formato String; ciò significa che quando andrai a definire una colonna nel formato integer o boolean, o byte o short o Float, il software incaricato a leggere/scrivere un DB, procederà di sua sponte a trasformare i vari dati nell'unico formato accettato e cioè nel formato String.
Saputo ciò, puoi procedere ad organizzare il tuo DB minimale esattamente come lo vuoi pensare TU, tanto per scrivere un esempio di DB non è necessario dare vita ad una struttura complicata con tutte le tabelle professionalmente necessarie, ma solamente a quelle tabelle che serviranno per costruire l'esempio campione che renda l'idea di come pensare un DB relazionale. L'imporatnte è tenere conto a non ripetere, se non che per la o le colonne chiave, dati che occuperebbero solo spazio inutile e di memoria di disco e di programma, ma anche comporterebbero lungaggini procedurali.
Detto questo ti lascio, perchè, fuori dalla mia quarantena, sto prendendo freddo. :)
Caratteristica di un software che può eseguire i compiti per cui è preposto senza che siano richiesti altri componenti.Ho usato questo termine in modo improprio per dirti semplicemente che uso MySql anche per programmi che girano solo su un
Standalone, la cui traduzione letterale dall'inglese è autonomo, indica generalmente qualcosa in grado di funzionare "da solo".
Per questo motivo, un programma è detto standalone quando è in grado di avviarsi senza necessitare della procedura di installazione.
ho usato l'aggettivo standalone (ma è un aggettivo ???) senza manco accorgermi di averlo fatto.
Questo il suo significatoCitazioneCaratteristica di un software che può eseguire i compiti per cui è preposto senza che siano richiesti altri componenti.
Standalone, la cui traduzione letterale dall'inglese è autonomo, indica generalmente qualcosa in grado di funzionare "da solo".
Per questo motivo, un programma è detto standalone quando è in grado di avviarsi senza necessitare della procedura di installazione.
stand-alone : da solo, automatico. Si dice di un sistema informatico funzionante in modo autonomo, non essendo connesso o dipendente da unIn definitiva un pc non attaccato informaticamente ad una rete locale o intranet , è un pc stand-alone, mentre un sistema con due o più pc di cui il principale è un server, mentre tutti gli altri, logicamente connessi ad esso, sono chiamati client a costituiscono il cosiddetto mmodello client/server.
computer principale.
io non ho mai preso in considerazione MySql e tanto meno PostgreSQL di cui so... praticamente niente.
Sono interessatissimo a questi database (sinceramente più a PostgreSQL anche se deve essere tostissimo avendo una logica diversa rispetto ai database relazionali classici) ma non trovi che per introdurre una persona che nulla sa di programmazione e database a questi tipi nati per servire dei client, ci voglia gente con...
Dim i As Integer
For i = 1 To 10000000 ' :)))))))))
Print "Hurrà";; "Bene";; "Viva"
Next.....In definitiva un pc non attaccato informaticamente ad una rete locale o intranet , è un pc stand-alone, mentre un sistema con due o più pc di cui il principale è un server, mentre tutti gli altri, logicamente connessi ad esso, sono chiamati client a costituiscono il cosiddetto mmodello client/server.Nell' accezione hardware e come dici tu.
Scusate se non sono stato sufficientemente tecnico nell'esposizione di un concetto per me planetario, ma meglio non ho saputo fare. :-\
Ciao a tutti e due.
Passando alla struttura del DB concordo con le osservazioni fatte da Tornu, alle quali aggiungerei che relativamente agli articoli bisognerebbe prevedere la gestione delle confezioni e delle promozioni. Ti faccio un esempio pratico.Con Gianluigi non sono andato molto in profondità visto il suo intento, ma se c'è la volontà..., a quello che hai detto con cui sono pienemente d'accordo, aggiungo che hai introdotto il concetto di "confezione" che può avere vari aspetti sia in fase di vendita ma
Le fascette metalliche che si utilizzano per fissare i raccordi in gomma, possono essere vendute singolarmente, in confezioni da 10 da 20 o da 100; in pratica lo stesso articolo (la fascetta) diventa più articoli differenti (x10, x20, x100).
Tabella Articoli:Anche più di uno, è la possibilità di generarne uno automaticamente da programma se il fornitore non lo prevvede.
includerei un campo per il codice a barre.
il campo Art_Iva lo trasformerei in FK sulla tabella Aliquote che contiene le aliquote iva.
Tabella Testata Ordini::ok:
introdurrei i campi Data_Creazione e Data_Evasione
Tabella Clienti:Sono d'accorto con te, era per semplificare, in questo caso bisogna introdurre una gestione di politiche di acquisto e vendita legate alle categorie merceologiche.
non userei il campo Cli_Sconto in quanto la percentuale di sconto può variare in base all'articolo; una minuteria può godere di uno sconto diverso rispetto ad un utensile o un macchinario. Bisognerebbe prevedere una struttura di tabelle per gestire le scontistiche dei clienti in base alle categorie merceologiche.
No. Non credo tu voglia scrivere la Bibbia della progettazione database, materia complessa ed il cui studio non finisce mai, sono però convinto che sia meglio iniziare con gli strumenti giusti.La penso come te. Credo che Gianluigi abbia capito cosa intendevo con le mie varie risposte alle sue perplessità, perchè avvolte volendo
Il progetto mi interessa e sicuramente nei limiti delle mie conoscenze e del tempo disponibili parteciperò.Io non sò se per un progetto tale con tutti i limiti che possiamo avere, ma comunque cercando di realizzarlo al meglio delle nostre
Caro Gianluigi, premesso che non sono assolutamente un esperto, semmai un eterno principiante, innanzitutto apprezzo il tuo entusiasmo ed in secondo luogo il desiderio di scrivere questo manuale. Il progetto, oltre che propedeutico rappresenta un'occasione di collaborazione ed aggregazione del forum.
Veniamo all'oggetto della discussione.
PostgreSQL, se opterai per questo DB, lo puoi installare quasi certamente da gestore dei pacchetti, semmai dovremo spenderere qualche riga (nel manuale) circa la configurazione degli accessi, che risulta appena un poco più complicata rispetto MySQL.
La scelta dell' utente la trovo molto valida, un campo molto vasto e di articoli diversificati. Perlomeno non è la solita biblioteca o concessionaria di auto...
Per quanto riguarda la struttura del DB procederei per passi; partendo da una molto semplice, magari anche con qualche errore o carenze, per poi svilupparla passo passo, introducendo le migliorie e le correzzioni necessarie alla compressione dei concetti espressi.
Per meglio capirci, inizialmente per introdurre il concetto di relazione una tabella Cliente con i soli campi: Id, Ragione Sociale, Indirizzo, Comune, Cap e Telefono potrebbe bastare. In seguito la completermo aggiungendo i campi necessari (PartitaIva, CodiceFiscale, ...)
Coraggio Capitano parti alla guida della tua truppa...
Passando alla struttura del DB concordo con le osservazioni fatte da Tornu, alle quali aggiungerei che relativamente agli articoli bisognerebbe prevedere la gestione delle confezioni e delle promozioni. Ti faccio un esempio pratico.Con Gianluigi non sono andato molto in profondità visto il suo intento, ma se c'è la volontà..., a quello che hai detto con cui sono pienemente d'accordo, aggiungo che hai introdotto il concetto di "confezione" che può avere vari aspetti sia in fase di vendita ma
Le fascette metalliche che si utilizzano per fissare i raccordi in gomma, possono essere vendute singolarmente, in confezioni da 10 da 20 o da 100; in pratica lo stesso articolo (la fascetta) diventa più articoli differenti (x10, x20, x100).
anche in fase di acquisto. Uno per esempio è questo: acquisto in confezioni da 100 Pz. (confezione minima di acquisto) a seconda
del fornitore può avere il prezzo per confezione oppure per unità della stessa, e io vendo a pezzi singoli.
Non sono d'accordo sul discorso che l'articolo se è in confezioni (imballo) diverse diventi più articoli, in questo caso siccome l'articolo
è sempre lo stesso anche se in imballi diversi il discorso si può gestire implementando l'uso di funzioni come il moltiplicatore quantità o il fattore di conversione.
Siamo d'accordo no si usa la Ferrari (PostgreSQL).CitazioneIl progetto mi interessa e sicuramente nei limiti delle mie conoscenze e del tempo disponibili parteciperò.Io non sò se per un progetto tale con tutti i limiti che possiamo avere, ma comunque cercando di realizzarlo al meglio delle nostre
conoscenze si possa fare con SQLite, che come ho detto io non conosco, altrimenti il primo passo è quello di decidere su quale
database, ed in ogni caso potrebbe essere una discussione molto interessante (almeno per me) da cui Gianluigi in ogni caso
potrebbe trarre spunti da una "applicazione reale" per i suoi esempi da riportare sul libro.
Ciao tornu,Grazie per le spiegazioni, non ho detto che approvo PostgreSQL, ma come ha detto sotema visto che ognuno di noi conosce un database diverso, nessun problema, non l'ho mai provato con Gambas leggo ogni tanto documentazione che lo riguarda come
vedo che approvi PostgreSQL :D :D :D
Aggiungo PK = Primary Key, CPK = Composite Primary Key, CPK/FK Composite Primary Key/Foreign Key
Per disegnare i database io uso 1 lato UNO e M lato MOLTI ma è errato occorrerebbe usare N. I più tanti usano disegnare una
riga che unisce le chiavi con una forchetta a tre punte lato molti e una barra che interseca la riga lato uno.
Caspita :o Gianluigi, se già arrivato ai modelli di DDT e Fattura... ;)
[/quote
Cavolicchio, mi viene il dubbio che Gianluigi voglia scrivere il gestionale per un suo cliente e ci stia sfruttando... ;D
Scherzi a parte, propongo di fare una pausa e focalizzare l'obiettivo. Sono cose completamente diverse scrivere un manuale per lo studio dei DB e progettare un gestionale.
In qualità di Team Leader ti spetta la responsabilità di guidare le scelte e decidere la strategia. :P
Caspita :o Gianluigi, se già arrivato ai modelli di DDT e Fattura... ;)
Cavolicchio, mi viene il dubbio che Gianluigi voglia scrivere il gestionale per un suo cliente e ci stia sfruttando... ;D
In qualità di Team Leader ti spetta la responsabilità di guidare le scelte e decidere la strategia. :P
Scherzi a parte, propongo di fare una pausa e focalizzare l'obiettivo. Sono cose completamente diverse scrivere un manuale per lo studio dei DB e progettare un gestionale.
Sono d'accordo con te. :ok:
Grazie per le spiegazioni, non ho detto che approvo PostgreSQL
...
ma come tu stesso hai detto andiamo per gradi, quindi teniamole presenti e le esaminiamo più avanti. Io direi se siete d'accordo per prima cosa installiamo il DB scelto, proviamolo con
Gambas anche con un piccolo progetto test, scambiamoci documentazione a riguardo se qualcuno già ne possiede e andiamo
avanti, che ne pensate?
Caspita :o Gianluigi, se già arrivato ai modelli di DDT e Fattura... ;)
sudo -u postgres psql template1
ALTER USER postgres WITH PASSWORD 'miapassword';
\q
Public $myconn As New Connection
Public Sub Connect()
$myconn.Close
With $myconn
.Type = "postgresql"
.Host = "127.0.0.1"
.Name = "MioDatabase"
.Login = "postgres"
.Password = "MiaPassword"
.port = "5432"
End With
Try $myconn.Open()
If Error Then $myconn.Close()
Catch
Message.Error("Connessione non riuscita")
End Così mi connetto con gambasCodice: [Seleziona]
Public $myconn As New Connection
Public Sub Connect()
$myconn.Close
With $myconn
.Type = "postgresql"
.Host = "127.0.0.1"
.Name = "MioDatabase"
.Login = "postgres"
.Password = "MiaPassword"
.port = "5432"
End With
Try $myconn.Open()
If Error Then $myconn.Close()
Catch
Message.Error("Connessione non riuscita")
End
Se avete bisogno son quà :2birre:
Ciao Golia,
ben ritrovato, mi fa piacere il tuo intervento, se vuoi salire a bordo di questa...avventura... a me fà molto piacere,
ma son sicuro anche agli altri, visto che se non ricordo male hai sviluppato "tanto tempo fà" un piccolo gestionale
per uso tuo personale che non so se usi ancora condividendo con il Forum la tua esperienza. Guardando il codice
che hai postato per collegare Gambas a PostgreSql o notato che è praticamente identico al sistema che uso io per
MySql, appena installo PgSql lo provo.
Ne approfitto è faccio qui la domanda, in attesa di fare una ricerca, magari qualcuno di voi mi risponde al volo:
posso avere MySql e PostgreSql nello stesso computer, e visto che ho installato PhpMyAdmin per gestire MySql
è compatibile con PgSql.
Golia, grazie per la disponibilità. :ciao:
.... cercherò di stendere una piccola guida.
Ciao
Io uso Postgres da qualche anno e mi trovo molto bene.
...
La stessa sintassi per connettere un MySql o PgSQL dipende dal fatto che Gambas crea un layer indipendente dal db in uso, il lavoro sporco viene svolto dal componente gb.db, che carica il driver corretto a seconda del valore di Connection.Type.
Vorrei però far presente che l'installazione di PostgreSQL, è leggeremente più articolata e richiede alcuni passi supplementari. Se lo scopo è quello di produrre una guida per principianti allora dovremo fornire le indicazioni più esaurienti possibile. Nel fine settimana, non vogliatemene, cercherò di stendere una piccola guida.Va bene allora aspetto la tua guida prima di installarlo, potrei approfittare di questa breve pausa per andare a fare qualche altra domanda al nostro cliente, ti viene in mente qualcosa? Qualche documento interessante oltre alle bolle e le fatture?
ti viene in mente qualcosa? Qualche documento interessante oltre alle bolle e le fatture?Preventivo
Porca miseria mi sono dimenticato di farmi dare i listini, vorrei sapere dove ho la testa ultimamente... :rolleyes:
:ciao:
e visto che ho installato PhpMyAdmin per gestire MySqlSinceramente penso che phpmyadmin non sia compatibile con pg .... però alzo le mani :-\
è compatibile con PgSql.
@Sotema,
mi hai chiesto di ritirare dal cliente il modulo dei preventivi, intendi le stampe delle offerte che inviano per fax o e-mail?
Quando sono andato l'ultima volta, il titolare era indeciso se vendere anche al dettaglio, potrebbe darsi che decida per il si durante il nostro lavoro cosa consigli ne teniamo già conto?Sarebbe la prima volta che la progettazione di una base dati determina le esigenze e le politiche commerciali di un cliente ;D
Invece per le riparazioni non gliel'ho proprio chiesto, se fosse indeciso e mi chiedesse consiglio?
Ok li ritiro appena vado e poi li posto.
Intendevo proprio quello, la possibilità di stampare un preventivo di spesa a fronte della richiesta di un cliente.
Sarebbe la prima volta che la progettazione di una base dati determina le esigenze e le politiche commerciali di un cliente ;DBe è anche la prima volta che un hobbit commissiona un gestionale. :D Sai come sono estrosi e poi lui è particolare vende quasi più agli elfi che agli hobbit e umani.
...
Scusa ma se il sig, Manicotto Indeciso, si chiama così il titolare della Rubinetto Felice, non sa cosa fa la sua azienda, come possiamo fornirgli un gestionale?
La vendita al dettaglio comporta problematiche aggiuntive quali l'emissione di documenti fiscali al privato (Scontrino Fiscale o Ricevuta Fiscale) e di conseguenza la gestione dei Corrispettivi Giornalieri di Cassa. La gestione del magazzino deve prevedere lo scarico automatico magari tramite lettore di codice a barre del singolo prodotto venduto al banco; inversamente nella vendita all'ingrosso lo scarico può essere effettuato all'atto dell'emissione del documento di trasporto (DDT o Fattura Accompagnatoria).
Ancora, la vendita al privato comporta la presenza di un negozio, magari distaccato dalla sede aziendale, connesso al Server (ulteriori utenti)
Quindi occorre che decidiamo prima che io ci torni, cosa pensi potrebbe essere utile ai fini didattici aprirgli un negozio e fargli fare riparazioni?
Cari sotema e tornu,fermati un secondo, ancora non abbiamo abbozzato la struttura del DB e già pensi alle fatture, venale si ma con garbo... 8)
questi giorni ho davvero poco tempo da dedicare al gestionale appena posso posto i nuovi documenti acquisiti, se avete qualche domanda per il Geom. Manicotto fatemele avere prima che vada a trovarlo.
mi sarei aspettato curiosa ed entusiasta partecipazione.
Non ti piace più il database, non vuoi scoprire cose nuove?
Vista la tua esperienza contavo in un tuo aiuto sul lato della contabilità, la dove io sono completamente digiuno.
Prendo le difese di Picavbg, anche se non credo ne abbia bisogno, cui riconosco la sobrietà e l'onestà intellettuale di forzarti a riflettere sul fine che ti eri posto e che invero abbiamo abbandonato. Non credere che ci stia ripensando, le sfide mi hanno da sempre galvanizzato, ma il buon Picavbg ha posto l'attenzione sul vero problema. Il sentiero nel quale ci stiamo addentrando si rivelerà presto un' autostrada a numerose corsie, cosa che non deve certo spaventare (come ci ricorda lo stesso Picavbg) ma che certamente richiederà molte e molte risorse e tempo.Ciao sotema,
fermati un secondo, ancora non abbiamo abbozzato la struttura del DB e già pensi alle fatture, venale si ma con garbo... 8)No non fraintendere non sto già partendo col progetto, sto solo mettendo insieme le informazioni utili per poter poi ragionare sul database più idoneo per il cliente.
Nel frattempo ti dico che ho steso lo scheletro della guida di installazione di PostgreSQL. Nel fine settimana vedo di completarla, la sottoporro al vaglio del Team e quindi, forse, la pubblichiamo nella WIKI.Non vedo l'ora di leggerlo e installare la mia “Ferrari”. In effetti questo nome non è particolarmente azzeccato in quanto leggo che MySQL e MariaDB sarebbero più veloci, io l'ho usato intendendo "cosa ambita."
:sleepy:
PS: forse sarebbe il caso di aprire una nuova discussione, magari col titolo Sviluppo Gestionale Rubinetto FeliceHai ragione anche su questo, provvederò ad aprire la nuova discussione, infatti il titolo di questa non rende certo l'idea su quanto ci stiamo accingendo a fare.
...
Diversa sarebbe la prospettiva di costruire un gestionale che utilizzi il DB per acquisire l'esperienza necessaria per affrontare successivamente la stesura del DB minimale da riversare nel libro di testo pensato originariamente da Gianluigi.
Ciao a tutti.
Nota CreditoCiao sotema,
Ricevuta Fiscale (o il tuo cliente vende solo all'ingrosso?)
Nota d'Ordine
Commessa di lavorazione (se effettua riparazioni di attrezzatura)
se ci penso bene...
Nota CreditoCiao sotema,
Ricevuta Fiscale (o il tuo cliente vende solo all'ingrosso?)
Nota d'Ordine
Commessa di lavorazione (se effettua riparazioni di attrezzatura)
se ci penso bene...
ma questo non è più una "Gestione Ordini", di questo passo parliamo di un gestionale "quasi completo" esclusa la contabilità,
a meno che non ci sia qualcuno esperto che si vuole aggregare anche in questo campo e allora abbiamo fatto...bingo ;D
battute a parte, a me non spaventa, anzi le sfide mi piacciono, però ragazzi se si vuol fare questo passo in modo "serio"
sarà un cammino lungo e doloroso...quindi direi di andare per gradi.
@ Picavbg
Per quanto riguarda le tue osservazioni ricalcano anche se in "tono diverso" ciò che anche io avevo già fatto presente a Gianluigi,
però sono d'accordo anche con lui (già lo avevo detto) che comunque è ovvio che nel libro non potrà mettere tutto ciò che
eventualmente questo progetto produrrà, ma una cosa è certa, di spunti per spiegare certi concetti che vorrà affrontare ne troverà
tanti è calati nella realtà, a differenza di esempi a volte banali che non ti spiegano e non ti fanno capire le potenzialità di un DB.
In attesa delle linee guida di sotema per installare PgSql, vi allego uno screenshot della schermata iniziale di un'idea che avevo
abbozzato tempo fà, ma momentaneamente accontanata. Ciao a tutti :ciao: