Topic: Confronto sito per “ricette” in django  (Letto 767 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline avanguard

  • python unicellularis
  • *
  • Post: 11
  • Punti reputazione: 0
    • Mostra profilo
Confronto sito per “ricette” in django
« il: Dicembre 13, 2017, 07:34 »
Ciao,
 sto costruendo un sito utilizzando django, che avrà un app per la costruzione  di una “ricetta” in realtà non sarà culinaria, ma prendiamola come tale, tanto sarebbe la stessa cosa.

Io avrò un form per la creazione degli ingredienti(con diversi campi) e un altro per la costruzione del piatto.

Volevo un piccolo confronto su quest’ultimo è vedere voi come lo fareste a livello di db

Il form per la creazione piatto avevo pensato di farlo così:

Nome
Descrizione

Ingredienti ( pescando dal db ingredienti, utilizzando Java per un form dinamico con la possibilità di aggiungere campi)

Fasi di preparazione preparazione (anche qui form dinamico)

Il confronto che vorrei è proprio su questi campi dinamici, come li gestireste nel db??

Aggiungo una piccola nota:  nelle fasi non mi interessa collegarmi agli ingredienti sarà solo textfild, però devo fare diverse fasi separate

Grazie

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #1 il: Dicembre 13, 2017, 10:27 »
Non è chiarissimo che cosa vuoi fare, soprattutto quello che intendi per "dinamico". In un'applicazione gestita da un database tutto è "dinamico", nel senso che puoi sempre cambiare il dato nel database in qualunque momento. D'altra parte, una collezione di ricette è, in un certo senso, "statica" o almeno dovrebbe esserlo: per fare la pasta alle vongole ci vogliono sempre pasta e vongole, non è che domani puoi cambiare e metterci fettine di vitello e molto aceto. Non è più pasta alle vongole.

Detto questo, sì, se vuoi tenere traccia separatamente degli ingredienti e dei piatti, allora direi che ingredienti e piatti stanno tra loro in una relazione molti-a-molti. Naturalmente l'orm di django ha gli strumenti per modellare una relazione di questo tipo: https://docs.djangoproject.com/en/2.0/ref/models/fields/#manytomanyfield. Il tuo problema, qui, è che però una relazione molti-a-molti semplice non basta: non ti basta dire che per fare la "pasta alla carbonara" (piatto) ci vogliono "uova" (ingrediente), ma hai bisogno di specificare che ci vogliono *due* uova. Per contro, anche la "torta alle mele" (piatto) ha bisogno di "uova" (ingrediente), ma questa volta ce ne vogliono *quattro*. Hai bisogno cioè di inserire degli "extra-fields" nella tabella intermedia della relazione molti-a-molti. Siccome questa tabella intermedia è gestita da django dietro le quinte, apparentemente non c'è soluzione: solo che naturalmente django ha previsto anche questo caso (in effetti molto comune), e ha lo strumento adatto: https://docs.djangoproject.com/en/2.0/topics/db/models/#intermediary-manytomany.

Riassumendo:
- se quello che ho detto finora non ha senso per te (per esempio, se non ti è chiaro che una relazione molti-a-molti è costruita con una tabella intermedia) dovresti fermarti e imparare le basi di sql;
- se invece è tutto chiaro, dovresti studiarti l'orm di django *a fondo* per capire con precisione come django ti aiuta a modellare un database;
- una volta costruiti i tuoi model, il resto viene di conseguenza (form, view, schema di url, bla bla bla).

Segui *con la massima cura* il tutorial di django, e ripetilo almeno tre volte daccapo, sempre con la massima cura, prima di fare qualsiasi altra cosa. Davvero. Davvero. Django è *difficile*. L'unico vantaggio è che ha una documentazione di gran classe, quindi occorre sfruttarla al massimo.
In ogni caso, tieni conto che partire pensando alle view e ai form molto raramente (ma proprio molto raramente) è la cosa giusta. da fare.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Confronto sito per “ricette” in django
« Risposta #2 il: Dicembre 13, 2017, 13:54 »
A me verrebbe da dire: stai lontano dai database relazionali.
I db relazionali sono relativamente poco flessibili nello schema. Richiedono di fare *bene* la modellizzazione del problema. E normalmente sti big-design-up-front non sono una gran pratica.
Se questo non accade e' un *grosso* problema in seguito.

E nota che si parla di modellare il dominio, ancora prima di scrivere il codice. Poi di dovrebbe parlare di come modellarlo "nel software".

A me sembra che questo sia invece uno use case perfetto per un db non relazionale, quale per esempio ... beh, tutti sanno cosa starei per dire. :)

