2016-04-28 4 views
0

1Mレコードを少し上回るいくつかのテーブルでいくつかのテストを行いました。さまざまなカラムタイプを追加/削除するためにALTER TABLE文を実行すると、テストマシンでは約13秒かかります。 EAVモデルに?複数の中規模のテーブルでALTER TABLE文を扱う人はいますか?

いくつかのMレコードでテストを行っている理由は、私の具体的な使用例では、動的に作成されたテーブルごとに5M以上のレコードがあるとは思わないが、テーブルとフィールドは多くの検索されます。私はフィールドがそれを頻繁に変えるとは思わない。

このワークフローを使用して、EAVモデルとは逆のテーブルに列を動的に追加する人はいますか?もしそうなら、それはどのように比較されますか?

ありがとうございました。

+0

SharePoint:} – user2864740

+1

一般的に、テーブルから列を追加したり削除したりする場合は、データモデルに問題があります。 –

+0

@ GordonLinoff - カスタムフィールドを考える。 – Twisted1919

答えて

0

EAV(別名「拡張可能フィールド」、「カスタムフィールド」など)にALTER TABLEを使用することは、常に悪い考えです。ほとんどの場合、既存のテーブルに新しいカラムNULLを追加することは、あまりにも高価な操作ではありませんが、カラムの削除、並び替え、追加なしの挿入は非常に高価です。多くの場合、すべてのデータを新しい宛先テーブル(テーブルレベルのロックでトランザクション内で行わなければならない)オリジナルを削除する際に、外部キー制約の削除と再作成も忘れないでください。

理想的には、EAVデータは、疎なデータを扱い、EAVに必要な特別な制約を強制する専用EAVデータベースシステムに格納する必要があります(例えば、特定の親エンティティまたは他のビジネスルールに許可されるEAV属性の制限) 。多くの場合、これはNoSQLまたはDocument-Storeデータベース(MongoDBなど)で行われます。

しかし、唯一のツールがMySQLで他のタイプのサーバーを実行できない場合は、以下のようなデータを保存するための実際のEAVパターンを採用する方がよいでしょう。(疑似コードSQL)

CREATE TABLE Attributes (
    AttributeId bigint IDENTITY(1,1) PRIMARY KEY 
    Name nvarchar(50), 
    Type smallint /* some enum you define */ 
) 

CREATE TABLE AttributeHolders (
    HolderId bigint IDENTITY(1,1) PRIMARY KEY 
) 

CREATE TABLE AttributeValues (
    HolderId bigint FK AttributeHolders.HolderId, 
    AttributeId bigint FK Attributes.AttributeId, 

    TextValue nvarchar(100) NULL, 
    IntValue bigint NULL, 
    DateValue datetimeoffset NULL 
) 

次に、あなたの他のエンティティテーブルからAttributeHolders.HolderIdにFKを追加し、同じHolderIdを共有するそれらのエンティティの異なるインスタンスを防ぐ制約を追加する必要があります。

...これは読者に残っている問題です。残念ながら、簡単なクロスプラットフォームソリューションはありません。 1つの選択肢はHoldersになることができるさまざまなエンティティの識別値ソースとして機能するSEQUENCEオブジェクトを作成することです。