DB raccolta ordini

di il
30 risposte

30 Risposte - Pagina 2

  • Re: DB raccolta ordini

    Sei di nuovo fuori strada perchè pretendi che i vecchi oggetti che avevi progettato vadano bene con la nuova struttura. Anche i report devono essere progettati diversamente.
    Quando ti impantani così io consiglio sempre di elencare una serie di fatti significativi che sperano di dare ragione alla tua tesi. Io poi potrò dimostrarti come devi aggiustare il tutto.
    Fammi 2-3 esempi significativi.

    Tanto per curiosità. Quanti record hai per ogni tabella del vecchio database?
  • Re: DB raccolta ordini

    1_ come fare il report che ho allegato. Il report deve avere in alto i dati principali e li ok ci siamo perché sono in tabella ordini. Nel corpo sulla sinistra prodotto kg e qtà e a destra torta con i suoi sei campi di dettaglio. Queste due macro divisioni sono in un unica tabella e differenziare il report a seconda del prodotto, se sono nella stessa tabella mi pare impossibile

    2_ maschera inserimento dati mi troverei nello stesso problema descritto sopra
  • Re: DB raccolta ordini

    Perchè non vuoi rispondere a queste mie domande?

    OsvaldoLaviosa ha scritto:


    Fammi 2-3 esempi significativi.

    Tanto per curiosità. Quanti record hai per ogni tabella del vecchio database?
    Se continui a incaponirti così, non potrò più seguirti e dico STOP una volta per tutte.
    Non so perchè ti sto inseguendo pazientemente. Altri utenti avrebbero mollato quasi subito.
    Sarei molto contento se un altro utente (magari più esperto di me) potesse dire la sua.
  • Re: DB raccolta ordini

    Ma io ti ringrazio tantissimo per la Pazienza e lo dico di cuore.. Ma davvero non riesco a costruire il report con questa nuova struttura. Perché come faccio a mettere nella stessa schermata due prodotti con stessa tabella ma campi compilati diversi? Non posso fare un report (o forse non sono capace io) dove se mi ordina pizza mi chiede a che quante candeline... Guarda l'allegato della stampa e prova ad immaginare a farlo con questa struttura... Come lo faccio? Spero che ci sia qualche altro super esperto per darci anche lui un altra opinioni... Non è che non voglio ascoltarti è che così non riesco a creare la maschera e la stampa desiderata dal cliente.
  • Re: DB raccolta ordini

    Quanti record ho non lo so in quanto il programma è solo in fase di test..
  • Re: DB raccolta ordini

    asnaldo ha scritto:


    Quanti record ho non lo so in quanto il programma è solo in fase di test..
    Mi vuoi dire cioè che hai talmente pochi record che non riesci ad avere una idea "corposa" di come possono comportarsi i tuoi dati. Non tanto adesso, ma soprattutto in futuro.
    Se ancora non riesci a renderti conto che stai facendo una cavolata è proprio perchè hai pochi record e pochi valori. È sulla grande quantità di dati che Access risponde bene se la struttura è corretta, risponde male/rallenta se ecc...hai capito...!!!
    È sulla grande quantità di dati che si riesce a cogliere meglio l'omogeneità di certi valori piuttosto di altri.
  • Re: DB raccolta ordini

    Considera che non sono dati essenziali da tenere sempre online.. Se il db diventa corposo posso svuotarlo ogni mese.. (a parte anagrafica cliente) a me piacerebbe tanto usare questa struttura ma non riesco a fare né la maschera e ne il report.. A parte che se divido le tabelle forse rimane anche più leggero dato che i dati maggiormente compilati sono i prodotti con tre campi..
  • Re: DB raccolta ordini

    Ciao,

    ho dato una letta un po sommaria alla conversazione. Sostanzialmente mi sembra di capire che tu hai fatto un progetto per una base dati e qualcuno ti ha detto che non è normalizzata e vorresti capire eventualmente come normalizzarla.

    Ti chiedo se vuoi di riassumermi :
    - quali sono i requisiti;
    - quali saranno le interrogazioni che farai al database;
    - qual'è il tuo schema relazionale

  • Re: DB raccolta ordini

    Devo sostituire un modulo di raccolta ordini clienti di una pasticceria.

    Il cliente entra e l'operatore del negozio segna su un foglio questi dati :
    - dati anagrafici cliente con conseguente date presa ordine e consegna prevista dei prodotti ordinati
    - prodotto, kg e quantità
    - torta o costata e varie personalizzazioni

    Conclusa la presa dell'ordine stampa al cliente dell'ordine

    Allego lo schema DB che ho creato io e quello che in teoria sarebbe normalizzato.
    allego maschera e stampa (report) che ho creato per presa ordini con db doppia tabella ordini

    Interrogazioni che mi servono. Presa ordine e sua modifica. Anagrafici cliente è modifica. Report presa ordini da dare al cliente. Riporto stampa giornaliera ordini divisa per punto vendita

    tapatalk_1425587406510.png
    tapatalk_1425587406510.png


    tapatalk_1425587390088.png
    tapatalk_1425587390088.png


    tapatalk_1425587372021.jpeg
    tapatalk_1425587372021.jpeg


    Allegati:
    16249_b386d712379d401ee8696463a1c323b1.jpeg
    16249_b386d712379d401ee8696463a1c323b1.jpeg

    16249_59f4ff5d4afe6ec861766e68d569f254.png
    16249_59f4ff5d4afe6ec861766e68d569f254.png

    16249_91f87b93d512922cced89028c0551864.png
    16249_91f87b93d512922cced89028c0551864.png
  • Re: DB raccolta ordini

    asnaldo ha scritto:


    Considera che non sono dati essenziali da tenere sempre online.. Se il db diventa corposo posso svuotarlo ogni mese.. (a parte anagrafica cliente) a me piacerebbe tanto usare questa struttura ma non riesco a fare né la maschera e ne il report.. A parte che se divido le tabelle forse rimane anche più leggero dato che i dati maggiormente compilati sono i prodotti con tre campi..
    Sottovaluti Access. Access non ha alcun problema a gestire tabelle di decine-centinaia di migliaia di record. 1000 record in più o in meno in Access gli fai il solletico. Un database non viene costruito per poi cancellargli i dati periodicamente perchè si teme possa appesantirlo.
    Per me sei in una fase di stallo in cui non sei ancora convinto che la nuova struttura funzioni. Devi ripartire da quest'ultima. Conseguenza della nuova struttura è la cancellazione di tutti gli altri oggetti che avevi creato in precedenza, frutto della vecchia logica. Quindi elimina tutte le maschere, tutti i report, tutte le query.
    1. Crea le opportune caselle combinate nei campi delle tabelle figlie
    2. Ricostruisci facilmente (leggi la guida in linea sulla creazione guidata maschera/sottomaschera) maschera/sottomaschera Ordini/DettagliOrdini includendo tutti i campi di entrambe le tabelle
    3. Idem il report Ordini con DettagliOrdini

    Se il mio discorso non ti convince, conserva una copia del vecchio database, sulla nuova copia apporti tutte le modifiche che ti ho detto io.

    A corollario di tutta la lunga discussione ti consiglio la lettura di un buon manuale di base. Il forum suggerisce alcuni titoli. Io ho iniziato da "McGraw-Hill: Computer no problem - Access".
  • Re: DB raccolta ordini

    asnaldo ha scritto:


    Devo sostituire un modulo di raccolta ordini clienti di una pasticceria.
    Non capisco il perché tu abbia creato le due tabelle Farcitura e Decorazione (che caso mai dovrebbero chiamarsi Farciture e Decorazioni) le quali:
    1 - hanno un solo campo
    2 - le hai relazione alla tabella DettaglioOrdini (che invece dovrebbe chiamarsi OrdiniDettagli)

    Ci vuoi spiegare il motivo?
  • Re: DB raccolta ordini

    gibra ha scritto:


    Non capisco il perché tu abbia creato le due tabelle Farcitura e Decorazione (che caso mai dovrebbero chiamarsi Farciture e Decorazioni)
    Avevo già risposto io:

    OsvaldoLaviosa ha scritto:


    Giusto un mio puntiglio metodologico:
    - Nomina sempre al PLURALE i NomeTabella
    - Nomina sempre al SINGOLARE il NomeCampo
    quindi tabella Farciture, campo Farcitura. Tabella Decorazioni, campo Decorazione.
    Dall'immagine si legge la tabella PentiVendita, correggi PuntiVendita.
    Ti consiglio di mantenere rigida questa metodologia. Se domani hai bisogno di creare espressioni, codici VBA, il riferimento agli oggetti deve sempre essere coerente. Se col tempo intendi farlo a memoria, una dizione corretta all'inizio ti facilita per il futuro.
    Le tabelle Farciture e Decorazioni hanno motivo di esserci. Evidentemente lui sa che ci sono valori ripetibili e penso abbia fatto bene a pensarla così. Un campo solo di tipo Testo univoco e chiave primaria si può pensare di progettarlo.
    Non mi sembra qui il problema.
  • Re: DB raccolta ordini

    OsvaldoLaviosa ha scritto:


    Le tabelle Farciture e Decorazioni hanno motivo di esserci. Non vedo il problema. Evidentemente lui sa che ci sono valori ripetibili e penso abbia fatto bene a pensarla così.
    l'ho chiesto a LUI, non a te.
  • Re: DB raccolta ordini

    Non capisco il perché tu abbia creato le due tabelle Farcitura e Decorazione (che caso mai dovrebbero chiamarsi Farciture e Decorazioni) le quali:
    1 - hanno un solo campo
    2 - le hai relazione alla tabella DettaglioOrdini (che invece dovrebbe chiamarsi OrdiniDettagli)
    Le ho create per vincolare i valori con la chiave primaria in modo che il cliente decida 4 o 5 valori fissi e con una casella combinata poi li faccio apparire nella maschera. In questo modo evito che gli operatori si inventino cose strane.
    Per come ho chiamato i nomi delle tabelle, non avendo esperienza, le ho sbagliate tutte, quindi andrò a rinominare tutte le tabelle e cmapi come dall'ottima spiegazione sulla terminologia da usare che mi ha fatto OsvaldoLaviosa

    Cmq il problema principale forse l'ho già spiegato troppe volte, è che se non faccio due tabelle per dividere il prodotto che richiedere solo 2 campi e quello che ne richiede più di sei (torta) non riesco a gestire maschera e cartaceo con layout che mi ha chiesto il lciente (vedi allegati sopra postati)
  • Re: DB raccolta ordini

    asnaldo ha scritto:


    cartaceo con layout che mi ha chiesto il ciente
    Chi è questo Cliente che impone a te come devono essere visualizzati i suoi Ordini?
    Come fai a fare eventuali Totali dell'intero ordine se non li vedi tutti in VERTICALE?
    Come gestisci un Ordine di Mario Rossi che prevede:
    5 torte
    6 crostate
    10 pizze
    50 panini
    50 bignè ?

    Tra l'altro torno a contestarti l'idea che secondo me anche Pizza può essere personalizzata con tanto di Sesso, Forma, Farcitura, Decorazione.
    E se un Cliente ti chiede di personalizzare 10 panini con tanto di Forma, Farcitura, Decorazione?
    E se un Cliente ti chiede di personalizzare 100 tramezzini con tanto di Forma, Farcitura, Decorazione?
    Sono cose che non avete previsto in azienda oggi, ma che ne potete sapere domani di una possibile evoluzione del vostro marketing?
    Per me questi campi "secondari" possono avere dei valori "neutri" di default che restano tali (e nessuno li tocca) quando non devono avere un significato "qualificante". Li compili quando ce n'è bisogno.

    Con un po' di fantasia ci sarebbero altre strategie per impedire un look NON OMOGENEO. Perchè no prevedi 2 report dai look leggermente diversi:
    uno per i soli Prodotti a molti-campi
    uno per i soli Prodotti a 2-campi.

    Tutto questo discorso mi sembra al di fuori della tematica Progettazione database che mi appare ormai chiuso (o in stallo). Se il problema si sposta solo sulla organizzazione di maschera/sottomaschera e report, ti invito ad aprire 2 thread in Access con la stessa domanda, ma mostrando i 2 diversi scenari tabelle. Stiamo poi a vedere come si evolveranno le successive risposte.
Devi accedere o registrarti per scrivere nel forum
30 risposte