1

現在、次のようなテーブルがありますPages, Groups, GroupPage, Users, UserGroup。pickled セットを使用すると、3 つのテーブルのみで同じことを実装できますPages, Groups, Users。

setグループおよびパーミッション関連の操作はセットで非常に自然に表現できるため、ACL を実装するための自然な選択と思われます。許可/拒否リストをピクルセットとして保存すると、多対多関係の中間テーブルがほとんどなくなり、多くのデータベース操作なしで権限の編集が可能になります。

人間の可読性が重要な場合は、シリアル化に cPickle の代わりに json をいつでも使用できset、Python でアクセス許可リストを操作するときに使用できます。SQL を使用して権限を直接編集することはほとんどありません。それで、それは良いデザインアイデアですか？

SQLAlchemy を ORM として使用しているため、column で実装される可能性がありPickleTypeます。ピクルス化された「リソース」レコードセット全体を保存するつもりはなくset、「リソース」の主キー値から作成されたオブジェクトのみを保存する予定です。

4

4 に答える 4

3

セットをピクルする場合は、適切なオブジェクト データベース ( ZODBなど) を見つける必要があります。純粋なリレーショナルの世界では、セットは BLOB として保存され、うまく機能します。ORM の状況でセットを pickle しようとすると、ORM マッピングで混乱を招く問題が発生する可能性があります。これは、ほとんどの場合、デコードする必要のある BLOB を含まない純粋なリレーショナル マッピングを想定しているためです。

セットおよびその他のファースト クラスのオブジェクトは、実際にはデータベースに属するものです。リレーショナル データベースの方が「優れている」と考えている人もいるため、ORM はハックです。そのため、マッピング レイヤーをハックします。

オブジェクトデータベースを使用すると、多くの場合、物事がはるかにスムーズになることがわかります.

編集

SQLAlchemy には独自のシリアライザがあります。

http://www.sqlalchemy.org/docs/05/reference/ext/serializer.html

これは pickle でも cPickle でもありません。ただし、拡張可能である必要があるため、pickle のように動作します。これは、目的のために、必要なだけ高速になります。ACL を常に逆シリアル化するわけではありません。

于 2009-04-26T11:24:59.243 に答える
2

私は、アクセスに使用される特定のプログラミング言語から独立した形式で、リレーショナル DB に永続的な情報を保持することに固執します。Python が大好きなのと同じように (そして、それはたくさんあります)、いつの日かそれにアクセスしたいと思うかもしれません。他の言語からの情報であり、Python 固有の形式を選択した場合...男の子はそれを後悔することはありません...

于 2009-04-26T19:18:26.313 に答える
2

DBMS が提供するものとは何か、再実装する必要がある機能はどれかを検討する必要があります。並行性の問題は大きな問題です。考慮すべき競合状態がいくつかあります (異なるスレッドやプロセスで複数の書き込みが行われ、新しいデータが上書きされるなど)、パフォーマンスの問題 (書き込みポリシー? プロセスがクラッシュしてデータが失われた場合は?)、メモリの問題 (アクセス権セットの大きさはどれくらいですか? RAM にすべて収まりますか?)。

十分なメモリがあり、同時実行性について心配する必要がない場合、ソリューションは適切なものになる可能性があります。それ以外の場合は、データベースに固執します-データベースはこれらの問題を処理し、データを常にある一貫した状態から別の状態に移動できるようにするために多くの作業が行われました.

于 2009-04-26T11:18:04.330 に答える
1

それが物事を簡素化し、ファイルをあまり編集しない (または編集する頻度が低い) 場合は、それを選択します。もちろん、考慮すべき 3 番目のオプションは、sqliteデータベースを使用してこのデータを保存することです。これらを人間が簡単に読めるようにするためのツールがあります。

于 2009-04-26T11:26:36.510 に答える