:1.現在のデータベース設計時において先輩のような方法は使用してもいいのでしょうか?(実運用時に問題がでてこないのでしょうか?)2.そういう方法は流行っているのでしょうか?要は、(1)データーの容量が大きくなりすぎなくて、(2)インデックスが使えて、(3)運用のパフォーマンスが劣化しなければ、別にサイズ(型のサイズ)にこだわらなくて良いと思います。これらを満たすのかは知りませんが。クラスを使うだけですよね。最大長などの制約を付けたいのならば、制約(constraint)で付けたり、アプリケーションの側で付けたりすればよいことでしょう。将来のバージョンで削除されます。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。詳細については、「大きな値のデータ型の使用」を参照してください。19:53かめたろさん、unibonさん返信ありがとうございます。・かめたろさんntextが将来的に削除されるとは目からうろこでした。ありがとうございました。ntextの代わりにvarchar(max)を使用するようにしたいと思います。・unibonさん確かに先輩は、PostgreSQLが大のお気に入りで、よく利用しております。最終的に先輩の言っている内容を私は正直若干疑っていたのですが、問題なさそうなことが分かりました。ありがとうございました。21:20引用:2.最近の世の中の最近のシステムは皆そうだ。今私が作っているシステムは違うので「皆」ではないでしょうww#世の中には悪い先輩がたくさんいますね。00:16多くのRDBMSでは、インデクスを定義したり、ソートやグループ化する列に関しては、データ型や長さに制限があります。長大なデータを格納可能なデータ型は、行を物理的に格納する場合、基本となるレコードとは別のレコードとして格納されます。そのため、行の全列を操作する場合は、1行の操作で必ず複数回のI/Oが発生するといった問題もあります。Reserved.著作権はアイティメディア株式会社またはその記事の筆者に属します。当サイトに掲載されている記事や画像などの無断転載を禁止します。