DBの選定基準

Question

開発ではないのですが、迷った末に質問致します。

中小企業向けの商品管理システムの製造でDB設計をやることになりました。

で、DBの選定から行う事になったのですが、
さすがに経験が無いので皆様に質問です。

前提条件
・取扱データ量に関してはまだ見えていません。
・トランザクションは楽観的排他処理でOK。
・予算は安い方が良い(Oracleなどの有料DBも選択可)
・リレーショナルデータベースであること
・使用するプログラムの開発言語はC#.NetとWPF(ClickOnceによる配布)
・サーバはタワー型のWindows Server 2012 R2 を予定(linuxでも可)
・DBを搭載するサーバはDB専用サーバとして構築

当然、ユーザーから見れば予算を抑えたいだろうと思い、
私のDB使用経験のあるものから

・SQL Server Express (データ容量の制限はデータ保持期間に制限を設けるなどで検討)
・MySQL
のいずれかかな、と考えています。

当方、本職は事務方なので、現在のメジャーなDBの種類などにも疎いです。

皆様であればどういうDBを選択なさるのか、
そのDBのどういうメリットを見込んで選択されたのか、
などのご意見を頂けませんでしょうか？

2017/01/30追記
やはり技術的な質問ではないのか、なかなかご意見頂けませんね。
2017/02/01に締め切らせて頂きます。

2017/01/31追記
各DBの特徴と良し悪しの点などをお出しいただいたPanzer_vorさんからの回答をベストアンサーとさせていただきました。
また、私からのコメントで技術情報から脱線する話も多くなり、誠に申し訳ありません。
ただ、そういった中でも得られることは多く、技術サイドの方との話をする際に具体的に意見を求めやすくなる情報も多く頂き、感謝いたします。
皆様、ご回答・ご意見を頂きありがとうございました。

Answer 1

• MySQL
• SQL Server
• Oracle
• PostgreSQL

当方が触れたことがある上記４点に軽く触れながら回答してみます。
(※DB2は分かりません・・・^^;)

C#.NET、Windows ServerとWindows製品で固めるのであればMySQLよりSQL Serverを迷わず推したい所ですが、
Express版というのがちょっと引っかかりはします・・・。

一応SQL Serverの採用理由としては以下のような感じ。
0. .NETとの親和性が高い(いろいろ便利機能が使える)
0. 開発・管理用コンソールがVisual Studioとほぼ同様の操作性で利用可
0. ウィンドウ関数、CTEなど割と標準SQLに準拠

ただしExpress版の制限を見てると、
DBを長期的に運用するにあたり、
割と準備されてて欲しい機能が使えなかったり制限がかかっているようです。

なので本当にExpress版でいくならその辺りを慎重に検討すべきかと思います。

MySQLは個性が強いので、
個人的には苦手だったりしますが、
無償のRDBMSとしてはシェア的には抜けてます。
比較的規模が小さいシステムとなるのであれば、
MySQLも選択肢としては良いのかもしれません。
手軽に環境が構築できるのも強みです。

また同じく無償のRDBMSとしてPostgreSQLがありますが、
環境設定周りや大量データの取り扱いには少し手を焼く印象です。

ただしMySQLと比べると、
標準SQLへの準拠率は高くウィンドウ関数、CTEも利用可能です。
更にVer9.5からはUPSERT機能も追加されており、
より使いやすくはなっています。
ただし.NET、Windows Serverとの親和性については扱ったことがないので何とも判断できません。
(書き忘れてましたが、MySQLも同じく親和性の判断はつかないです。)

要件的に予算は安い方が良いとあるので、
Oracleはそもそも厳しいかもしれませんね。

それだったらSQL Serverの方が安価なので、
まだ説得する見込みはあるかもしれません。

---

長ったらしく書きましたが、
まとめると下記の順に推奨します。

・SQL Server Expressの制約が飲める場合
→ SQL Server Express

・制約が飲めない場合
→ MySQL、PostgreSQLのいずれか
(使い勝手はPostgre、手軽さはMySQLに軍配が上がります。)

