既存のテーブルに列を追加することは悪い習慣ですか？
逆に、新しいテーブルが作成されるときにすべての列を作成する方が良いですか？
私は新しいシステムに取り組んでおり、新しい要件が常に出てきます。最新の要件は、古いシステムと新しいシステムの間でデータを簡単に相関させることができるように、各顧客に新しいタグフィールドを追加することです。新しいシステムはまだ本番環境にはありませんが、移行プロセスのいくつかのテストが実行されています。
現在のところ、テーブルを削除してバッチロードを再実行することは依然として可能ですが、システムに大量のライブデータがあり、新しい列が必要になった場合はどうなりますか。たとえば、データをエクスポートし、すべての列を含むテーブルを再作成し、ALTER TABLE ADD列を実行するだけでデータを再度インポートするには、...
違いがある場合、ソリューションはPostgreSQL 9.5に基づいており、違いがある場合、どのDBMSが大体気になっているのかを知ることは興味深いでしょう。
この列にインデックスが作成されているかどうかは回答に影響しますか？たとえば、一意の制約が設定されている場合。
ALTER TABLEには理由があります。さらに真剣に、非常に大きなデータセットを計画しているのでない限り、オンデマンドで新しい列を追加することについて心配する必要はありません。テーブルを削除して再作成することは、（重要な）データがなくなるまでしか実行できません。つまり、後でALTER TABLE ... ADD COLUMNを使用する必要があります。
上記で「本当に大きい」と述べたとき、それは列の定義に使用されるさまざまなデータ型の調整とパディングについてです。たとえば、列がこの順序であるテーブルの行(smallint, integer, smallint)は、(smallint, smallint, integer)がある列よりも少し（2バイト）広くなります。これは、数百万行の10の（適切なハードウェアではおそらく100の）テーブルでのみ、またはテーブルに多くの列およびがある場合にのみ、違いを生み出し始めます行。この詳細については、Erwin Brandstetterの excellent answer をご覧ください。
新しい列を追加するときは、ALTER TABLE ... ADD COLUMN ... NOT NULL DEFAULT ...のトラップに注意してください。 ALTER TABLE ... ADD COLUMNは、同時セッションのテーブルへのアクセスを妨げる重いロックを必要とするため、トランザクションをできるだけ短くする必要があります。これを行うことができた場合、新しい列を追加しても、他のプロセスにとってパフォーマンス面でほとんど目立ちません。
列がNULLを許可する場合、データベースの観点からの影響なしに追加できます。この列に大量のデータを入力すると、混乱します。
新しい列にNOT NULL制約がある場合、多くのレコードがあるため、非常に重くなります。
したがって、状況によって異なります。 null許容列を無料で追加できます。
既存のテーブルに新しい列を追加すると、パフォーマンスヒットが1回になります。
たとえば、既存のテーブルと同じキーを持つ新しいテーブルを追加して新しい列を含める場合、クエリでそれらを一緒にJOINする必要があるたびに、パフォーマンスヒットが発生します。
新しい列が既存のテーブルが表すものと同じエンティティの属性である場合は、先に進んで追加します。