Làm thế nào bạn sẽ thiết kế một cơ sở dữ liệu người dùng với các trường tùy chỉnh

Câu hỏi này xoay quanh việc tôi nên thiết kế cơ sở dữ liệu như thế nào, nó có thể là cơ sở dữ liệu quan hệ / nosql, tùy thuộc vào điều gì sẽ là giải pháp tốt hơn

Đưa ra một yêu cầu trong đó bạn sẽ cần tạo một hệ thống sẽ liên quan đến cơ sở dữ liệu để theo dõi "Công ty" và "Người dùng". Một người dùng luôn chỉ thuộc về một công ty

• Một người dùng chỉ có thể thuộc về một công ty
• Một công ty có thể có nhiều người dùng

Thiết kế cho bảng "Công ty" khá đơn giản. Công ty sẽ có các thuộc tính / cột sau: (hãy giữ cho nó đơn giản)

ID, COMPANY_NAME, CREATED_ON

Kịch bản đầu tiên

Đơn giản và dễ hiểu, tất cả người dùng đều có cùng thuộc tính, vì vậy điều này có thể dễ dàng thực hiện theo kiểu quan hệ, bảng người dùng:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

Kịch bản thứ hai

Điều gì xảy ra nếu các công ty khác nhau muốn lưu trữ thuộc tính hồ sơ khác nhau cho người dùng của họ. Mỗi công ty sẽ có một bộ thuộc tính được xác định sẽ áp dụng cho tất cả người dùng của công ty đó.

Ví dụ:

• Công ty A muốn lưu trữ: THÍCH_MOVIE (boolean), THÍCH_MUSIC (boolean)
• Công ty B muốn lưu trữ: FAV_CUISINE (Chuỗi)
• Công ty C muốn lưu trữ: OWN_DOG (boolean), DOG_COUNT (int)

Cách tiếp cận 1

cách thức mạnh mẽ là có một lược đồ duy nhất cho người dùng và để họ có null khi họ không thuộc về công ty:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON

Điều này thật khó chịu vì bạn sẽ có rất nhiều NULLS và hàng người dùng có các cột không liên quan đến họ (ví dụ: tất cả người dùng thuộc Công ty A có các giá trị NULL cho FAV_CUISINE, OWN_DOG, DOG_COUNT)

Cách tiếp cận 2

cách tiếp cận thứ hai, là có "trường biểu mẫu miễn phí":

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON

Điều này sẽ gây khó chịu cho chính bạn vì bạn không biết trường tùy chỉnh là gì, kiểu dữ liệu sẽ không phản ánh các giá trị được lưu trữ (ví dụ: chúng tôi sẽ lưu trữ giá trị int dưới dạng VARCHAR).

Cách tiếp cận 3

Tôi đã xem xét trường JSON của PostgreSQL, trong trường hợp đó bạn sẽ có:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_PROFILE_JSON, CREATED_ON

Trong trường hợp này, làm thế nào bạn có thể áp dụng các lược đồ khác nhau cho người dùng? Người dùng với Công ty A sẽ có lược đồ giống như

 {"LIKE_MOVIE":"boolean", "LIKE_MUSIC": "boolean"}

Trong khi người dùng với Công ty C sẽ có một lược đồ khác:

 {"OWN_DOG ":"boolean", "DOG_COUNT": "int"}

Tôi nên giải quyết vấn đề này như thế nào? Làm cách nào tôi có thể thiết kế cơ sở dữ liệu đúng cách để cho phép lược đồ linh hoạt này cho một "đối tượng" (Người dùng) duy nhất dựa trên mối quan hệ họ có (Công ty)?

Giải pháp quan hệ? Giải pháp nosql?

Chỉnh sửa: Tôi cũng đã nghĩ về bảng "CUSTOM_PROFILE" về cơ bản sẽ lưu trữ các thuộc tính người dùng theo hàng thay vì cột.

Có 2 vấn đề với cách tiếp cận này:

1) Dữ liệu tăng theo mỗi người dùng tăng theo hàng thay vì cột - và điều này có nghĩa là để có được một bức tranh đầy đủ về người dùng, rất nhiều phép nối cần được thực hiện, nhiều lần tham gia vào bảng "hồ sơ tùy chỉnh" trên các thuộc tính tùy chỉnh khác nhau

2) Giá trị dữ liệu luôn được lưu trữ dưới dạng VARCHAR là chung, ngay cả khi chúng ta biết dữ liệu được coi là số nguyên hoặc boolean, v.v.

Hãy coi đây là một sự thay thế. Hai ví dụ trước sẽ yêu cầu bạn thay đổi lược đồ khi phạm vi của ứng dụng tăng lên, ngoài ra giải pháp "custom_column" rất khó để mở rộng và duy trì. Cuối cùng, bạn sẽ kết thúc với Custom_510 và sau đó chỉ cần tưởng tượng bảng này sẽ hoạt động khủng khiếp như thế nào.

