Django-eav（元のパッケージはもはや管理されていませんが、いくつかの盛んなフォークがあります）
このソリューションは、エンティティ属性値データモデルに基づいています。基本的に、オブジェクトの動的属性を格納するためにいくつかのテーブルを使用します。このソリューションの優れた点は次のとおりです。
欠点：
- あまり効率的ではありません。これは、EAVパターン自体に対する批判であり、列形式のデータをモデルのキーと値のペアのセットに手動でマージする必要があります。
- メンテナンスが難しい。データの整合性を維持するには、複数列の一意のキー制約が必要です。これは、一部のデータベースでは効率的でない場合があります。
- 公式パッケージはもはやメンテナンスされておらず、明確なリーダーがいないため、フォークの1つを選択する必要があります。
使い方はかなり簡単です：
import eav
from app.models import Patient, Encounter
eav.register(Encounter)
eav.register(Patient)
Attribute.objects.create(name='age', datatype=Attribute.TYPE_INT)
Attribute.objects.create(name='height', datatype=Attribute.TYPE_FLOAT)
Attribute.objects.create(name='weight', datatype=Attribute.TYPE_FLOAT)
Attribute.objects.create(name='city', datatype=Attribute.TYPE_TEXT)
Attribute.objects.create(name='country', datatype=Attribute.TYPE_TEXT)
self.yes = EnumValue.objects.create(value='yes')
self.no = EnumValue.objects.create(value='no')
self.unkown = EnumValue.objects.create(value='unkown')
ynu = EnumGroup.objects.create(name='Yes / No / Unknown')
ynu.enums.add(self.yes)
ynu.enums.add(self.no)
ynu.enums.add(self.unkown)
Attribute.objects.create(name='fever', datatype=Attribute.TYPE_ENUM,\
enum_group=ynu)
# When you register a model within EAV,
# you can access all of EAV attributes:
Patient.objects.create(name='Bob', eav__age=12,
eav__fever=no, eav__city='New York',
eav__country='USA')
# You can filter queries based on their EAV fields:
query1 = Patient.objects.filter(Q(eav__city__contains='Y'))
query2 = Q(eav__city__contains='Y') | Q(eav__fever=no)
PostgreSQLのHstore、JSON、またはJSONBフィールド
PostgreSQLは、さらに複雑なデータ型をいくつかサポートしています。ほとんどはサードパーティのパッケージでサポートされていますが、近年Djangoはそれらをdjango.contrib.postgres.fieldsに採用しています。
HStoreField：
Django-hstoreは元々サードパーティのパッケージでしたが、Django 1.8は組み込みのHStoreFieldと、PostgreSQLがサポートする他のいくつかのフィールドタイプを追加しました。
このアプローチは、動的フィールドとリレーショナルデータベースの両方の長所を利用できるという意味で優れています。ただし、hstoreは、特に1つのフィールドに何千ものアイテムを格納することになる場合は、パフォーマンスに関して理想的ではありません。また、値の文字列のみをサポートします。
#app/models.py
from django.contrib.postgres.fields import HStoreField
class Something(models.Model):
name = models.CharField(max_length=32)
data = models.HStoreField(db_index=True)
Djangoのシェルでは、次のように使用できます。
>>> instance = Something.objects.create(
name='something',
data={'a': '1', 'b': '2'}
)
>>> instance.data['a']
'1'
>>> empty = Something.objects.create(name='empty')
>>> empty.data
{}
>>> empty.data['a'] = '1'
>>> empty.save()
>>> Something.objects.get(name='something').data['a']
'1'
hstoreフィールドに対してインデックス付きクエリを発行できます。
# equivalence
Something.objects.filter(data={'a': '1', 'b': '2'})
# subset by key/value mapping
Something.objects.filter(data__a='1')
# subset by list of keys
Something.objects.filter(data__has_keys=['a', 'b'])
# subset by single key
Something.objects.filter(data__has_key='a')
JSONField：
JSON / JSONBフィールドは、キーと値のペアだけでなく、JSONでエンコード可能なデータ型をサポートするだけでなく、Hstoreよりも高速で（JSONBの場合）コンパクトになる傾向があります。django-pgfieldsを含むいくつかのパッケージはJSON / JSONBフィールドを実装していますが、Django 1.9 以降では、JSONFieldはJSONBをストレージに使用する組み込み型です。
JSONFieldはHStoreFieldに似ており、大きな辞書を使用するとパフォーマンスが向上する可能性があります。また、整数、ブール値、ネストされた辞書など、文字列以外のタイプもサポートしています。
#app/models.py
from django.contrib.postgres.fields import JSONField
class Something(models.Model):
name = models.CharField(max_length=32)
data = JSONField(db_index=True)
シェルで作成：
>>> instance = Something.objects.create(
name='something',
data={'a': 1, 'b': 2, 'nested': {'c':3}}
)
インデックス付けされたクエリは、ネストが可能であることを除いて、HStoreFieldとほとんど同じです。複雑なインデックスには、手動での作成（またはスクリプトによる移行）が必要な場合があります。
>>> Something.objects.filter(data__a=1)
>>> Something.objects.filter(data__nested__c=3)
>>> Something.objects.filter(data__has_key='a')
Django MongoDB
または、他のNoSQL Djangoの適応-それらを使用すると、完全に動的なモデルを持つことができます。
NoSQL Djangoライブラリは優れていますが、Djangoと100％互換ではないことに注意してください。たとえば、標準のDjangoからDjango-nonrelに移行するには、ManyToManyをListFieldに置き換える必要があります。
このDjango MongoDBの例を確認してください。
from djangotoolbox.fields import DictField
class Image(models.Model):
exif = DictField()
...
>>> image = Image.objects.create(exif=get_exif_data(...))
>>> image.exif
{u'camera_model' : 'Spamcams 4242', 'exposure_time' : 0.3, ...}
Djangoモデルの埋め込みリストを作成することもできます。
class Container(models.Model):
stuff = ListField(EmbeddedModelField())
class FooModel(models.Model):
foo = models.IntegerField()
class BarModel(models.Model):
bar = models.CharField()
...
>>> Container.objects.create(
stuff=[FooModel(foo=42), BarModel(bar='spam')]
)
Django-mutant：syncdbとSouth-hooksに基づく動的モデル
Django-mutantは完全に動的な外部キーとm2mフィールドを実装しています。また、Will HardyとMichael Hall による信じられないほどのハックなソリューションに触発されています。
これらはすべてDjango Southフックに基づいています。DjangoCon2011 （Wit it！）でのWill Hardyの講演によると、それでも堅牢であり、運用環境でテストされています（関連するソースコード）。
これを最初に実装したのは、マイケルホールでした。
はい、これは魔法です。これらのアプローチにより、リレーショナルデータベースバックエンドで完全に動的なDjangoアプリ、モデル、フィールドを実現できます。しかし、どのようなコストで？頻繁に使用すると、アプリケーションの安定性が損なわれますか？これらは考慮すべき問題です。同時データベース変更リクエストを許可するには、適切なロックを維持する必要があります。
Michael Halls libを使用している場合、コードは次のようになります。
from dynamo import models
test_app, created = models.DynamicApp.objects.get_or_create(
name='dynamo'
)
test, created = models.DynamicModel.objects.get_or_create(
name='Test',
verbose_name='Test Model',
app=test_app
)
foo, created = models.DynamicModelField.objects.get_or_create(
name = 'foo',
verbose_name = 'Foo Field',
model = test,
field_type = 'dynamiccharfield',
null = True,
blank = True,
unique = False,
help_text = 'Test field for Foo',
)
bar, created = models.DynamicModelField.objects.get_or_create(
name = 'bar',
verbose_name = 'Bar Field',
model = test,
field_type = 'dynamicintegerfield',
null = True,
blank = True,
unique = False,
help_text = 'Test field for Bar',
)