Detto questo... mi dici perche' menzioni Java? Cioe', fai quello che vuoi, ma se stai lavorando in Python perche' devi avere *una* form servita da uno stack diverso in Java?

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #3 il: Dicembre 13, 2017, 16:18 »
Sì è vero, le relazioni molti-a-molti bisogna un po' incastrarle a martellate nel modello relazionale... detto questo, l'OP tenga comunque conto che, se il suo problema è solo quello che ci ha detto e non ci sono complicazioni strane in agguato, allora direi che questa cosa in django si fa comunque con un'oretta di lavoro, e sta su più che dignitosamente.

>  mi dici perche' menzioni Java?
uhm, è vero... non ci avevo neanche fatto caso.

Offline avanguard

  • python unicellularis
  • *
  • Post: 11
  • Punti reputazione: 0
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #4 il: Dicembre 13, 2017, 22:43 »
Non è chiarissimo che cosa vuoi fare, soprattutto quello che intendi per "dinamico". In un'applicazione gestita da un database tutto è "dinamico", nel senso che puoi sempre cambiare il dato nel database in qualunque momento. D'altra parte, una collezione di ricette è, in un certo senso, "statica" o almeno dovrebbe esserlo: per fare la pasta alle vongole ci vogliono sempre pasta e vongole, non è che domani puoi cambiare e metterci fettine di vitello e molto aceto. Non è più pasta alle vongole.

Detto questo, sì, se vuoi tenere traccia separatamente degli ingredienti e dei piatti, allora direi che ingredienti e piatti stanno tra loro in una relazione molti-a-molti. Naturalmente l'orm di django ha gli strumenti per modellare una relazione di questo tipo: https://docs.djangoproject.com/en/2.0/ref/models/fields/#manytomanyfield. Il tuo problema, qui, è che però una relazione molti-a-molti semplice non basta: non ti basta dire che per fare la "pasta alla carbonara" (piatto) ci vogliono "uova" (ingrediente), ma hai bisogno di specificare che ci vogliono *due* uova. Per contro, anche la "torta alle mele" (piatto) ha bisogno di "uova" (ingrediente), ma questa volta ce ne vogliono *quattro*. Hai bisogno cioè di inserire degli "extra-fields" nella tabella intermedia della relazione molti-a-molti. Siccome questa tabella intermedia è gestita da django dietro le quinte, apparentemente non c'è soluzione: solo che naturalmente django ha previsto anche questo caso (in effetti molto comune), e ha lo strumento adatto: https://docs.djangoproject.com/en/2.0/topics/db/models/#intermediary-manytomany.

Riassumendo:
- se quello che ho detto finora non ha senso per te (per esempio, se non ti è chiaro che una relazione molti-a-molti è costruita con una tabella intermedia) dovresti fermarti e imparare le basi di sql;
- se invece è tutto chiaro, dovresti studiarti l'orm di django *a fondo* per capire con precisione come django ti aiuta a modellare un database;
- una volta costruiti i tuoi model, il resto viene di conseguenza (form, view, schema di url, bla bla bla).

Segui *con la massima cura* il tutorial di django, e ripetilo almeno tre volte daccapo, sempre con la massima cura, prima di fare qualsiasi altra cosa. Davvero. Davvero. Django è *difficile*. L'unico vantaggio è che ha una documentazione di gran classe, quindi occorre sfruttarla al massimo.
In ogni caso, tieni conto che partire pensando alle view e ai form molto raramente (ma proprio molto raramente) è la cosa giusta. da fare.