・お金は多少かけても良い場合
→ SQL Server製品版

・お金を突き抜ける場合
→ Oracle

こんな所でしょうかね。

Comments

[kurori]

スマホより。
ご意見有難うございます。

私も経験があるのは上記の4DBですが、Postgresを上げてないのは以下の理由からです。

1.サードパーティツールのPgAdminの品質が安定しない。(3では接続が頻繁に切れる、4ではバックアップ機能が問題を抱えているなど)

2.トランザクションの速度が遅い(あくまで体感ですが、大量データを取り込む場合などでは、上記4DBの中でもっとも遅い？)

MySQLの.Net系の言語との互換では特に困ったことはなかったので問題ないかと。
(いくつかの案件で経験済み)

Oracle自体は優秀なのですが、ODACでの接続だと64bitと32bitのExeが入り乱れる場合に、ODACのバージョン管理が煩雑で苦しいイメージがあります。
まぁ、こちらは他に方法も有るとは思いますが。

参考にさせていただきますm(__)m

[Panzer_vor]

> kuroriさん
確かにpgAdminは解せないですね。
当方はLinuxとPostgreのペアで基本コマンドベースでやることが多かったので使う機会もあまりなくあまり意識してませんでしたが。

Postgreは大量データの操作は他よりも工夫する必要が多いですね。
大量データを削除するなら、
DROP、CREATEで入れ直した方が早いとか、
COPY句噛ませた方が早いなど・・・

[kurori]

>Panzer_vorさん
私も個人でSQLの勉強するときはLinux + Postgresの組み合わせですね。
この組み合わせは仮想で立てて軽量なのが個人的には魅力ですね。
>DROP、CREATEで入れ直した方が早い
>COPY句噛ませた方が早い
確かにこういう問題もありましたね。
最初はBULK INSERTやろうとして首を捻ってた経験があります。

Answer 2

システムの運用主体は誰になるのでしょうか？
ユーザに納品したら運用はユーザが主体でしょうか？
その場合kuroriさん、kuroriさんの会社はどのような立場になるのでしょうか？
ユーザサポートを受けるのか、納品して終わりになるのか。

アプリケーションがWindows(.Net)ベースとの事で、Windows+SQL Serverにしてはと言いたいところですが、運用者のOSやDBへの習熟度合いも考慮に入れる必要があるのではないでしょうか。
Windowsの運用しかした事がない人にLinuxベースのサーバを任せても、ひとたびトラブったら手も足も出ないなんてことになりかねません。
その逆も然りで、Windowsだからサーバ運用が簡単ということもありません。

また、kuroriさん(の会社)が納品後も関わるのであれば、プロダクトの購入費用のほかにサポート契約の費用も見込んでおいた方がよいです。(Linux+MySQLであっても)
ユーザで手に負えない技術的トラブルのエスカレーションを受けたとき、迅速に、手厚く対応してもらうには費用を払ってサポートしてもらう他ないと思います。
構成の選定にはその費用も影響すると思いまし、安ければよいというものでもないはずです。

もちろんkuroriさん(の会社)が「このOS、このDBならどんなトラブルでも対応できる」というのであればその限りにあらずで、その場合は自信のあるプロダクトで構築して納入すればよい話です。
ユーザに納品してしまえばそれで終わり、あとは何も対応しないということであれば気にしなくてもいいのかも知れませんが。

質問文に技術的な要件があまりなかったのでその辺は要再確認だと思うのですが、運用する人のことも考慮に入れないとユーザもkuroriさん(の会社)も幸せになれないと思います。

あまり回答になっていなくて済みません。

Comments

[kurori]

ご意見ありがとうございます。
確かに質問への回答としては不適かもしれませんが、もっともなご意見だと思います。

良くある話(?)かもしれませんが、
相手側のシステム担当者が運用するそうです。

