2014-02-16 14:50 GMT+01:00 Perini Matteo <perini.mat...@gmail.com>: > sto seguendo con interesse ma il livello si è alzato un po' ;) >
Sai come finiscono ste cose, uno fa una domanda innocente (la mia sugli orm) e ne viene fuori una tavola rotonda. Pero' fa sempre bene ascoltare chi ne sa di piu', pure se, come mi sta accdendo in qualche passaggio, devi prima googlare un poco solo per avere idea vaga di cosa stiano dicendo ;) > Cerco di spiegarvi cosa vorrei fare. > Per adesso si tratta di una piccola applicazione per tener traccia di > accessi e pagamenti per una associazione. > > Scenario: > Qualche centinaio di utenti avranno una carta RFID (codice univoco) con la > quale potranno accedere alla sala dell'associazione. > Ad ogni codice nel db corrisponderà l'anagrafica, numeri di telefono ecc, > una decina di cose specifiche dell'associazione. > Oltre a questo, ogni ingresso/uscita andrebbe immagazzinato da qualche > parte. > All'ingresso vi sarà anche un controllo se l'utente è in regola con i > pagamenti delle quote associative. > Gli utenti possono essere di vario tipo (studenti/Adulti/pensionati) con > vari tipi di possibile associazione (mensile/annuale/n°di ingressi). > Tutti i controlli verranno fatti via sw appoggiandomi ad un db (sto > propendendo per mongodb... ma non sono ancora sicuro) > Io sapevo (ma posso sbagliarmi) che Mongo Db (che ribadisco quanto detto altrove trovo MOOOOLTO carino) era pensato per grosse moli di dati. > > Ho visto un po' di differenze tra db relazionali e documentali e penso che > per il mio caso non faccia molta differenza quale uso. (il numero di campi > sarà fisso) > Cosa che porta piu' verso il relazionale, o meglio, che e' caratteristica buona per un relazionale (*). > Anche i tempi delle varie query penso siano insignificanti in entrambi i > casi visto che si parla di qualche migliaio di dati. > Non mi è invece molto chiaro come posso immagazzinare tutte le date/ora > degli ingressi e uscite? suggerimenti? > Campi appositi di tipo date/time? (magari adesso mi darai del'idiota, ma possibile che non abbia capito bene la domanda). Come facilità d'uso cosa mi consigliate? mongodb? SQLite? > Sono tutti facili e tutti difficili. Il mio consiglio, basato sulla mia teoria che il miglior editor/ide/linguaggio/db/etc. e' quello con cui ti trovi meglio) e' di provare entrambi, giocarci un poco e poi decidere. > Dimenticavo... l'accesso al db avverrà sempre dallo stesso sw ma in due > modi distinti, tramite la gui con richiesta dell'utente e, in automatico > quando un utente "passa" la tessera con l'RFID, servirà prevedere thread > per questo? > Dipende da quanti user contemporaneamente accedono. > Grazie dell'aiuto (anche di domenica) > la domenica e' un giorno come gli altri se non sei un fanatico religioso. ;) * Per un progetto (che dorme nel cassetto da anni) avevo necessita' di tabelle che potevano avere un numero di campi variabili. Volevo pero' evitare una tabella correlata "1 a molti" per motivi di performance. Ed ero ricorso ad una tabella a 4 campi (va beh, tra id autoincrementale e altri accessori erano di piu' ma quelli importanti erano 4) e per la precisione identificatore della transazione (raggruppamento) tipologia dell'oggetto nome dell'oggetto valore dell'oggetto Si tratta di una applicazione per immobiliari, il primo campo era riferito alla proposta immobiliare, il secondo mi diceva se si trattava di prezzi, tipologie di transazione, descrizione di accessori, etc, il terzo era il nome dell'oggetto in se e l'ultimo il suo valore. Con un dirty trick riuscivo ad cercare proposte immobiliari variegate (esempio offerte in affitto di appartamenti con 3 camere, 2 bagni, posto auto, riscaldamento autonomo, tra il 2ndo ed il 4to piano, non attici, in una data zona e ad un prezzo massimo di x) ma era davvero una query poco ortodossa (una sommatoria di variabili messe a 1 se caratteristica presente). Poi ho scoperto MongoDb e tutto e' stato rivisitato in maniera naturale. Pero' e' un caso specifico dove la stessa proprieta' immobiliare puo' presentare un range di caratteristiche di cui alcune comuni (prezzo, indirizzo, tipologia), altre specifiche del tipo (un garage non avra' ascensore o giardino) ed altre ancora magari presenti solo per quella proposta (un appartamento con giardino pensile per dire). Carlos -- Je suis marxiste, de tendance Groucho.
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
