回答編集履歴
3
修正
answer
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
顧客ごとにワンセットの別DBにするというのは、セキュリティの観点などから選択肢としてあるかと思いますが、言われている理由では、個別のデータベースにしなくとも、識別する項目をレイアウトに持たせれば目的は果たせます。
|
|
6
6
|
|
|
7
|
-
アクセスするアプリケーション
|
|
7
|
+
アクセスするアプリケーション側から考えると、分離されていない方が処理しやすいですし、ハード面で分離する理由がある場合でも、ミドルウェア側で統合されるような構成にするのが一般的だと思います。
|
|
8
8
|
|
|
9
9
|
---
|
|
10
10
|
MySQLでのデータベースというのは、他のDBMSで言うところのスキーマの概念が統合されたものです。
|
2
修正
answer
CHANGED
|
@@ -8,4 +8,4 @@
|
|
|
8
8
|
|
|
9
9
|
---
|
|
10
10
|
MySQLでのデータベースというのは、他のDBMSで言うところのスキーマの概念が統合されたものです。
|
|
11
|
-
ですので、機能的な括りとしてデータベース（スキーマ）を分けるという事はあるので、仰っているのがサイトごとに機能が異なる（テーブル構成やレイアウトが違うし、当然プログラムも違う）というのならありかと思います。
|
|
11
|
+
ですので、機能的な括りとしてデータベース（スキーマ）を分けるという事はあるので、仰っているのがサイトごとに機能が異なる（テーブル構成やレイアウトが違うし、当然プログラムも違う）というのならありかと思いますが、当然保守コストは上がるので、結局共通的な構成を考えた方が無難でしょう。
|
1
追記
answer
CHANGED
|
@@ -4,4 +4,8 @@
|
|
|
4
4
|
|
|
5
5
|
顧客ごとにワンセットの別DBにするというのは、セキュリティの観点などから選択肢としてあるかと思いますが、言われている理由では、個別のデータベースにしなくとも、識別する項目をレイアウトに持たせれば目的は果たせます。
|
|
6
6
|
|
|
7
|
-
アクセスするアプリケーションで側から考えると、分離されていない方が処理しやすいですし、ハード面で分離する理由がある場合でも、ミドルウェア側で統合されるような構成にするのが一般的だと思います。
|
|
7
|
+
アクセスするアプリケーションで側から考えると、分離されていない方が処理しやすいですし、ハード面で分離する理由がある場合でも、ミドルウェア側で統合されるような構成にするのが一般的だと思います。
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
MySQLでのデータベースというのは、他のDBMSで言うところのスキーマの概念が統合されたものです。
|
|
11
|
+
ですので、機能的な括りとしてデータベース（スキーマ）を分けるという事はあるので、仰っているのがサイトごとに機能が異なる（テーブル構成やレイアウトが違うし、当然プログラムも違う）というのならありかと思います。
|