私共のプロバーの一括受注なのですが、保守契約の締結まではいっていないようで、
リリース後には瑕疵対応及び機能追加の際にのみ私どもの方で作業するようです。
（この辺りはプロジェクトマネージャーと営業に要確認という状態です）

経験的には中小へのシステム導入の場合、
システム担当者が請け負う => 細部を把握しきれない(正確には覚えようとしない) => 保守やってくれない？
といった流れで納品後、瑕疵対応期間内に保守契約の相談が来ることが多いように思います。
その辺りは大規模システムと違ってやりにくいみたいですね。

運用者は完全に素人さん(ExcelVBAができる程度)なので、
最悪、リカバー作業がユーザーでもできるようにLinuxではなくWindowsで予定としてる次第です。

そういった経緯もあって、製造サイドに一任されているようなのです。

ユーザーがデータチェックの際にはUIとしてSQL Server Management Sutudioのような
開発者向けのツールではなく、管理用のツールを製造・提供することも考えています。

まぁ、そういうわけで、広くご意見頂きたいな、
という質問の方向とさせて頂いた次第です。

[hsk]

横から失礼します。観点のひとつとしてですが
定期保守をユーザーさんにお願いするとなると、SQLServer であればWindowsUpdateでOSと無償かつ一貫してバグフィックスやセキュリティパッチを適用できますね（リリース後約10年間あるサポート期間内であればですが）慣れ親しんだ操作、または自動で。
ご存知かもしれませんが、OracleDBはセキュリティパッチも有償期間契約などをしないと入手できないです。SQL ServerのCALなどのライセンスもお値段張りますけれども...データ量を調べたら、案外ExpressEditionでも十分かもしれませんよ。あるいは、不明であればスケーラビリティも考慮するとして、BEACHSIDEさんの案にあるようなクラウド上のプラットフォームを使用する（必要であれば、監視・保守もそのままこちらで行えるようにできますし）のも一考かもしれません。

[kurori]

>hskさん
ご意見ありがとうございます。
>OracleDBはセキュリティパッチも有償期間契約などをしないと入手できないです。
把握しております。高いですからねぇ...

逆に、Microsoft製品であることの懸念として、
自動アップデートにより挙動が変わるようなケースが出ないか？
という面では常に不安視しています。
（それを言ってしまうとMicrosoft製品自体が選択肢から外れそうな意見になってしまいますが...）

個人的に苦い経験だったので記載しますと、
例えばWindows10へのアップデート誘導のポップアップは記憶にも真新しいかと思います。
広告システムではないですが、BtoCのシステムでCustomerに画面を見せる機能が有り、
このポップアップが邪魔で問題になったことが有りました。

Updateのタイミングなどはコントロールできるので不安は無いのですが、
その更新内容がシステムに影響が出ないのか？などを考えると、
お客様に自動アップデートを勧めるのがなかなか気が進まないところではあります。

ユーザー操作にしても、更新内容の精査がされるとも考えにくく悩ましくは有ります。

この辺りは契約面で線引きすべき、とも思いますけどもね。

[hsk]

Windows10のあれは、たしかに醜かったですね...

今回の件に絞ると、ServerOSにはMSでもさすがにかのような軽率なことをしないだろう（個人ではなく企業が使用している故、さすがに訴訟を起こされる...）ことを信じています...
WSUSなどを組み込んで、普段は「セキュリティ更新のみの適用」設定にできれば完全ではないにしても尚良でしょうか...

WindowsOSは、何かにつけ事例情報が多いこと、仮に何らかの大きな不具合が発生した場合、社会の多数の企業が同じ被害を受ける（ニュースにもなる）ため理解を比較的得られやすい（Linuxで不具合があった場合、なんでそんなのを選定したんだ！とも言われかねず）ことは利点に思います。

私個人でLinux Mintを推していた時期がありましたが、配布サイトが乗っ取られて、配布物にバックドアを仕掛けられた事件以来、企業ユースでの採用は諦めました。無償のものは、やはりそれなりなのだな、と。。

[kurori]

