質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.55%

DB設計における仕様データの扱いについて

解決済

回答 5

投稿 編集

  • 評価
  • クリップ 4
  • VIEW 1,879
退会済みユーザー

退会済みユーザー

データベース初心者です。素っ頓狂なことを言っていたら申し訳ありません。

DB設計について疑問です。

リレーショナルデータベースシステムを使用して例えばPOSシステムを構築するとします。
その際、顧客情報や日報情報など、複数レコードが想定されるデータに関しては、テーブルを定義してRDBSに格納すると効率よくシステムを運用しやすくなるでしょう。

しかし、システムの仕様(「自動入金チェックの有無(true or false)」や「緊急時のロック機能の有無(true or false)」など)のような2値データの集合は、どのように表現するのが一般的なのでしょうか。


ここで、条件を以下のように定義します。

  • システムの仕様である2値の設定データが1000個あるとします(極端ですが)。
  • システムとして定期的なバックアップを行います。RDBSに格納しているデータに関しては、RDBSに備わっているバックアップ機能を用います。
  • システムの仕様データも、バックアップ対象とします。
  • システムの仕様データは、システム起動時に一回だけロードし、メンテナンス時以外はその後アクセスしません。

私の中で現状考えられるのは以下です。

  1. 仕様データもRDBSに格納する。そのために、「自動入金チェックの有無」や「緊急時のロック機能の有無」のようなカラムを1000個用意した1レコードからなるテーブルを用意する。
  2. 仕様データは、xmlやjson形式のファイルで用意し、RDBSとは別途に格納する。ただし、この場合はRDBSのバックアップ機能の対象外となるので、別途バックアップ機能を実装する。
  3. 2に似ているが、XMLDBSを別途用意し、仕様データに関しては、XMLDBSで運用する。

自分なりに、上記のメリット・デメリットを考えてみました。

  • 1は、RDBSで完結してデータを格納でき、RDBSのバックアップ機能をそのまま使える。しかし、仕様データのテーブル表現が不自然に感じ、データを取り扱う際もRDBのメリットがないように思える
  • 2は、直感的に仕様設定を定義でき、仕様に関するメンテナンス性もよいと思う。しかし、バックアップ機能を別途実装する手間がある
  • 3は、2のメリットに加え、アクセス効率も良い。しかし、XMLDBSを立てるコストがある。

皆様の業務上の経験や、一般則等ありましたらお教えいただければ幸いです。
また、質問内容自体がおかしかったり、不自然な構成を想定しているようであれば、その点の指摘も頂ければと思います。
よろしくお願い致します。

 補足です。

条件に以下を追加します。

  • エンドユーザには、クライアントサーバ形式でシステムを提供する。エンドユーザは基本的にはクライアント側しか操作しないが、データベースはサーバ側に格納する。

イメージとしては、店舗内にPOS端末(クライアント)が複数あり、売り上げ情報等をサーバのデータベースを管理しているという感じです。
店舗全体としての仕様データをサーバ側に格納するものと考えています。

後出しで申し訳ありません。よろしくお願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

checkベストアンサー

+9

ユースケースによって最適な方法は決まってきます。

  • マルチテナントのクラウドサービス化することを考えているなら、これらの設定値ほとんどはシステム設定値というよりは顧客ごとの動作設定ということになり、RDB格納、顧客ごとに行ができる、カラム数の多いテーブルになります。
    設定フラグごとにカラムを作るのでなく、第一正規形違反なのですが64ビット整数であるBIGINTカラムに64個のフラグをビット単位で持たせてしまうやり方も有効です。アプリ側でフラグが増えるたびにADD COLUMNを流すのは大変ですし、このフラグ値を検索やソートや外部キー参照などの対象にすることはまずないので正規形でなくても困らないんですよね。
  • そうでなく、また、稼働中に設定変更することはまずなくて設定変更するのならシステムの瞬断も許されるということなら、RDB格納ではなく外部化します。
    ただここで、JSONやXMLファイルにするのでなく環境変数にすることはできないかご検討ください(項目数が多いんで苦しそうですが)。
    JSONやXMLファイルにするとしたら、開発リポジトリには本番用の設定ファイルを入れますか、それも開発用のを?
    どちらも間違いのもとになる要素があるんですよね…
    一つの手としては、項目数がとても多いので設定ファイルのJSONかなんかにする、リポジトリには本番用と開発用を両方入れる、どの設定ファイルを参照するかは環境変数で設定する、さらに環境変数で任意の項目を上書きできるということにしておく、とかだとそれなりに運用も合理化できそうです。
  • 稼働中にメンテタイムなしで設定変更が必要? 仕方ありません、RDBでもNoSQLDBでもに突っ込むしか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/06/01 20:44

    ありがとうございます。

    なるほど、ビット列をフラグとして表現するという方法が一般的に存在するのですね。

    > 稼働中に設定変更することはまずなくて設定変更するのならシステムの瞬断も許されるということなら、RDB格納ではなく外部化します

    これは、具体的に何故か理由はありますでしょうか。
    お手数をお掛けしますが、よろしくお願いします。

    キャンセル

  • 2017/06/02 09:20

    RDB使わずに済ませられるのなら使いたくない理由は2つ。

    1つは、RDBは開発も運用も高コストだということです。簡単な話、設定値をRDBに置くことにするとしたらそれを操作するためのUIアプリを追加で作らないといけません。設定ファイルや環境変数ならエディタ使えばいじれるのに。
    UIアプリなんか作らなくてもRDBのコンソールに入ってしまえば操作できる? そうなのですが、これは2にも絡んでくることで…

    その2つめが、安全性、もしくはドメインの切り分けです。
    RDBには稼働中のビジネスデータが入っています。設定変更するためにビジネスデータの保管庫に立ち入るのってどうですかとなります。
    (金融機関の人事の人が、人事の仕事するために貸金庫エリアに入っていったらなんかおかしいです)

    ではスキーマ分けるかDBインスタンスを分けるかしてビジネスデータと設定データを独立させればいいか?
    はい、それはその通りです。
    その場合、設定データはDBであればRDBでなくても構いません(RDBは開発運用が高コストながら大量の構造化データを整然と扱える、というものです)。
    そしたらそこで思い出してください、ファイルシステムというのがそもそも高度なDBだったのでは、と。

    キャンセル

  • 2017/06/04 18:33

    なるほど、1と2の両方について、納得いたしました。
    ありがとうございます。

    キャンセル

