[Python] python SQL?

[Carlos Catucci]

2014-02-16 14:50 GMT+01:00 Perini Matteo <perini.matteo a 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.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140216/e1c1ebc1/attachment.html>