sql >> データベース >  >> RDS >> PostgreSQL

データベース内で配列を使用するのは悪い設計ですか?

    タイトルへの短い答え :いいえ

    もう少し長い答え

    必要に応じて、配列の使用方法を学ぶ必要があります。配列自体は悪い設計ではなく、文字を変化させるフィールド(文字の配列、違いますか?)と同じくらいアトミックであり、私たちの生活を楽にし、データベースをより速く、より軽くするために存在します。移植性を考慮すると問題があります(ほとんどのデータベースシステムはアレイをサポートしていないか、Postgresとは異なる方法でサポートしています)

    例:

    投稿とタグのあるブログがあり、各投稿に0個以上のタグが含まれている可能性があります。最初に頭に浮かぶのは、2つの列postidを持つ別のテーブルを作成することです。 およびtagid そのテーブルにタグを割り当てます。

    tagidを使用して投稿を検索する必要がある場合は、追加のテーブルが必要です(もちろん適切なインデックスを使用)。

    ただし、タグ情報のみを投稿の追加情報として表示したい場合は、投稿のテーブルに整数配列列を簡単に追加して、そこから情報を抽出できます。これは追加のテーブルでも実行できますが、配列を使用するとデータベースのサイズが小さくなり(追加のテーブルや追加の行は不要)、選択したクエリを1つ少ないテーブルに結合して実行できるようになるため、クエリが簡素化され、理解しやすくなります。人間の目で(最後の部分は見る人の目にありますが、私はここで大多数を話していると思います)。タグがプリロードされている場合は、結合は1つも必要ありません。

    例は貧弱かもしれませんが、それが最初に思い浮かびました。

    結論

    配列は必要ありません。間違って使用すると有害な場合があります。それらがなくても生活でき、優れた高速で最適化されたデータベースを利用できます。移植性を検討している場合(たとえば、他のデータベースと連携するようにシステムを書き直す場合)、配列を使用しないでください。

    Postgresを使い続けることが確実な場合は、適切と思われる場所でアレイを安全に使用できます。それらは理由のために存在し、悪い設計でも非準拠でもありません。これらを適切な場所で使用すると、データベース構造とコードの単純化、およびスペースと速度の最適化に少し役立ちます。以上です。



    1. MariaDBで大文字に変換する方法

    2. PostgreSQL text[][]タイプとJavaタイプのマッピング

    3. ランニングトータル/ランニングバランスを計算する

    4. データベース:パイプライン化された関数