Сохранение настроек учетной записи в одной строке со сложными данными

Question

Мне нужно сохранить настройки учетной записи для каждого профиля учетной записи. Я решил использовать SQL DB для этого, но не уверен, должен ли я идти со сложными данными (json/xml).

Я нашел ответы

Using a Single Row configuration table in SQL Server database. Bad idea?

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 (макс) SettingsValue NVARCHAR (макс)

, которые могут хранить данные, такие, как

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

......

Я предполагаю, что оба решения действительны и зависят от потребностей приложений, но ДЕЙСТВИТЕЛЬНО хотели бы знать, есть ли проблема, которую я не вижу при использовании сложных данных с однострочным подходом для хранения настроек приложения?

Answer 1

Одна из проблем заключается в том, что если у вас многозадачная большая база данных, вы не можете повторно индексировать ONLINE (если у вас есть версия Enterprise) на поля XML, text, varchar (max). Это вызывает горе в 2008 R2. Новые версии MS SQL Server могут переиндексировать онлайн-поля varchar (max), поэтому зависит от того, какая версия вы используете.

Кроме того, вы не сможете запрашивать или индексировать, если вам нужно искать определенные записи, если вы не используете тип таблицы SettingsName, SettingsValue, который я использовал много. Это решает проблему повторного индекса онлайн (если это относится к вашей ситуации), а также индексирование полей для быстрых запросов.