Trước tiên hãy sử dụng lược đồ công ty của bạn.

[Companies] ComnpanyId, COMPANY_NAME, CREATED_ON

Tiếp theo, chúng tôi cũng sẽ sử dụng lược đồ Người dùng của bạn cho các thuộc tính bắt buộc cấp cao nhất sẽ được sử dụng / chia sẻ bởi tất cả các công ty.

[Users] UserId, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

Tiếp theo, chúng tôi xây dựng một bảng trong đó chúng tôi sẽ xác định các thuộc tính động của chúng tôi dành riêng cho từng thuộc tính người dùng tùy chỉnh của công ty. Vì vậy, ở đây một giá trị mẫu của cột Thuộc tính sẽ là "LikeMusic":

[UserAttributeDefinition] UserAttributeDefinitionId, CompanyId, Attribute

Tiếp theo, chúng tôi xác định bảng UserAttribution sẽ giữ các giá trị thuộc tính người dùng

[UserAttributes] UserAttributeDefinitionId, UserId, Value

Điều này có thể được sửa đổi theo nhiều cách để tốt hơn cho hiệu suất. Bạn có thể sử dụng nhiều bảng cho UserAttribution làm cho mỗi bảng cụ thể cho loại dữ liệu được lưu trữ trong Giá trị hoặc chỉ để nó dưới dạng VarChar và làm việc với nó như một kho lưu trữ khóa.

Bạn cũng có thể muốn chuyển CompanyId khỏi bảng UserAttributionDefiniton và vào một bảng tham chiếu chéo để chứng minh trong tương lai.

