web-dev-qa-db-ja.com

悪い習慣は、ランタイムにデータベース構造を作成することですか？

私は、最初に常にClassコンストラクターが基本的なデータベース構造が存在することを確認するクローラーアプリを作成しています。

これは悪い習慣ですか？ OSがデータベースに直接構造を作成する利点は何ですか？

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'
databasepythonpostgres
3
Renato Prado

それは、主にデータベースのライフサイクルと使用シナリオに依存します。次の場合、DB構造の作成は自動的に意味があります。

  • データベースはアプリケーションによって排他的（または少なくとも主に）に使用されます

  • 1つのデータベースだけでなく、さまざまな場所にこの構造のさまざまなdbインスタンスが存在することを期待している

  • データベースは、アーカイブされるか、使用後に破棄される、ある種の一時ストレージとして使用されます

  • アプリケーションにデータベース構造の変更を禁止するためのセキュリティ要件はありません

たとえば、大企業を構築している場合OLTPデータベースを使用し、多くの異なるアプリケーションがそれを使用している場合、いずれかのアプリケーション内にDB構造を作成することは、通常、悪い考えです。実際にはつまり、DBはアプリケーションで利用できることが期待できる環境の一部であるため、通常、通常のアプリケーションは、DB構造を変更するためのアクセス権さえも取得しません。

一方、一連の測定値を一定期間（たとえば、1日とする）記録または保存するためのデータベースアプリケーションを構築する場合は、状況が異なります。これらの期間ごとに新しいdbインスタンスが必要であると想定すると、そこにないときにこのインスタンスを自動的に作成することは、非常に理にかなっています。このようなシナリオでは、本格的なクライアント/サーバーデータベースシステムではなく、軽量の単一ファイルデータベースシステムを使用するのが一般的です。

「クローラーアプリ」がこれらのカテゴリのどれに該当するかはわかりませんが、上で書いたポイントに従ってシナリオを確認し、決定を下します。

5
Doc Brown

一般に、環境設定をメインアプリケーションから分離することをお勧めします。このようなことの通常の慣行は、インストーラーまたはセットアップスクリプトによってデータベース構造を作成することです。それがそれを助けることができるならば、アプリケーションはそれ自身の構造を作成するべきではありません。

これらを分離する理由の1つは、データベースエンジンごとにスキーマのバージョンがわずかに異なる場合です。メインアプリケーションとは別のデータベースインストーラーを使用している場合、ユーザーは自分に最も適したデータベーススクリプトを選択してから、アプリケーションにユーザーが求めているものを推測させるのではなく、アプリケーションを実行できます。

また、アプリケーションはデータベース設定の失敗をどのように処理しますか？実行したい標準設定が他のすべてのデータベースで100％機能しない場合があるため、DBAは自分の環境に合わせて調整する必要がある場合があります。セットアップをアプリケーションに直接埋め込むと、これを実行できなくなりますが、特定のデータベースのセットアップに必要な変更を加えることができない場合、アプリケーションを実行できなくなる可能性もあります。

...本当に必要な場合は、アプリケーションでデータベースを確認し、接続できない場合は、セットアップを実行するかどうかをユーザーに尋ねます。次に、メインアプリケーションを再開する前に、メインアプリケーションでセットアップスクリプトを実行します。

3
FrustratedWithFormsDesigner