>hskさん
確かに問題が発生しても事例確認 => FotFixの適用の流れがスムーズにできるのが魅力の一つであるのは間違いないですね。
あとはWin8系OSで起きるディスクアクセスが100%になる問題が何とかなってくれればいいんですけどね。
この問題はWindows Server 2012 R2でも同様に起きるらしい(と言いますか、起きたことがある)ので、
それさえ何とかなってくれれば文句ないのですが。

失礼、いらない愚痴になりました（笑）

Datacenterエディションの様にWindowsUpdateのリリース物自体が厳選されていればいいのですけどね。
Linuxもそういう意味ではサードパーティライブラリを使用して開発するのと同じような危険は有りますし、
おっしゃる通りではありますね。

追記頂きありがとうございました。

[Panzer_vor]

運用サイドのお話で盛り上がっていそうなので。

運用面まで考慮に入れてくると、本当に親切なのはプロダクト提供者のサポート付なのは疑いようのない事実なんですよね。

ではそれがどうしても採用できない場合はどうすべきかという話なのですが、
それこそ契約のありよう、特に責任範囲を明確にしておくのが一番かなと思います。

例えば保守サポートも開発側が受け持つなら、
得意なDBを選べばいいわけで。その代わり何かあったら責任を持たなければなりませんがね。

逆に運用はユーザ側が持つというのであれば、
どこまでシステム提供者側が責任を担保するかを契約レベルで明確にしとかないとトラブります。

例えば質問者様のあげていた、運用者用のツール、機能を提供するのも１つの手段ですし、
運用者向けの手順書を準備しておくという手段も考えられます。

まぁそこはお互い嫌な思いはしないよう詰めるべき所ですね。

・・・まぁそれがうまくいかないことが多いから、こじれるケースも多いわけですが^^;

[kurori]

