Tôi đang phát triển một trình tạo biểu mẫu và tự hỏi liệu nó có phải là mojo xấu để lưu trữ JSON trong cơ sở dữ liệu SQL không?Lưu trữ JSON trong cơ sở dữ liệu msSQL?
Tôi muốn giữ lại cơ sở dữ liệu của tôi & bảng đơn giản, vì vậy tôi sẽ phải
`pKey, formTitle, formJSON`
trên một bảng, và sau đó lưu trữ
{["firstName":{"required":"true","type":"text"},"lastName":{"required":"true","type":"text"}}
trong formJSON.
Bất kỳ đầu vào nào được đánh giá cao.
Tôi sử dụng JSON rộng rãi trong CMS (lưu trữ khoảng 110 trang web) và tôi thấy tốc độ truy cập dữ liệu rất nhanh. Tôi đã rất ngạc nhiên khi không có sự suy giảm tốc độ. Mỗi đối tượng trong CMS (Trang, Bố trí, Danh sách, Chủ đề, v.v.) có cột NVARCHAR (MAX) được gọi là JSONConfiguration. Công cụ ORM của tôi biết tìm cột đó và tạo lại nó làm đối tượng nếu cần. Hoặc, tùy thuộc vào tình hình, tôi sẽ chỉ chuyển nó cho máy khách để jQuery hoặc Ext JS xử lý.
Vì khả năng đọc/bảo trì mã của tôi, bạn có thể nói nó được cải thiện vì bây giờ tôi có các lớp đại diện cho rất nhiều đối tượng JSON được lưu trữ trong DB.
Tôi đã sử dụng JSON.net cho tất cả serialization/deserialization. http://james.newtonking.com/default.aspx
Tôi cũng sử dụng một truy vấn đơn để trả về meta-JSON với dữ liệu thực tế. Như trong trường hợp Ext JS, tôi có các truy vấn trả về cả cấu trúc của đối tượng Ext JS cũng như dữ liệu mà đối tượng sẽ cần. Điều này cắt giảm một bài đăng trở lại/SQL vòng chuyến đi.
Tôi cũng ngạc nhiên về cách nhanh chóng mã được phân tích cú pháp danh sách các đối tượng JSON và ánh xạ chúng thành một đối tượng DataTable mà sau đó tôi giao cho một GridView.
Nhược điểm duy nhất tôi đã thấy khi sử dụng JSON là lập chỉ mục. Nếu bạn có thuộc tính của JSON bạn cần tìm kiếm, thì bạn phải lưu trữ nó dưới dạng một cột riêng biệt.
Có JSON DB ở ngoài có thể phục vụ nhu cầu của bạn tốt hơn: CouchDB, MongoDB và Cassandra.
Nó sẽ chậm hơn so với biểu mẫu được xác định trong mã, nhưng một truy vấn phụ không được gây hại cho bạn nhiều. (Chỉ cần không để 1 truy vấn thêm trở thành 10 truy vấn phụ!)
Chỉnh sửa: Nếu bạn đang chọn hàng theo formTitle thay vì pKey (Tôi sẽ, vì sau đó mã của bạn sẽ dễ đọc hơn), hãy đặt chỉ mục formTitle
Tôi sẽ không đề xuất nó.
Nếu bạn muốn thực hiện bất kỳ báo cáo hoặc truy vấn nào dựa trên những giá trị này trong tương lai, nó sẽ làm cho cuộc sống của bạn khó khăn hơn nhiều so với việc có thêm một vài bảng/cột.
Tại sao bạn không tạo bảng mới? Tôi nói nếu ứng dụng của bạn yêu cầu họ tiếp tục và thêm chúng vào ... Ngoài ra nếu ai đó phải trải qua mã của bạn/db thì có thể sẽ khó khăn hơn cho họ để tìm ra những gì bạn đã thực hiện (tùy thuộc vào loại tài liệu bạn có).
Một cách tuyệt vời để tạo cơ sở dữ liệu đối tượng từ máy chủ sql.Tôi làm điều này cho tất cả các đối tượng cấu hình và mọi thứ khác mà không cần bất kỳ truy vấn cụ thể nào. mở rộng đối tượng của bạn - dễ dàng, chỉ cần tạo một thuộc tính mới trong lớp của bạn và bắt đầu với giá trị mặc định. Bạn không cần tài sản nữa? Chỉ cần xóa nó trong lớp. Dễ dàng triển khai, nâng cấp dễ dàng. Không thích hợp cho tất cả các đối tượng, nhưng nếu bạn trích xuất bất kỳ lệnh nào bạn cần phải lập chỉ mục - hãy tiếp tục sử dụng nó. Cách sử dụng máy chủ sql rất hiện đại.
Tôi đã gặp nhiều lần, nơi tôi đang tìm kiếm giải pháp và tìm đường đến đây. Trong cuộc tìm kiếm giải pháp, đôi khi tôi tìm thấy một câu trả lời tốt hơn ở nơi khác và có thể với công nghệ mới hơn so với những gì đã được trả lời vào thời điểm đó. Nó không chỉ để trả lời câu hỏi của bạn, nhưng đối với tất cả những người chạy vào tình huống tương tự như bạn trong tương lai. Và giống như KOPEHb, tôi sẽ đủ lịch sự để cập nhật hoặc thậm chí cung cấp các giải pháp tốt hơn là đã được trả lời. – Levitikon
Bạn sẽ có thể sử dụng SisoDb cho việc này. http://sisodb.com
Có ai có ý kiến gì sau khi sử dụng SisoDB không? Có vẻ đầy hứa hẹn, nhưng loại thư viện này thực sự có thể bị đánh hoặc bỏ lỡ khi được sử dụng trong thực tế ... –
Xin chào, tôi thành kiến vì tôi đã xây dựng SisoDB nhưng chúng tôi đang sử dụng nó trong một sản phẩm thương mại đang được phát triển ngày nay. Nó được sử dụng để duy trì readmodels trong một môi trường CQRS. – Daniel
Chúng tôi đã sử dụng phiên bản XML đã sửa đổi cho mục đích chính xác mà bạn đã giải thích trong bảy hoặc tám năm và nó hoạt động rất tốt. Nhu cầu hình thức của khách hàng của chúng tôi rất đa dạng nên chúng tôi không bao giờ có thể theo kịp cách tiếp cận bảng/cột. Chúng tôi quá xa con đường XML để thay đổi rất dễ dàng nhưng tôi nghĩ rằng JSON sẽ hoạt động tốt và có thể evan tốt hơn.
Báo cáo không có vấn đề với một vài hàm phân tích cú pháp tốt và tôi sẽ thách thức bất kỳ ai tìm thấy sự khác biệt đáng kể về hiệu suất giữa báo cáo/phân tích của chúng tôi và giải pháp bảng/cột cho nhu cầu này.
Tôi nghĩ rằng đó không phải là ý tưởng tối ưu để lưu trữ dữ liệu đối tượng trong một chuỗi trong SQL. Bạn phải chuyển đổi bên ngoài SQL để phân tích cú pháp nó. Điều đó trình bày một vấn đề về hiệu suất và bạn mất đi đòn bẩy của việc sử dụng khả năng phân tích dữ liệu gốc SQL. Một cách tốt hơn là lưu trữ JSON dưới dạng một kiểu dữ liệu XML trong SQL. Bằng cách này, bạn sẽ giết hai con chim bằng một viên đá: Bạn không phải tạo ra các tải trọng của các bảng và vẫn nhận được tất cả các lợi ích truy vấn gốc của SQL.
Chúng tôi dành nhiều thời gian trên các hình thức tùy chỉnh, mà thường có chứa các thông tin tương tự, hầu hết các thông tin đó được lưu trữ trong chỉ 3-4 bảng khác nhau. SO nếu tôi có thể tạo các biểu mẫu theo lập trình và gửi chúng vào các bảng thích hợp, nó sẽ tiết kiệm rất nhiều thời gian phát triển trong tương lai. – JKirchartz
Tôi nghĩ trong tình huống đó có lẽ sẽ ổn thôi. Giống như Michael nói nó sẽ chỉ là một truy vấn phụ. Tôi nghĩ bạn đang cố gắng lưu trữ các giá trị cùng với cấu trúc của biểu mẫu. –