2017-12-05 14 views
1

私の全体的なユースケースでは、多少のデータベースには無関係(PostgresとMySQLをサポートする以上)のデータを生のテキストとして保存できるかどうかを判断しようとしています。 MySQLの文字列/テキスト型についてはthis answerに基づいていますが、LONGTEXT型だけが自分の要件を満たすことができるようです。私は可変長文字列のためのそのText列型を主張するSQLAlchemyを使用していますが、一般的にデータベースのCLOBまたはTEXT型にマップしています。 MySQLにはCLOB型はありませんが(BLOBはありますが)、TEXT型は自分のニーズには不十分です。SQLAlchemyがMySQLの「テキスト」に使用する列の種類は何ですか?

したがって、SQLAlchemyはMySQLの「テキスト」にどのような列タイプを使用しますか? SQLAlchemyのはLONG​​TEXTをサポートよう

+0

'TEXT'が十分でない場合、' BLOB'型を使用する必要があります。 –

+1

@TimBiegeleisen、MySQLでは、 'TEXT'と' BLOB'はどちらも長さ64KBのコンテンツをサポートしています。 https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html –

答えて

1

はルックス:

$ python 
Python 2.7.13 (default, Sep 29 2017, 15:31:18) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> from sqlalchemy.dialects.mysql import LONGTEXT 
>>> 

は、ここでは、ベンダー固有の型を使用する方法を参照してください:完全ブランド中立データベース層を開発しようと、それは価値がある何のため http://docs.sqlalchemy.org/en/latest/core/type_basics.html#vendor-specific-types

をされます困難であり、努力する価値はほとんどありません。私は数年前にZend Framework 1.0で作業しましたが、そのフレームワークでサポートされているすべてのSQLデータベース用の汎用ユニットテストスイートを作成しようとしました。 ANSI/ISO SQL標準をサポートすると主張しているにもかかわらず、すべてのSQL実装で同じようにサポートされるデータ型はごくわずかです。

最終的には、データ層に独自のクラス階層を作成し、データベース固有のアダプタごとにコードを少しずつ実装する必要があります。


更新:ニュースは私たちが考えるより優れていると思います。私はそれがMySQLデータベースに作成することになったか見て確認後

t2 = Table('t2', metadata, 
     Column('id', Integer, primary_key=True), 
     Column('t1', String(64000)), 
     Column('t2', String(16000000)), 
     Column('t3', String(4294000000)), 
     Column('t4', Text) 
    ) 

metadata.create_all(engine) 

:私はこのテストを試してみました

mysql> show create table t2; 

CREATE TABLE `t2` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `t1` mediumtext, 
    `t2` longtext, 
    `t3` longtext, 
    `t4` text, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 

だから行い、多かれ少なかれにマップSQLAlchemyののジェネリックStringデータ型適切なMySQLデータ型。

予想より大きいデータ型を使用していることは驚くことではありません。 MEDIUMTEXTは、バイトの16MBをサポートし、文字のではサポートされていません。私のデフォルトの文字セットはマルチバイトのutfmb4なので、MEDIUMTEXTの最大長は実際には2^24文字よりはるかに少ないです。そこで、それをLONGTEXTにアップグレードしなければなりませんでした。もちろん、2^32文字はLONGTEXTには入りませんが、SQLAlchemyではカラムを作成することを意味しているようです。

私はまだ完全に実装中立のコードを行うのは難しいと思います。たとえば、ストレージエンジンのテーブルオプションのようないくつかのMySQL機能や、同等のものがない特定のデータタイプ(たとえば、ENUM)を使用する場合はどうなりますか?

+0

ありがとう!知っておくと便利ですが、PostgresはLONG​​TEXTをサポートしていませんが、TEXTタイプは大きなデータをサポートしています。私はできる場合は、PostgresとMySQLのための別のロジックを避けたい – augray

+0

私はそれが可能だとは思わない。私のゲストですが、数ヶ月後に同じ結論に来ると思います。 –

+0

私はちょっと恐れているかもしれません!今すぐ "探検のオプション"の段階で、可能であれば、その恐怖を確認するか反論したいと思う。 SQLAlchemyのベンダーのニュアンスの大部分を抽象化する魅力は、私のケースでは実現可能性がある唯一の理由です – augray

関連する問題