Ti ringrazio della risposta, mi è chiaro quello che mi stai dicendo, non è moltissimo che uso django però ho seguito già parecchi tutorial e ora appunto sto iniziando a creare quello per cui ho iniziato... però mi sono espresso male,molto probabilmente, dato che anche gli altri che hanno risposto non hanno capito cosa intendevo...

Quando mi riferisco a un form dinamico intendo letteralmente il form dinamico Con la possibilità di variari il numero di campi utilizzando Java.
Perché potrei avere una ricetta che ha 2 ingredienti e una che ne 10.
Quindi grazie a Java potevo aggiungere nuovi campi per gli ingredienti.

Io però sinceramente non ero a conoscenza di questi extra-fild per quello che non avevo valutato una relazione manytomany, adesso li studio un po’ e vedo se fa al caso mio.

Anche perché nella schermata della ricetta, sono tante le cose che dovrà gestire, per esempio gli ingredienti avranno un costo, e io inserendo l’ingrediente e La quantità per la produzione dovrò avere un totale di costo del piatto.

Comunque ti ringrazio per il suggerimento ora ci darò un occhiata.

Offline avanguard

  • python unicellularis
  • *
  • Post: 11
  • Punti reputazione: 0
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #5 il: Dicembre 13, 2017, 22:55 »
A me verrebbe da dire: stai lontano dai database relazionali.
I db relazionali sono relativamente poco flessibili nello schema. Richiedono di fare *bene* la modellizzazione del problema. E normalmente sti big-design-up-front non sono una gran pratica.
Se questo non accade e' un *grosso* problema in seguito.

E nota che si parla di modellare il dominio, ancora prima di scrivere il codice. Poi di dovrebbe parlare di come modellarlo "nel software".

A me sembra che questo sia invece uno use case perfetto per un db non relazionale, quale per esempio ... beh, tutti sanno cosa starei per dire. :)

Detto questo... mi dici perche' menzioni Java? Cioe', fai quello che vuoi, ma se stai lavorando in Python perche' devi avere *una* form servita da uno stack diverso in Java?

Grazie per la risposta, devo essere sincero mentre Mysql è parecchio che lo uso e iniziò a capirci qualcosa non ho mai usato db non relazionali, avevo giusto data un occhiata al volo a MongoDB però ora già sto imparando a usare django e se devo anche capire come gestire un nuovo database credo che farei un casino hahahah, però non escludo che per il futuro mi lancerò anche su quello.

Comunque parlavo di Java semplicemente per la costruzione del form perché mi serviva qualcosa per inserire tutti gli ingredienti che volevo senza limitazione quindi mi era funzionale

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Confronto sito per “ricette” in django
« Risposta #6 il: Dicembre 15, 2017, 14:57 »
Comunque parlavo di Java semplicemente per la costruzione del form perché mi serviva qualcosa per inserire tutti gli ingredienti che volevo senza limitazione quindi mi era funzionale

Quello che stai scrivendo non ha il minimo senso, questo e' il problema.
Tipo: "Quindi grazie a Java potevo aggiungere nuovi campi per gli ingredienti."

Ora, c'e' una sola spiegazione che da un senso al tutto: non sai quale e' la differenza fra Java e Javascript.

Che, mutatis mutandis, e' un po' come se qualcuno andasse in forum di carpentieri per chiedere consigli su come costruire un armadietto e saltasse fuori che non ha presente la differenza fra un martello e un cacciavite.

Mi verrebbe da dire: ferma tutto. Come stai studiando, non funziona. Cambia.

Offline avanguard

  • python unicellularis
  • *
  • Post: 11
  • Punti reputazione: 0
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #7 il: Dicembre 16, 2017, 08:20 »
Comunque parlavo di Java semplicemente per la costruzione del form perché mi serviva qualcosa per inserire tutti gli ingredienti che volevo senza limitazione quindi mi era funzionale

Quello che stai scrivendo non ha il minimo senso, questo e' il problema.
Tipo: "Quindi grazie a Java potevo aggiungere nuovi campi per gli ingredienti."

Ora, c'e' una sola spiegazione che da un senso al tutto: non sai quale e' la differenza fra Java e Javascript.

