È una cattiva pratica creare una struttura di database sul runtime?

3

Sto creando un'app crawler che sarà sempre, all'inizio, quando il costruttore della classe, assicura che la struttura di base del database esista.

È una cattiva pratica? Qual è il vantaggio del SO che crea la struttura direttamente sul database?

import psycopg2
from datetime import timedelta

class DBManager:
    def __init__(self):
        self.connected = False
        self.conn = None
        self.cursor = None
        try:
            self.conn = psycopg2.connect()
            self.cursor = self.conn.cursor()
        except:
            print "I am unable to connect to the database"

        try:
            self.cursor.execute("BEGIN TRANSACTION;")
            self.cursor.execute('CREATE TABLE IF NOT EXISTS proxy(id SERIAL NOT NULL PRIMARY KEY,ip VARCHAR(15) NOT NULL,active BOOLEAN NOT NULL, times_used smallint default 0, last_use timestamp DEFAULT CURRENT_TIMESTAMP not null );')
            self.cursor.execute('CREATE TABLE IF NOT EXISTS app_update (time TIMESTAMP NOT NULL);')
            self.cursor.execute("""
                CREATE OR REPLACE FUNCTION merge_proxy(_proxy VARCHAR(15)) RETURNS void AS $$
                    BEGIN
                        IF EXISTS( SELECT * FROM proxy WHERE ip = _proxy ) THEN
                            UPDATE proxy SET active = TRUE WHERE ip = _proxy;
                        ELSE
                            INSERT INTO proxy(ip,active,times_used,last_use) VALUES (_proxy,TRUE,0,CURRENT_TIMESTAMP);
                        END IF;
                    END;
                $$ LANGUAGE plpgsql;
            """)
            self.cursor.execute("END TRANSACTION;")
            self.connected = True
            print 'ending creating tables'
        except:
            print 'unable to create table'
    
posta Renato Prado 16.09.2014 - 21:37
fonte

2 risposte

5

Dipende - principalmente dal ciclo di vita dei tuoi database e dallo scenario di utilizzo. Creare automaticamente le strutture DB ha senso se

  • il database viene utilizzato esclusivamente (o almeno principalmente) dall'applicazione

  • ti aspetti di avere non solo un database, ma molte diverse istanze di questa struttura in posti diversi

  • il database viene utilizzato come una sorta di memoria temporanea, archiviata o gettata via dopo l'uso

  • non ci sono requisiti di sicurezza che vietano alla tua applicazione di cambiare le strutture db

Ad esempio, quando si crea un database OLTP di grandi dimensioni, con molte applicazioni diverse che lo utilizzano, la creazione della struttura DB all'interno di una delle applicazioni è in genere una cattiva idea. In realtà non ha senso, dal momento che il DB è parte dell'ambiente che ci si può aspettare di essere disponibile per l'applicazione. In tale ambiente, le normali applicazioni in genere non ottengono nemmeno i diritti di accesso per modificare le strutture di DB.

D'altro canto, quando si costruisce un'applicazione di database per registrare o archiviare una serie di misurazioni su un periodo di tempo fisso (diciamo, per un giorno), le cose sono diverse. Supposto per ciascuno di questi periodi hai bisogno di una nuova istanza di db, la creazione di questa istanza automaticamente quando non è lì ha molto senso. In tali scenari è normale non utilizzare un sistema di database client / server completo, ma un sistema db leggero a file singolo.

Non so in quali di queste categorie cade la tua "app per crawler", ma controlla il tuo scenario in base ai punti che ho scritto sopra e prendi una decisione.

    
risposta data 16.09.2014 - 22:34
fonte
3

Generalmente è considerata una buona idea separare la configurazione dell'ambiente dall'applicazione principale. La prassi abituale per qualcosa di simile è avere le strutture del database create dal programma di installazione o dallo script di installazione. L'applicazione non dovrebbe creare le proprie strutture, se può aiutarla.

Un motivo per separarli potrebbe essere se si dispone di versioni leggermente diverse dello schema per diversi motori di database. Se il programma di installazione del database è separato dall'applicazione principale, l'utente può scegliere quale script di database è più appropriato per loro e quindi eseguire l'applicazione, piuttosto che lasciare che l'applicazione provi a indovinare ciò che l'utente desidera.

Inoltre, in che modo la tua applicazione gestirà i fallimenti nell'impostazione del database? A volte capita che l'impostazione standard che si desidera venga eseguita dagli utenti potrebbe non funzionare al 100% nel database di tutti gli altri, quindi l'amministratore di database potrebbe volerlo modificare per il proprio ambiente. L'incorporamento della configurazione direttamente nell'applicazione impedisce alle persone di farlo, ma potrebbe anche impedire alle persone di eseguire l'applicazione, se non sono in grado di apportare le necessarie modifiche alla configurazione per il loro particolare database.

... Se lo desideri, puoi fare in modo che l'applicazione controlli il database e, se non riesce a connettersi, chiedi all'utente se vuole che l'installazione funzioni. Quindi fai in modo che l'applicazione principale esegua lo script di configurazione prima di riprendere l'applicazione principale.

    
risposta data 16.09.2014 - 21:55
fonte

Leggi altre domande sui tag