Sử dụng cơ sở dữ liệu NoQuery. Sẽ có tài liệu của công ty và người dùng. Người dùng sẽ có một phần của lược đồ của họ được tạo động dựa trên mẫu người dùng (văn bản để chỉ ra các trường / loại cho công ty đó.

\Company\<uniqueidentifier>
    - Name: <Name>
    - CreatedOn: <datetime>
    - UserTemplate: <Text>

\User\<uniqueidentifier>
    - COMPANY_ID: <ID>
    - FIRST_NAME: <Text>
    - LAST_NAME: <Text>
    - EMAIL: <Text>
    - CREATED_ON: <datetime>
    - * Dynamically created fields per company

Đây là cách nó có thể trông giống như trong Firebase.com Bạn sẽ phải học cách làm điều đó trong bất cứ điều gì bạn chọn.

Nếu bạn thường xuyên chạy vào các yêu cầu trường tùy chỉnh, tôi thực sự sẽ mô hình hóa nó khá giống với cơ sở dữ liệu. Tạo một bảng chứa siêu dữ liệu về từng trường tùy chỉnh, CompanyCustomField (thuộc về loại dữ liệu, v.v.) và một bảng khác CompanyCustomFieldValues ​​có chứa CustomerId, FieldId và giá trị. Nếu bạn đang sử dụng một cái gì đó như Microsoft Sql Server, tôi sẽ có cột giá trị là kiểu dữ liệu sql_variant.

Tất nhiên điều này không dễ dàng vì bạn sẽ cần một giao diện cho phép quản trị viên xác định các trường tùy chỉnh cho từng khách hàng và một giao diện khác thực sự sử dụng siêu dữ liệu này để xây dựng giao diện người dùng để thu thập các giá trị trường. Và nếu bạn có các yêu cầu khác, chẳng hạn như nhóm các trường lại với nhau hoặc cần thực hiện một loại danh sách chọn, bạn sẽ cần phải bổ sung thêm với siêu dữ liệu / các bảng khác (ví dụ: CompanyCustomFieldPickListOptions).

Điều này không tầm thường, nhưng nó có ưu điểm là không yêu cầu thay đổi cơ sở dữ liệu / thay đổi mã cho mỗi trường tùy chỉnh mới. Bất kỳ tính năng nào khác của trường tùy chỉnh cũng sẽ cần được mã hóa (ví dụ: nếu bạn muốn xác thực lại giá trị chuỗi hoặc chỉ cho phép ngày giữa các phạm vi nhất định hoặc nếu bạn cần bật một trường tùy chỉnh dựa trên giá trị trường tùy chỉnh khác ).

Một thay thế cho các câu trả lời khác là có một bảng gọi là profile_attrib hoặc tương tự rằng lược đồ được quản lý hoàn toàn bởi ứng dụng của bạn.

Khi các thuộc tính tùy chỉnh được thêm vào, bạn ALTER TABLE profile_attrib ADD COLUMN like_movie TINYINT(1), bạn có thể cấm xóa chúng. Điều này sẽ giảm thiểu sự tham gia của bạn, trong khi vẫn cung cấp sự linh hoạt.

Tôi đoán rằng sự đánh đổi bit là ứng dụng hiện cần các đặc quyền bảng thay đổi cho cơ sở dữ liệu và bạn phải khéo léo trong việc vệ sinh các tên cột.

Câu hỏi của bạn có nhiều giải pháp tiềm năng. Một giải pháp là lưu trữ các thông tin bổ sung dưới dạng XML. XML có thể được lưu trữ dưới dạng văn bản hoặc nếu bạn sử dụng cơ sở dữ liệu hỗ trợ các loại XML dưới dạng XML (SQL Server). Lưu trữ dưới dạng văn bản giới hạn khả năng truy vấn của bạn (như tìm kiếm trên một thuộc tính tùy chỉnh), nhưng nếu lưu trữ và truy xuất là tất cả nhu cầu của bạn thì đó là một giải pháp tốt. Nếu một người cần truy vấn, thì việc lưu trữ XML dưới dạng một loại XML sẽ là một lựa chọn tốt hơn (mặc dù điều này là cụ thể hơn của nhà cung cấp).

Điều này sẽ cung cấp cho một khả năng lưu trữ bất kỳ số lượng thuộc tính nào cho khách hàng chỉ bằng cách thêm một cột bổ sung trên bảng khách hàng. Người ta có thể lưu trữ các thuộc tính dưới dạng băm hoặc từ điển, người ta sẽ mất an toàn kiểu vì mọi thứ sẽ là một chuỗi bắt đầu, nhưng nếu một thực thi chuỗi định dạng chuẩn cho ngày, số, thì booleans sẽ hoạt động tốt.

Để biết thêm thông tin:

https://msdn.microsoft.com/en-us/l Library / hh403385.aspx

Câu trả lời của @ WalterMitty cũng hợp lệ, mặc dù nếu một người có nhiều khách hàng với các thuộc tính khác nhau, người ta có thể kết thúc với nhiều bảng nếu theo mô hình thừa kế. Nó phụ thuộc vào số lượng thuộc tính tùy chỉnh được chia sẻ giữa các khách hàng.

Bạn nên bình thường hóa cơ sở dữ liệu của mình sao cho bạn có 3 bảng khác nhau cho mỗi loại hồ sơ công ty khác nhau. Sử dụng ví dụ của bạn, bạn sẽ có các bảng với các cột:

USER_ID, LIKE_MOVIE, LIKE_MUSIC

USER_ID, FAVORITE_CUISINE

USER_ID, OWN_DOG, DOG_COUNT

Cách tiếp cận này giả định rằng bạn sẽ biết hình dạng thông tin mà một công ty muốn lưu trữ trước khi ra tay và nó sẽ không thay đổi thường xuyên. Nếu hình dạng của dữ liệu không xác định tại thời điểm thiết kế, có lẽ sẽ tốt hơn nếu đi với trường JSON hoặc cơ sở dữ liệu nosql.

Vì lý do này hay lý do khác, cơ sở dữ liệu là một lĩnh vực trong đó hiệu ứng nền tảng bên trong xuất hiện thường xuyên nhất. Đây chỉ là một trường hợp khác của mô hình chống bật lên.

Trong trường hợp này, bạn đang cố gắng chống lại giải pháp tự nhiên và chính xác. Người dùng của Công ty A không phải là người dùng của Công ty B và họ nên có các bảng riêng cho các lĩnh vực của riêng họ.

Nhà cung cấp cơ sở dữ liệu của bạn không tính phí cho bạn bởi bảng và bạn không cần gấp đôi dung lượng đĩa cho hai lần bảng (thực tế, có hai bảng hiệu quả hơn vì bạn không lưu trữ các thuộc tính của A cho người dùng B. Thậm chí chỉ lưu trữ NULL chiếm không gian).

Tất nhiên, nếu có đủ các trường chung, bạn có thể đưa các trường đó vào bảng Người dùng chung và có khóa ngoại trong mỗi bảng người dùng dành riêng cho công ty. Đây là một cấu trúc đơn giản đến mức không có trình tối ưu hóa truy vấn cơ sở dữ liệu nào phải vật lộn với nó. Bất kỳ THAM GIA cần thiết là tầm thường.

Giải pháp của tôi cho rằng bạn sẽ gọi truy vấn này từ một chương trình và bạn sẽ có thể thực hiện xử lý bài. Bạn có thể có các cột sau:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_VALUES

CUSTOM_VALUES sẽ là cặp khóa lưu trữ và chuỗi giá trị. khóa sẽ là tên cột và giá trị sẽ là giá trị cột, vd

LIKE_MOVIE;yes;LIKE_MUSIC;no;FAV_CUISINE;rice

trong TÙY CHỈNH này, bạn sẽ chỉ lưu những thông tin tồn tại. Khi bạn truy vấn từ chương trình, bạn có thể tách chuỗi này và sử dụng nó.

Tôi đã sử dụng logic này và nó hoạt động tốt, chỉ là bạn sẽ phải áp dụng logic lọc trong mã chứ không phải trong truy vấn.