>Panzer_vorさん
>運用サイドのお話で盛り上がっていそうなので。
失礼(汗　つい脱線してしまいましたね。
技術情報の交換サイトですから、運用とか契約がらみの話は推奨じゃないでしょうしね。

>逆に運用はユーザ側が持つというのであれば、
>どこまでシステム提供者側が責任を担保するかを契約レベルで明確にしとかないとトラブります。
別の開発会社さんで、今まさにこれで揉めてるらしいです。
この辺の契約ごとを詰めるときに技術者も一人くらい連れてってればいんでしょうけどね。
（営業の独断専行らしいと耳にしました）

皆様、本題からの脱線、失礼しました。

Answer 3

技術的な面は、Panzer_vorさんの回答が参考になると思いますので、別の視点をからの話です。

結局のところ、
性能や運用のしやすさは（ある程度の小中規模であれば）開発者次第なので、
開発者が開発しやすいもの、かつ、運用しやすいものを選ぶのがベターだと考えてます。

（それなりに大規模なものを開発したり、パフォーマンストラブルシュートしたりの経験から個人的な意見です）

この質問のスコープ外な話になるかと思いますが、
個人的な意見だと、
「PaaSのデータベース使えばいいじゃん」と感じています。

クラウドの利用が、お客さんの都合で無理なら仕方ないのですが...食わず嫌いか知らないから無理とかなら、説明してあげればよいかと。

個人的な一例として、値段的にもお手頃なAzureのSQL Databaseを使います。ついでにサーバーはAzureのWeb Appsの組み合わせで。
オンプレでサーバー買ってインフラ構築・運用とか面倒だしハード面のトラブルシュートでオンサイト対応とかほど面倒なことはないので。
クラウド上でPaaSで揃えれば、インフラ面の心配は不要、構築も自動化できるし、アプリの開発・運用にのみ集中でき、デザスタリカバリーも簡単に構築できるのできます。バックアップストラテジーもポチポチするだけでできるので、メリットは山ほどあります。

クラウド推しを書いてしまいましたが、結局そこも技術者次第です。オンプレ同様、クラウドのアーキテクチャーのプラクティスを理解してないとおかしなことになりかねないので。

バタバタ書いてて、全然回答になっていないのですが、
結論として、
最低限のメリットデメリットと開発・運用での制約内に当てはまるかの検討はするとして、
使えない理由さえなければ、開発側が何を使って開発するっていう決意さえあればよいかと、と思っております。

（お客さんへの説明は、根性論ではなく論理的な説明がもちろん必要と思います）

Comments

[kurori]

ご意見ありがとうございます。
私自身、PaaSを用いたプロジェクト経験は無いのですが、GMO、AmazonEC2等のクラウドサービスは運用経験があるので利便性は認識しているつもりです。
で、クラウドでの導入もAzureを専門にしているスタッフから意見は有りましたが、
お客様には早い段階で拒否されています。

私見で申し訳ないのですが、中小企業のお客様の拒否理由は経験的には４つのどれかですね。（今回のお客様は２つが該当）
１．お客様先のシステム担当の方が詳しくはなく、クラウドを理解しようとして頂けない。
　　最終的にはその人が運用/保守を任されるが、上記の理由からクラウドでの導入を渋る。
２．顧客情報などをネットワーク上に置くのを嫌がる。
　　（別に社内においててもネットワークに繋がってるので設定次第なんですけどね...）
３．物理的なサーバで手元で管理したがる。
　　（これは障害時に予備への切替が簡単など、お客様の持つ導入後のシステムイメージ次第ですが）
４．サーバーが壊れるまで使う、壊れてからシステム入れ替えかリカバーを考えるという所もあり、
　　そこまでのランニングコストで比較されてしまう。
　　そういったお客様は大抵、データの退避だけは考えていらっしゃいますが、前提がおかしいのに気づいてないですね。

変に詳しいお客様はさくらVPSの事件も引き合いに出してきたりして、
大抵は理解しようとしてもらえない、という残念な結果になっているようです。(営業談)
実際にAzureの導入例もあるので全てのお客様が、というわけではないようですがね。

社内的にも下記のご意見はネックかもしれませんね。
>クラウドのアーキテクチャーのプラクティスを理解してないとおかしなことになりかねないので
実のところ、PaaSに関しての知識が深いメンバーも多くはなく、
そういった知識共有が出来ていないために専任のメンバーが抜けると痛手を被りかねません。

そういった訳で、今回は実機(タワーサーバ)の導入の方向で進めています。
貴重なご意見を頂き、ありがとうございます。

Answer 4

そんな難しく考えずに、MySQL以外の選択肢なんかありえない案件だと思います。

いろいろ細かいことを気にするなら専門の技術者を使うべきところ。
それを事務方が本職の人に片手間にやらせるようなクソ会社なら、DBはシンプルに一番普及していてトラブル時も解決しやすいMySQLを選ぶしかないでのは？

Comments

[kurori]

ご意見ありがとうございます。
>いろいろ細かいことを気にするなら専門の技術者を使うべきところ。
これは本当にその通りだとは思いますね。
とは言え、人が足りない時は背に腹は代えられないでしょうし。

低評価付いてますね。何だろう...

事務方とはいえ、システムを触っている人間の端くれですので、疑問点にお答え頂けると幸いです。

>DBはシンプルに一番普及していてトラブル時も解決しやすいMySQLを選ぶしかない
要件によって選定されるDBは異なると思いますが、
中小向けの業務システムではおっしゃるほどにMySQLが普及しているのでしょうか？
導入が簡単で普及しやすい要素は有りますが、トラブル解決も何かツールなりあるのでしょうか？

経験的にパッケージソフトであればSQL Server、在庫管理等の中～大企業であればOracleを比較的見かけるように思います。
(パッケージはInstallShield、古いものはセットアッププロジェクト等との親和性の問題もあるのでしょうね)
独自に構築したシステムであれば、MySQL、Access、DB2等も見覚えはありますが、
MySQLはそこまで飛びぬけてシェアがあるのでしょうか？

また、技術的なリファレンスの充実量、あるいはカンファレンスでの情報(出席できないので後日PDF等でチェックですが)、
そういったものから、他RDBと比べてそこまでシェアに差があるように感じたことは無いのです。

[zico_teratail]

そもそも「中小企業」の定義が曖昧でよく分かりませんが、零細も含めたらMySQLの普及度・使用度は圧倒的にズバ抜けている気がします。

証拠データはありませんが、それこそ統計の数字にはカウントされない「隠れユーザー」が多いでしょう、オープンソースは。私がこれまで開発・運営しているだけでもMySQLを使っているのは数百サイトありますが、これだってどこの統計にもカウントされていませんしね（カウントされようがない）。

リファレンスというか、ネット上の情報量とか、それこそここ（teratail）での人気ぶりとか見れば、明らかに他と差があると私は思います。

まあお金を払ってDBを使うことでメンタルが安定するなら、そうすればいいと思いますよ。

[kurori]

>「中小企業」の定義が曖昧でよく分かりませんが
中小企業基本法における定義ですね。事務屋だとこれが一般的ですかね？
業務内容で経産省の公文書準拠とかで定義が違うのかな...不勉強ですいません。
むしろ、零細企業という言い方のほうが久々でした。小規模事業者の事ですね。

>ネット上の情報量とか、それこそここ（teratail）での人気ぶりとか
確かに、こういった作業を振られる関係からコイミュニティサイトなども見ますが、
MySQLは他DBのコミュニティに比べ活発な印象がありますね。
主に日米独くらいしか読めないのでそれくらいしか見ませんが。
（OracleのOTNは移行後が残念なことになっていますし...）

>まあお金を払ってDBを使うことでメンタルが安定するなら、そうすればいいと思いますよ。
これについては同意しかねますかね。
予算を削ってあらゆるトラブルをリリース元のサポートなしで乗り切れるだけの技術者を集めるか、
その予算を回してサポートを受けるかの選択だと考えます。
実際、SQLServerではHotFixの適用が必要な問題がありサポートを受けたこともあります。

個人的にはオープンソースではそういった根本の問題への対応速度が遅い印象もあります。
そのあたりは無償、有志がやってくれているのだから仕方ないことではあるでしょう。
そういう面も含めれば、無償であること、有償であることの良し悪しも天秤に掛けるに足ると思います。

[zico_teratail]

なんかつまんないことばっかり気にしてますね。
日米独語が読めるスーパーエリート様なら他人に聞かずに自分で考えてサクッとやればいいんじゃない？

Answer 5

フリーウェアはもとより,書籍だけでなく,インターネットからでも情報入手しやすいDBを選ぶべきだと思います.

ゆえに,今回は,選ぶべきでないDBを提示します.
DB名：4DDAM
現在の名前は,AIDAMといいます.
数年前まで東証のシステムに使われていたDBです.
処理速度の速さに比べて,仕様が複雑で,開発者全員が仕様を把握できていないため,4DDAMを使っている箇所全てを試験する羽目になったほどです.
そのため,東証はその試験費用を出し渋ったため,入館許可の無いまま開発現場に共連れ入館して試験をすることになりました.

わざわざ,情報入手しやすいDBを選べるならば,有料DBを選ぶ必要は無いと思います.
例えば,OracleDBについて質問が発生したとき,直接Oracle社に質問したければ契約すべきかと・・・.

Comments

[kurori]

AIDAMのサイトとかを軽く見てきました。
なるほど、わからん、と思いました。

同時に、一時期はpentahoというツールを使ってDWHの解析をさせられたことがあり、
その時のDBによく似ているな、とは思いました。
(当時はSQLが書ける程度。その作業時は入館時にカードと静脈認証通ってました)

DBの名前はすいません、あんまり聞かない名だったので覚えてないのですが、
・本体がハッシュファイル構造
・非定型テーブル構造
というワードを見たときにデータストアとかビッグデータが思い浮かびました。
やはり大量データを高速に扱う場合、そういう特殊なものになってくるんですね。

勉強になりました。ありがとうございます。
技術に知ってるか聞いてみて、話のタネにしてます。