Che, mutatis mutandis, e' un po' come se qualcuno andasse in forum di carpentieri per chiedere consigli su come costruire un armadietto e saltasse fuori che non ha presente la differenza fra un martello e un cacciavite.

Mi verrebbe da dire: ferma tutto. Come stai studiando, non funziona. Cambia.

Si intendevo js, scusa non pensavo di creare una tragedia incomprensibile facendo un errore simile,

Per intenderci ho visto questo tutorial e pensavo fosse fattibile.
https://youtu.be/jSSRMC0F6u8

Comunque credo che lo scopo di questi forum sia anche quello di imparare e migliorare, le critiche sono ottime quando sono costruttive, e ti ringrazio per avermi fatto capire che è importante specificare meglio.

Ma non ho nascosto di essere un principiante, credo che un refuso sia accettabile
« Ultima modifica: Dicembre 16, 2017, 08:25 da avanguard »

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #8 il: Dicembre 16, 2017, 10:59 »
Un refuso è un refuso, ma ripetere la seconda volta il refuso, dopo che ti è stato chiesto esplicitamente di chiarire la questione del refuso... beh, dai, siamo onesti, non è più un refuso, dico bene?
Visto che stiamo parlando di ricette, immagina questo dialogo tra te e il cuoco del ristorante. Tu: come la fai la matriciana? Cuoco: ...poi aggiungo la marmellata e... Tu: la marmellata? Sei sicuro? Cuoco: sì, la marmellata dà quel gusto particolare che... Tu: ma non è che ti confondi con il guanciale? Cuoco: ah, sì, certo, naturalmente, intendevo dire il guanciale. Scusa, è solo un piccolo refuso. Non è il caso di farne una tragedia.
Cosa penseresti del cuoco?