+4

結論から言えば、2の「別途ファイルで持たせる」がいいと考えます。

どれだけDBにデータを持たせるにしても、DBの接続情報など、原理的にDBへ格納できないデータは存在しますので、結局ファイル単位のバックアップも必須となるからです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/06/01 20:41 編集

    ありがとうございます。

    例えば、クライアント側にはDB接続情報を持たせますが、サーバー側(データベース実装側)に設定ファイルを持たせるとした場合でも、同様に2となりますでしょうか。
    これは、クライアント側でDB接続設定ファイルをバックアップ処理するなら、同じバックアップ処理モジュールをサーバ側でも流用して設定ファイルをバックアップすればよいという理由からでしょうか。
    お手数をお掛けしますが、ご教授お願いします。

    キャンセル

  • 2017/06/01 20:48 編集

    すみません、Webサーバ上のアプリのような、「DBクライアント」もサーバ上で動くもの、という前提で考えていました。エンドユーザーがクライアントを持つ形態だと、ちょっとこれでは合わないかもしれませんね。

    キャンセル

  • 2017/06/01 20:57

    すみません、質問が不適切でした・・・
    「エンドユーザがクライアントを持つ」とはどこにも書いていませんね・・・
    失礼しました。

    ありがとうございます。

    キャンセル

+1

システム起動時に一回だけしかロードしないマスタみたいな使い方なら外部ファイル化する。
中断データのように頻繁に更新される値ならDBに入れる。

アクセスするテーブルに顧客数分(0~数百万)レコードあったとして、どれくらい起動が遅くなるかかな。
メンテナンス性は作る側の都合なので、まずSLAですね。起動が遅いとそれはもう文句を言われます。不具合です。

ビット単位にフラグを持つのはあるあるですね。何個目がなんのフラグだとか。
拡張がとても楽ですが、仕様書が更新されてなくてよく死にます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/06/01 20:36 編集

    ありがとうございます。

    > システム起動時に一回だけしかロードしないマスタみたいな使い方なら外部ファイル化する

    これは、具体的に何故か理由はありますでしょうか。
    今回考えている「仕様データ」とは、まさに「システム起動時に一回だけしかロードしないマスタ」です。
    お手数をお掛けしますが、よろしくお願いします。

    キャンセル

0

DBの一つのカラムにテキスト扱いでJSONやXMLを放り込むって手もあります。
利点:
・仕様変更に強い
・安い
・バックアップの心配がない。
・DBMSによってはもっと便利な機能がある。
欠点:
・フロントエンドがリッチでないととても扱えない。
・DBMSによってはカラムサイズの制限により扱えない。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

補足事項に合致しないのかもしれませんが、(プログラム側で決めておいた) ENUM 又は、定義した文字列を key にして、KVS の感覚で RDB に格納するのは不自然ではないと思います。
RDB の場合は操作するための UI は確かに必要ですが、一本化のメリットは大きいです。顧客に同一サーバを使用させる場合でも、顧客 id も id に入れておけばよい話です。

ただし、『設定変更するためにビジネスデータの保管庫に立ち入るのってどうですかとなります。』が尤もで、これを超える意見はないと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.55%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる