0

アカウント プロファイルごとにアカウント設定を保存する必要があります。これには SQL DB を使用することにしましたが、複雑なデータ (json/xml) を使用する必要があるかどうかはわかりません。

答えが見つかりました

SQL Server データベースで単一行構成テーブルを使用します。悪いアイデア？

https://softwareengineering.stackexchange.com/questions/163606/configuration-data-single-row-table-vs-name-value-pair-table

しかし、複雑なデータを含む単一行アプローチの使用については誰も議論していません

複雑なデータは、次の DB テーブル内に格納されます

AccountID int
AccountSettings nvarchar(max)

次のような AccountSettings データが含まれます。

"settings": {
  "branding": {
    "header_color": "1A00C3",
    "page_background_color": "333333",
    "tab_background_color": "3915A2",
    "text_color": "FFFFFF",
    "header_logo_url": "/path/to/header_logo.png",
    "favicon_url": "/path/to/favicon.png",
  },
  "apps": {
    "use":            true,
    "create_private": false,
    "create_public":  true
  },
  "tickets": {
    "comments_public_by_default":     true,
    "list_newest_comments_first":     true,
    "collaboration":                  true,
    "private_attachments":            true,
    "agent_collision":                true
    "list_empty_views":               true,
    "maximum_personal_views_to_list": 12,
    "tagging":                        true,
    "markdown_ticket_comments":       false
  },
  "chat": {
    "maximum_request_count": 5,
    "welcome_message":       "Hello, how may I help you?",
    "enabled":               true
  },
  "voice": {
    "enabled":     true,
    "maintenance": false,
    "logging":     true
  },
  "twitter": {
    "shorten_url": "optional"
  },
  "users": {
    "tagging": true,
    "time_zone_selection": true,
    "language_selection": true
  },
  "billing": {
    "backend": 'internal'
  },
  "brands": {
    "default_brand_id": 47
  },
  "active_features": {
    "on_hold_status":                true,
    "user_tagging":                  true,
    "ticket_tagging":                true,
    "topic_suggestion":              true,
    "voice":                         true,
    "business_hours":                true,
    "facebook_login":                true,
    "google_login":                  true,
    "twitter_login":                 true,
    "forum_analytics":               true,
    "agent_forwarding":              true,
    "chat":                          true,
    "chat_about_my_ticket":          true,
    "customer_satisfaction":         true,
    "csat_reason_code":              true,
    "screencasts":                   true,
    "markdown":                      true,
    "language_detection":            true,
    "bcc_archiving":                 true,
    "allow_ccs":                     true,
    "advanced_analytics":            true,
    "sandbox":                       true,
    "suspended_ticket_notification": true,
    "twitter":                       true,
    "facebook":                      true,
    "feedback_tabs":                 true,
    "dynamic_contents":              true,
    "light_agents":                  true
  },
  "ticket_sharing_partners": [
    "foo@example.com"
  ]
}

他の解決策は、AccountID int SettingsName nvarchar(max) SettingsValue nvarchar(max) などの広く使用されている単一行のアプローチです。

次のようなデータを保持できます

AccountID     SettingsName                   SettingsValue
1             Branding.Header_Color          1A00C3
1             Branding.Page_Background_Color 333333
1             Apps.Use                       true

……

どちらのソリューションも有効であり、アプリケーションのニーズに応じて異なると思いますが、アプリケーション設定を保存するために単一行アプローチで複雑なデータを使用する場合に見られない問題があることを本当に知りたいですか?

4

1 に答える 1

0

懸念事項の 1 つは、ビジーな大規模データベースを使用している場合、XML、テキスト、varchar(max) タイプのフィールドで (Enterprise バージョンを使用している場合) オンラインで再インデックスを実行できないことです。これは 2008 R2 の悲しみを引き起こします。MS SQL Server の新しいバージョンでは、オンラインの varchar(max) フィールドのインデックスを再作成できるため、実行しているバージョンによって異なります。

また、特定のレコードを検索する必要がある場合は、私がよく使用する SettingsName、SettingsValue 型のテーブルを使用しない限り、クエリやインデックスを作成することはできません。これにより、オンラインでのインデックスの再作成の問題 (状況に当てはまる場合) が解決され、クイック クエリ用にフィールドのインデックスが作成されます。

于 2016-02-27T21:11:52.360 に答える