私は個人的には別々の列を持っているのが好き。私がマスキングすると考える唯一の場所は、データベースやアプリケーションが極端な条件下で実行されている場合や、メモリやスペースの使用が重要な低メモリやストレージデバイスで実行されている場合です。
1つのスペースは、クラス/テーブルが巨大なボリュームに拡大する可能性がある場合を除き、考慮しないでください。 ブールフラグをシミュレートするには、小さなint（1）で十分であり、必要なのは0/1の値だけです。
2テーブル上でクエリを実行したい、またはテーブルを使用してレポートを書きたいと思っている人にとっては、はるかに難しくなります。クライアントがデータベースにアクセスする場合は、ほとんどの場合、マスキングが受け入れられないと確信しています。
3 - 彼らが必要とされるときには、（データベースに基づいて）すべてで可能になります場合はより多くの作業とすべきではない多くのコードを書く
4-、この列に索引を作成するためにはるかに困難になります問題。あなたはもっと今働いていますが、将来はあまり働かないでしょう。それはプログラマーのためのより少ない仕事だと思って/ dbaはまさにイリュージョンIMHOです。
a-コードを維持してデータベースクエリを書き込むことは難しくなります。多分あなたは今あなたのJavaコードのすべてを行うが、あなたは未来が何を保持するか決して決してわからない。
構造変更がより困難になります。顧客が2つのフラグを削除して4を追加する必要がある場合はどうなりますか？削除されたフラグを保持していた元の2ビットをデータベースに保持し、4ビットを追加しますか？ 2つの新しいフラグのためにそれらを使用し、2つのビットを追加しますか？すでに書かれているコードにどのような影響を与えますか？すべての場所を追跡して実際にコードを変更するのはどれほど簡単でしょうか？
小さなアプリケーションでは、これは大きな問題ではありません。アプリケーションは時間とともに成長します。テーブルが広く使用されるようになると、これは非常に危険です。 7番目と8番目のフラグで作業していたコードが削除され、そのコードが削除され、同じ場所を再利用するように決定された場合、7番目と8番目のビットにアクセスするために使用されたコードは、 ）それが気づかれるまで。問題が発見されて修正されるまでは既に有害なことが起きる可能性があります。別の列があり、それらをドロップした場合、その列がそこには存在しないため、そのコードの最初の使用時にエラーが表面にポップアップします。
c- dbaのデータをアップグレードしたり、構造を変更するスクリプトを作成することは間違いありません。経験豊富なdbaは座って列名を次々と書き、スクリプトを生成するツールを使用しません。ビット操作では、彼は手作業で作業し、様々な選択/更新で彼が作成する表現を間違えないでください。
5つ以上はデータベースに関連しています。アプリケーションに達すると、あなたは無料です。 データベースから16個のフラグを読み取り、整数を生成することができます。コードはビット操作を使用でき、時間を節約することができます。私は個人的には、あまりにも良いことではないが、とにかくそれをあなたが選んだのも良いと思う。
私は集中していないと私は知っている私はこことそこに繰り返されている可能性があります。しかし、私は、あなたがあなたの事件のために正しい選択をするのを助ける長期的な考慮事項を見て、あなたを助けることができたことを願っています。
私はブール型を使用できませんでした。クライアントは、複数の選択肢が必要となるように仕様を変更しました。クラスでint []配列を使用して終了し、次にint []から単一の文字列に変換して戻します。インターフェイス要件のために、文字列をデータベースに格納します。かなりうまく動作します。 – Huntrods