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

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

新規登録して質問してみよう
ただいま回答率
85.51%
データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

5回答

3368閲覧

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

退会済みユーザー

退会済みユーザー

総合スコア0

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

0グッド

4クリップ

投稿2017/06/01 02:33

編集2017/06/01 12:05

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

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

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

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答5

0

ベストアンサー

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

  • マルチテナントのクラウドサービス化することを考えているなら、これらの設定値ほとんどはシステム設定値というよりは顧客ごとの動作設定ということになり、RDB格納、顧客ごとに行ができる、カラム数の多いテーブルになります。

設定フラグごとにカラムを作るのでなく、第一正規形違反なのですが64ビット整数であるBIGINTカラムに64個のフラグをビット単位で持たせてしまうやり方も有効です。アプリ側でフラグが増えるたびにADD COLUMNを流すのは大変ですし、このフラグ値を検索やソートや外部キー参照などの対象にすることはまずないので正規形でなくても困らないんですよね。

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

ただここで、JSONやXMLファイルにするのでなく環境変数にすることはできないかご検討ください(項目数が多いんで苦しそうですが)。
JSONやXMLファイルにするとしたら、開発リポジトリには本番用の設定ファイルを入れますか、それも開発用のを?
どちらも間違いのもとになる要素があるんですよね…
一つの手としては、項目数がとても多いので設定ファイルのJSONかなんかにする、リポジトリには本番用と開発用を両方入れる、どの設定ファイルを参照するかは環境変数で設定する、さらに環境変数で任意の項目を上書きできるということにしておく、とかだとそれなりに運用も合理化できそうです。

  • 稼働中にメンテタイムなしで設定変更が必要? 仕方ありません、RDBでもNoSQLDBでもに突っ込むしか。

投稿2017/06/01 02:47

yuba

総合スコア5568

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/06/01 11:44

ありがとうございます。 なるほど、ビット列をフラグとして表現するという方法が一般的に存在するのですね。 > 稼働中に設定変更することはまずなくて設定変更するのならシステムの瞬断も許されるということなら、RDB格納ではなく外部化します これは、具体的に何故か理由はありますでしょうか。 お手数をお掛けしますが、よろしくお願いします。
yuba

2017/06/02 00:20

RDB使わずに済ませられるのなら使いたくない理由は2つ。 1つは、RDBは開発も運用も高コストだということです。簡単な話、設定値をRDBに置くことにするとしたらそれを操作するためのUIアプリを追加で作らないといけません。設定ファイルや環境変数ならエディタ使えばいじれるのに。 UIアプリなんか作らなくてもRDBのコンソールに入ってしまえば操作できる? そうなのですが、これは2にも絡んでくることで… その2つめが、安全性、もしくはドメインの切り分けです。 RDBには稼働中のビジネスデータが入っています。設定変更するためにビジネスデータの保管庫に立ち入るのってどうですかとなります。 (金融機関の人事の人が、人事の仕事するために貸金庫エリアに入っていったらなんかおかしいです) ではスキーマ分けるかDBインスタンスを分けるかしてビジネスデータと設定データを独立させればいいか? はい、それはその通りです。 その場合、設定データはDBであればRDBでなくても構いません(RDBは開発運用が高コストながら大量の構造化データを整然と扱える、というものです)。 そしたらそこで思い出してください、ファイルシステムというのがそもそも高度なDBだったのでは、と。
退会済みユーザー

退会済みユーザー

2017/06/04 09:33

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

0

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

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

投稿2017/06/01 02:51

maisumakun

総合スコア145062

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/06/01 11:45 編集

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

2017/06/01 11:48 編集

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

退会済みユーザー

2017/06/01 11:57

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

0

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

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

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

投稿2017/06/01 05:23

Erda

総合スコア14

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/06/01 11:45 編集

ありがとうございます。 > システム起動時に一回だけしかロードしないマスタみたいな使い方なら外部ファイル化する これは、具体的に何故か理由はありますでしょうか。 今回考えている「仕様データ」とは、まさに「システム起動時に一回だけしかロードしないマスタ」です。 お手数をお掛けしますが、よろしくお願いします。
guest

0

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

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

投稿2017/06/06 12:19

takotakot

総合スコア1111

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2017/06/06 01:34

hihijiji

総合スコア4150

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問