Studiati js (che è proprio interamente un'altra cosa rispetto a java), e lascia perdere ogni cosa che vedi su youtube. E' veleno per chi vuole imparare. Prenditi un buon libro, invece.

Detto questo, tieni presente che, se il tuo progetto è proprio solo quello che hai detto, e non ci sono altre complicazioni in agguato, allora se lo fai in django dubito che tu avrai davvero bisogno di integrare js a mano... Cioè, non è una buona scusa per non imparare js, ma insomma prima darei un'occhiata a django.
E ancora più in generale, direi che stai partendo a costruire la casa dal tetto invece che dalle fondamenta. Prima di preoccuparti della view, dovresti pensare al model: studiati sql e i database relazionali, capisci come si modella una relazione molti-a-molti nei vari casi, studiati come l'orm di django affronta questi problemi, e decidi come costruire il tuo database. Poi la parte di presentazione verrà dopo.

Offline avanguard

  • python unicellularis
  • *
  • Post: 11
  • Punti reputazione: 0
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #9 il: Dicembre 16, 2017, 17:54 »
Un refuso è un refuso, ma ripetere la seconda volta il refuso, dopo che ti è stato chiesto esplicitamente di chiarire la questione del refuso... beh, dai, siamo onesti, non è più un refuso, dico bene?
Visto che stiamo parlando di ricette, immagina questo dialogo tra te e il cuoco del ristorante. Tu: come la fai la matriciana? Cuoco: ...poi aggiungo la marmellata e... Tu: la marmellata? Sei sicuro? Cuoco: sì, la marmellata dà quel gusto particolare che... Tu: ma non è che ti confondi con il guanciale? Cuoco: ah, sì, certo, naturalmente, intendevo dire il guanciale. Scusa, è solo un piccolo refuso. Non è il caso di farne una tragedia.
Cosa penseresti del cuoco?

Studiati js (che è proprio interamente un'altra cosa rispetto a java), e lascia perdere ogni cosa che vedi su youtube. E' veleno per chi vuole imparare. Prenditi un buon libro, invece.

Detto questo, tieni presente che, se il tuo progetto è proprio solo quello che hai detto, e non ci sono altre complicazioni in agguato, allora se lo fai in django dubito che tu avrai davvero bisogno di integrare js a mano... Cioè, non è una buona scusa per non imparare js, ma insomma prima darei un'occhiata a django.
E ancora più in generale, direi che stai partendo a costruire la casa dal tetto invece che dalle fondamenta. Prima di preoccuparti della view, dovresti pensare al model: studiati sql e i database relazionali, capisci come si modella una relazione molti-a-molti nei vari casi, studiati come l'orm di django affronta questi problemi, e decidi come costruire il tuo database. Poi la parte di presentazione verrà dopo.

Hai ragione ho sbagliato, in realtà se vogliamo fare un esempio più azzeccato ho confuso il guancela con la guancetta, hahahah però va beh

Comunque per me è tutto un modo per imparare, conosco la differenza fra Java e javascript è che proprio mi sono confuso nello scrivere.

In ogni modo per me queste sono proprio le “ fondamenta” che ho bisogno perché devo impostare il db, se no non posso fare niente, io di fatto mi ero portato avanti parlando del form, ma avevo proprio bisogno un consiglio sul db che con la relazione manytomany mi hai dato.
anche se stavo valutando un altra strada e gestirli separatamente, quindi una tabella materie prime, una ricetta e una ingredienti, Associando a ingredienti 2 ForeignKey una per l’ingrediente e una per la ricetta che ne pensi?

Comunque se hai un buon libro da consigliarmi sarebbe fantastico.

Anche perché anche solo a scrivere la parte delle materie prime ho trovato un intoppo per far calcolare in automatico i valori.
Approposito di questo. Io sto provando a farlo con una definizione al salvataggio.
Ma si potrebbe usare anche prepopuletedfild nell’admin? Perché in giro tutti lo usano solo per il compito slug, quindi non so se si può usare anche per dirgli tipo prendi il prezzo è moltiplicalo per X

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Confronto sito per “ricette” in django
« Risposta #10 il: Dicembre 16, 2017, 20:02 »
Mi dispiace che te la sia presa (se te la sei presa). Non era mia intenzione essere offensivo, solo brutalmente onesto.
Spesso la via piu' rapida fra due punti non e' quella diretta. Nello specifico, puoi affrontare questo progetto prendendo a capocciate ogni problema che ti si presenta oppure, come sembra indicare il fatto che hai scritto qua, cercare di capire quale sia il modo meno faticoso e piu' comodo.
Che e' *studiare*.

Dopo di che, secondo me stai affrontando il problema dal lato sbagliato. Scusa, tolgo il secondo me. E' il parere di qualunuque professionista: il database e' un dettaglio di basso livello e non vuoi "mai" che i dettagli di basso livello dettino le scelte di alto livello.
Ora tu non hai davvero un modello della tua applicazione. Non e' per essere noioso, ma prima devi capire che tipo di dati vuoi salvare. Devi capire come sono composti. Questo lo devi fare a prescindere. Questa e' tua vision. E' quella che la tua applicazione deve fare.

Poi si pone il problema di *come* scriverla sta applicazione. E sinceramente fare un modello relazionale sensato a partire da un'applicazione non e' particolarmente banale. Perche' il modello relazionale non e' banale (e la maggior parte della gente non lo capisce davvero).
Per quello suggerivo di stare su nosql: hai un problema in meno. E sopratutto sei meno committed. E' piu' facile adattare un cambiamento in un db nosql. Se sei nel modello relazionale e hai fatto delle scelte sbagliate all'inizio, ne esci con molta fatica. Ed esperienza. Che e' la cosa che non hai e non avrai per un po'.

Per esempio, tornando al discorso del modello. Ti interessa dire che ci vogliono 100 grammi di pasta per la matriciana? Ti interessa invece dire che ci vogliono "10 parti" di qualcosa?
Vuoi gestire tu le unita' di misura? La pasta deve essere "pasta" (e se si, ti interessa specificare il tipo? e la marca? e se e' di segale, di uova, con le ortiche?).
E cose tipo "il soffritto". Vuoi che sia una cosa a se stante, con la sua ricetta, e poi tutte le ricette di soffritto vanno li?
Oppure hai diversi tipi di soffritto, un po' condivisi fra piu' ricette e un po' unici? E uno puo' volere cercare anche le specifiche ricette di soffritto? E anche quelle dei soffritti unici che hanno senso solo dentro una specifica ricetta?
E le ricette hanno variazioni? Come le vuoi tracciare? E sono "variazioni" o solo "evoluzioni"?
E ti interessano i prezzi? E gli strumenti da cucina? Tipo mi sono appena comprato una mandolina e adesso mi piacerebbe vedere qualche ricetta per cui posso usarla. Mentre per un cuoco probabilmente questa cosa e' priva di senso.
E ti interessa gestire i tempi? E quando hai la ricetta del soffritto, lo calcoli a parte (perche' si assume che se ti dico soffritto, tu abbia il soffritto... che potrebbe anche avertelo dato la nonna oppure essere un preparato? beh, con il soffritto magari non ha senso... sostituiscilo con qualcos'altro).

Ora quasi tutte queste innocenti domande ti cambiano il modello a tal punto che poi i db relazionali corrispondenti non sia assomiglierebbero nemmeno troppo. A meno di non avere uno schema iper generale e iper complesso che supporta "tutto". E buona fortuna a scriverlo. E poi quando scopri che il tutto non era cosi' tutto... beh, ancora buona fortuna.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #11 il: Dicembre 16, 2017, 23:32 »
Sì, direi che se leggi a fondo e con distacco questa risposta di Riko, ne capisci di cose. Compreso il fatto che (giustamente) dovresti farti prendere da un pizzico di timor sacro. Ora, tenendo conto che Riko ha *ragione*, e che condivido quello che dice, provo almeno un po' ad addolcire la pillola.
Non è che per fare un database di ricette devi avere tutto in mente alla perfezione. Puoi anche *sbagliare*. Puoi anche romperti la testa, fasciartela, capire dove e perché hai sbagliato, e correggere. In effetti potrebbe anche essere la strada giusta, didatticamente parlando. Prova a fare qualcosa, invece di pensarci troppo sopra, poi prova a usarla, probabilmente si spaccherà subito, capisci dove si è spaccata e come fare ad aggiustarla. Ripeti, e ripeti, e ripeti.

Molte cose che dice Riko usano la metafora delle ricette, perché tu sei partito da quelle. Il problema è che però tu hai anche detto che in realtà tu non devi fare un'applicazione di "ricette", e quindi non è possibile capire fino in fondo che cosa ti serve davvero, e come. Non è un problema da poco: un database deve modellare con cura un dominio applicativo, e conformarsi a quello. Riko ha ragione quando dice:

> tutte queste innocenti domande ti cambiano il modello a tal punto che poi i db relazionali
> corrispondenti non sia assomiglierebbero nemmeno troppo.

Quindi, figurati che cosa succede quando si scopre che in realtà il tuo dominio applicativo è addirittura una cosa diversa dalle "ricette di cucina".  Mah. In ogni caso, sempre come dice Riko:

>  il database e' un dettaglio di basso livello e non vuoi "mai" che i dettagli di basso livello dettino le scelte di alto livello.
> Ora tu non hai davvero un modello della tua applicazione. Non e' per essere noioso, ma prima devi capire che tipo di dati vuoi salvare.
> Devi capire come sono composti. Questo lo devi fare a prescindere. Questa e' tua vision. E' quella che la tua applicazione deve fare.

Esatto. Tieni a mente questo. Devi mappare il tuo dominio applicativo nel database, *SENZA* pensare ai calcoli (logica di business) e alle interazioni utente (logica di presentazione) che su questi dati verranno fatti. Pensa a quanti e quali attori hai sul tavolo, e quali sono le relazioni "statiche" che li collegano. Come per esempio, quando fai il software di una biblioteca pensi che gli attori sono "libri", "autori" e "editori", e stanno in una certa relazione tra loro (un autore può aver scritto molti libri, un editore pubblica molti libri, un libro può essere stato scritto da più autori... insomma le solite cose che ti spiegano al primo capitolo del libro su sql o giù di lì).  Dopo, e soltanto dopo, pensi che magari ti interesserà sapere qual è l'editore di riferimento per un certo autore, ma appunto, questa è logica di business che non ti deve interessare nel momento in cui modelli un database.

Quindi, domande come "calcolare in automatico i valori", "usare un prepopulated field" e cose del genere, non hanno molto senso. O meglio, hanno molto senso, ma soltanto "dopo".
Dopo di che, l'orm di django ti può aiutare a risolvere dei problemi, se impari come ragiona django.  Ma una certa conoscenza di database relazionali e di come si costruiscono è indispensabile a prescindere.


Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Confronto sito per “ricette” in django
« Risposta #12 il: Dicembre 17, 2017, 15:19 »
Dopo di che, l'orm di django ti può aiutare a risolvere dei problemi, se impari come ragiona django.  Ma una certa conoscenza di database relazionali e di come si costruiscono è indispensabile a prescindere.

Pero' qua viene un punto di rinforzo. Se sai modellare un'applicazione come "software" un ORM (anche quello di Django) ti consente di dimenticarti per un po' di SQL.
Ma se hai un'applicazione modellata male a livello software... beh,  sara' difficile fare fare alla tua applicazione quello che vuoi. 
Una buon modello del tuo dominio applicativo e' qualcosa che ti serve a prescindere dalle tecnologie che usi. E per modellare un'applicazione con Django... devi comunque avere un'idea di cosa vuoi modellare.

Un modello fatto bene e' anche che ti porta ad una buona architettura. E una buona architettura e' qualcosa che ti aiuta a modificare il modello quando ti accorgi che in effetti non e' proprio quello che volevi.


Questo non vuole dire "stop the world", fai tutto il design a monte e fra qualche mese se ne parla. Questo approccio non funziona, hanno provato a venderlo, e si sa che non funziona. Si, hanno venduto fumo.
Ma perdere un pomeriggio per farti il modello dopo avere studiato per il tempo necessario come si modellizza il software e' un tradeoff accettabile.
Toh, magari te ne vogliono due con una buona notte di sonno che porta consiglio (davvero) nel mezzo. E non piu' che qualche ora di fila: se no svalvoli e la qualita' decresce. Ora di file con pause accettabili, eh. Caffe', the, 5-10 minuti di passeggiata, quello che ti pare. Non cazzeggio su internet o cose che distraggono. Semplicemente cose che non ti fanno pensare a nulla. Che lasciano la mente libera di riorganizzarsi.
Se ti trovi a pensare al problema non e' un dramma, ma non e' l'obiettivo. E' meglio, se possibile, che la mente pensi in background al problema, in modo inconscio. Tu pensa al parco, agli alberi... boh. Alla gente che fa jogging. A cosa ti va di mangiare.

Offline avanguard

  • python unicellularis
  • *
  • Post: 11
  • Punti reputazione: 0
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #13 il: Dicembre 17, 2017, 21:12 »
Ringrazio tutti del supporto, purtroppo io sono un autodidatta e più che guardare su internet e chiedere consigli a persone più competenti di me, non so come fare per andare avanti.

Io per adesso ho provato a ragionare su come poteva essere la struttura e provo velocemente a spiegarla partendo questa volta al contrario, quindi da come sarà il risultato

Ci sarà una schermata di “ordinazione” dove ogni settimana vengono inseriti le quantità da produrre, in base a queste il sistema dovrà avere un download di un file xls con l’elenco delle produzioni e uno con l’elenco delle materie prime necessarie.

Da un altra parte bisogna poter inserire i prodotti con le materie prime di riferimento e da li, ci dovrà essere una schermata per poter vedere tutte le specifiche per l’operatore che deve eseguire la produzione e la possibilità di scaricare in pdf.

Sostanzialmente è questa più ci saranno delle schermate di statistiche, non ci sono particolari varianti in questo in realtà. Anche perché sono anni che lavoriamo con mail e file xls fatti a mano, quindi già questo sistema sarà un bel passo avanti
« Ultima modifica: Dicembre 17, 2017, 21:15 da avanguard »

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.869
  • Punti reputazione: 9
    • Mostra profilo
Re:Confronto sito per “ricette” in django
« Risposta #14 il: Dicembre 18, 2017, 09:47 »
>  ho provato a ragionare su come poteva essere la struttura (...)
> Ci sarà una schermata

Ecco, capisci il problema? Questa non è una struttura. Non pensi in termini di struttura.