it-swarm-vi.tech

Lược đồ cơ sở dữ liệu động

Kiến trúc được đề xuất để cung cấp lưu trữ cho lược đồ cơ sở dữ liệu logic động là gì?

Để làm rõ: Trường hợp một hệ thống được yêu cầu cung cấp lưu trữ cho một mô hình mà lược đồ của người dùng có thể được mở rộng hoặc thay đổi một lần khi sản xuất, một số công nghệ tốt, mô hình cơ sở dữ liệu hoặc công cụ lưu trữ sẽ cho phép điều này là gì?

Một vài khả năng để minh họa:

  • Tạo/thay đổi các đối tượng cơ sở dữ liệu thông qua DML được tạo động
  • Tạo các bảng có số lượng lớn các cột vật lý thưa thớt và chỉ sử dụng các bảng cần thiết cho lược đồ logic 'được phủ'
  • Tạo bảng 'dài, hẹp' lưu trữ các giá trị cột động dưới dạng các hàng cần được xoay vòng để tạo một hàng 'ngắn, rộng' chứa tất cả các giá trị cho một thực thể cụ thể
  • Sử dụng hệ thống loại BigTable/SimpleDB PropertyBag

Bất kỳ câu trả lời dựa trên kinh nghiệm thực tế sẽ được đánh giá rất cao

65
Fake Jim

Những gì bạn đang đề xuất không phải là mới. Rất nhiều người đã thử nó ... hầu hết đều nhận thấy rằng họ theo đuổi sự linh hoạt "vô hạn" và thay vào đó kết thúc với nhiều, ít hơn thế nhiều. Đó là "nhà trọ roach" của các thiết kế cơ sở dữ liệu - dữ liệu đi vào, nhưng hầu như không thể lấy nó ra. Hãy thử và khái niệm hóa việc viết mã cho BẤT K sort loại ràng buộc nào và bạn sẽ thấy ý tôi là gì.

Kết quả cuối cùng thường là một hệ thống khó khăn hơn trong việc gỡ lỗi, bảo trì và đầy đủ các vấn đề về tính nhất quán của dữ liệu. Đây không phải là luôn luôn trường hợp, nhưng thường xuyên hơn không, đó là cách nó kết thúc. Chủ yếu là vì (các) lập trình viên không thấy con tàu đắm này đến và không bảo vệ được mã chống lại nó. Ngoài ra, thường kết thúc trường hợp tính linh hoạt "vô hạn" thực sự không cần thiết; đó là một "mùi" rất tệ khi nhóm nhà phát triển nhận được thông báo "Trời ạ, tôi không biết họ sẽ đưa loại dữ liệu nào vào đây, vì vậy hãy đặt WHATEVER" ... và người dùng cuối vẫn ổn có các loại thuộc tính được xác định trước mà chúng có thể sử dụng (mã hóa số điện thoại chung # và để chúng tạo bất kỳ số nào trong số chúng - đây là một hệ thống được chuẩn hóa độc đáo và duy trì tính linh hoạt và toàn vẹn!)

Nếu bạn có một nhóm phát triển rất tốt và nhận thức sâu sắc về các vấn đề bạn sẽ phải khắc phục với thiết kế này, bạn có thể mã hóa thành công giếng Thiết kế, hệ thống không lỗi khủng khiếp. Hầu hết thời gian.

Tại sao bắt đầu với tỷ lệ cược xếp chồng lên nhau rất nhiều, mặc dù?

Đừng tin tôi? Google "Một bảng tra cứu thực sự" hoặc "thiết kế bảng đơn". Một số kết quả tốt: http://asktom.Oracle.com/pls/asktom/f?p=100:11 0 ::::P11_QUESTION_ID:10678084117056

http://thed Dailywtf.com/Comments/Tom_Kyte_on_The_Ultimate_Extensibility.aspx?pg=

http://www.dbazine.com/ofinterest/oi-articles/celko22

http://thed Dailywtf.com/Comments/The_Inner-Plevelop_Effect.aspx? p = 2

36
Matt Rogish

Một trường xml được gõ mạnh trong MSSQL đã làm việc cho chúng tôi.

20
Bloodhound

Giống như một số người khác đã nói, đừng làm điều này trừ khi bạn không có lựa chọn nào khác. Một trường hợp bắt buộc là nếu bạn đang bán một sản phẩm ngoài giá phải cho phép người dùng ghi dữ liệu tùy chỉnh. Sản phẩm của công ty tôi thuộc loại này.

Nếu bạn cần cho phép khách hàng của mình làm điều này, đây là một vài mẹo:
[.__.] - Tạo một mạnh mẽ công cụ quản trị để thực hiện các thay đổi lược đồ và không cho phép các thay đổi này được thực hiện theo bất kỳ cách nào khác.
[.__.] - Làm cho nó trở thành một tính năng quản trị; không cho phép người dùng bình thường truy cập nó.
[.__.] - Ghi nhật ký mọi chi tiết về mọi thay đổi lược đồ. Điều này sẽ giúp bạn gỡ lỗi các vấn đề và nó cũng sẽ cung cấp cho bạn dữ liệu CYA nếu khách hàng làm điều gì đó ngu ngốc.

Nếu bạn có thể thực hiện những điều đó thành công (đặc biệt là việc đầu tiên), thì bất kỳ kiến ​​trúc nào bạn đề cập sẽ hoạt động. Sở thích của tôi là thay đổi động các đối tượng cơ sở dữ liệu, vì điều đó cho phép bạn tận dụng các tính năng truy vấn của DBMS khi bạn truy cập dữ liệu được lưu trữ trong các trường tùy chỉnh. Ba tùy chọn khác yêu cầu bạn tải khối dữ liệu lớn và sau đó thực hiện hầu hết việc xử lý dữ liệu của bạn bằng mã.

16
Josh Yeager

Tôi có một yêu cầu tương tự và quyết định sử dụng lược đồ ít hơn MongoDB .

MongoDB (từ "humongous") là một cơ sở dữ liệu hướng tài liệu, có khả năng mở rộng, hiệu suất cao, không có lược đồ, được viết bằng ngôn ngữ lập trình C++. (Wikipedia)

Điểm nổi bật:

  • có chức năng truy vấn phong phú (có thể là gần nhất với SQL DB)
  • sẵn sàng sản xuất (5.0, sourceforge sử dụng nó)

Lowdarks (những thứ bạn cần hiểu, vì vậy bạn có thể sử dụng mongo một cách chính xác):

9
clyfe

Tôi đã làm nó trong một dự án thực tế:

Cơ sở dữ liệu bao gồm một bảng với một trường là một mảng 50. Nó có một chỉ mục 'Word' được đặt trên đó. Tất cả dữ liệu là không đánh máy, vì vậy 'Chỉ mục Word' hoạt động như mong đợi. Các trường số được biểu diễn dưới dạng các ký tự và việc sắp xếp thực tế đã được thực hiện ở phía máy khách. (Vẫn có thể có một số trường mảng cho từng loại dữ liệu nếu cần).

Lược đồ dữ liệu lôgic cho các bảng logic được giữ trong cùng một cơ sở dữ liệu với 'loại' hàng khác nhau (phần tử mảng đầu tiên). Nó cũng hỗ trợ phiên bản đơn giản theo kiểu sao chép trên ghi bằng cách sử dụng trường 'loại' tương tự.

Ưu điểm:

  1. Bạn có thể sắp xếp lại và thêm/xóa các cột của mình một cách linh hoạt, không cần kết xuất/tải lại cơ sở dữ liệu. Bất kỳ dữ liệu cột mới nào cũng có thể được đặt thành giá trị ban đầu (hầu như) trong thời gian 0.
  2. Phân mảnh là tối thiểu, vì tất cả các bản ghi và bảng có cùng kích thước, đôi khi nó mang lại hiệu suất tốt hơn.
  3. Tất cả các lược đồ bảng là ảo. Bất kỳ cấu trúc lược đồ logic nào đều có thể (thậm chí đệ quy hoặc hướng đối tượng).
  4. Nó tốt cho dữ liệu "viết một lần, chủ yếu là đọc, không xóa/đánh dấu như đã xóa" (hầu hết các ứng dụng Web thực sự đều như vậy).

Nhược điểm:

  1. Chỉ lập chỉ mục bằng từ đầy đủ, không viết tắt,
  2. Các truy vấn phức tạp là có thể, nhưng với sự suy giảm hiệu suất nhẹ.
  3. Phụ thuộc vào việc hệ thống cơ sở dữ liệu ưa thích của bạn có hỗ trợ các mảng và chỉ mục Word hay không (nó đã được thực hiện trong PROGRESS RDBMS).
  4. Mô hình quan hệ chỉ trong tâm trí lập trình viên (tức là chỉ trong thời gian chạy).

Và bây giờ tôi nghĩ bước tiếp theo có thể là - thực hiện một cơ sở dữ liệu như vậy ở cấp độ hệ thống tệp. Điều đó có thể tương đối dễ dàng.

7
Thevs

Toàn bộ quan điểm của việc có một DB quan hệ là giữ cho dữ liệu của bạn an toàn và nhất quán. Thời điểm bạn cho phép người dùng thay đổi lược đồ, sẽ có tính toàn vẹn dữ liệu của bạn ...

Nếu nhu cầu của bạn là lưu trữ dữ liệu không đồng nhất, ví dụ như kịch bản CMS, tôi khuyên bạn nên lưu trữ XML được xác thực bởi một XSD liên tiếp. Tất nhiên bạn mất hiệu suất và khả năng tìm kiếm dễ dàng, nhưng đó là một sự đánh đổi tốt IMHO.

Kể từ năm 2016, hãy quên XML! Sử dụng JSON để lưu trữ túi dữ liệu không liên quan, với một cột được gõ thích hợp làm phụ trợ. Thông thường bạn không cần truy vấn theo giá trị bên trong túi, sẽ chậm mặc dù nhiều cơ sở dữ liệu SQL hiện đại hiểu JSON nguyên bản.

6
Sklivvz

Tạo 2 cơ sở dữ liệu

  • DB1 chứa các bảng tĩnh và biểu thị trạng thái "thực" của dữ liệu.
  • DB2 miễn phí cho người dùng thực hiện theo ý muốn - họ (hoặc bạn) sẽ phải viết mã để điền vào các bảng có hình dạng kỳ lạ của họ từ DB1.
3
AJ.

Âm thanh với tôi giống như những gì bạn thực sự muốn là một loại "lược đồ meta", một lược đồ cơ sở dữ liệu có khả năng mô tả một lược đồ linh hoạt để lưu trữ dữ liệu thực tế. Các thay đổi lược đồ động rất nhạy cảm và không phải là thứ bạn muốn gây rối, đặc biệt là nếu người dùng được phép thực hiện thay đổi.

Bạn sẽ không tìm thấy một cơ sở dữ liệu phù hợp với nhiệm vụ này hơn bất kỳ cơ sở dữ liệu nào khác, vì vậy cách tốt nhất của bạn chỉ là chọn một cơ sở dữ liệu dựa trên các tiêu chí khác. Ví dụ, bạn đang sử dụng nền tảng nào để lưu trữ DB? Ứng dụng được viết bằng ngôn ngữ nào? Vân vân

Để làm rõ những gì tôi có nghĩa là "lược đồ meta":

CREATE TABLE data (
    id INTEGER NOT NULL AUTO_INCREMENT,
    key VARCHAR(255),
    data TEXT,

    PRIMARY KEY (id)
);

Đây là một ví dụ rất đơn giản, bạn có thể sẽ có một cái gì đó cụ thể hơn cho nhu cầu của bạn (và hy vọng sẽ dễ dàng hơn để làm việc với nó), nhưng nó phục vụ để minh họa quan điểm của tôi. Bạn nên xem xét lược đồ cơ sở dữ liệu là bất biến ở cấp ứng dụng; bất kỳ thay đổi cấu trúc nào cũng cần được phản ánh trong dữ liệu (nghĩa là sự khởi tạo của lược đồ đó).

3
Daniel Spiewak

Tôi biết rằng các mô hình chỉ ra trong câu hỏi được sử dụng trong các hệ thống sản xuất trên tất cả. Một cái khá lớn đang được sử dụng tại một trường đại học/cơ sở giảng dạy lớn mà tôi làm việc. Họ đặc biệt sử dụng cách tiếp cận bảng hẹp dài để ánh xạ dữ liệu được thu thập bởi nhiều hệ thống thu thập dữ liệu khác nhau.

Ngoài ra, Google gần đây đã phát hành giao thức chia sẻ dữ liệu nội bộ, bộ đệm giao thức, dưới dạng nguồn mở thông qua trang web mã của họ. Một hệ thống cơ sở dữ liệu được mô phỏng theo phương pháp này sẽ khá thú vị.

Kiểm tra lượt theo dõi:

Mô hình giá trị thuộc tính-thực thể

Bộ đệm giao thức Google

3
siculars

Cách tiếp cận EAV tôi tin là cách tiếp cận tốt nhất, nhưng đi kèm với chi phí lớn

2
kamal

Wikipedia có một cái nhìn tổng quan tuyệt vời về không gian vấn đề:

http://en.wikipedia.org/wiki/Entity%E2%80%93attribution%E2%80%93value_model

2
DenNukem

Tôi biết đó là một chủ đề cũ, nhưng tôi đoán rằng nó không bao giờ mất tính thực tế. Tôi đang phát triển một cái gì đó như thế ngay bây giờ. Đây là cách tiếp cận của tôi. Tôi sử dụng cài đặt máy chủ với MySQL, Apache, PHP và Zend Framework 2 làm khung ứng dụng, nhưng nó sẽ hoạt động tốt với mọi cài đặt khác.

Dưới đây là một hướng dẫn thực hiện đơn giản, bạn có thể tự phát triển nó hơn nữa từ điều này.

Bạn sẽ cần triển khai trình thông dịch ngôn ngữ truy vấn của riêng mình, vì SQL hiệu quả sẽ quá phức tạp.

Thí dụ:

select id, password from user where email_address = "[email protected]"

Bố cục cơ sở dữ liệu vật lý:

Bảng 'thông số kỹ thuật': (nên được lưu trong bộ nhớ truy cập dữ liệu của bạn)

  • id: int
  • cha mẹ
  • tên: varar (255)

Bảng 'mục':

  • id: int
  • cha mẹ
  • spec_id: int
  • dữ liệu: varar (20000)

Nội dung của bảng 'thông số kỹ thuật':

  • 1, 0, 'người dùng'
  • 2, 1, 'email_address'
  • 3, 1, 'mật khẩu'

Nội dung của bảng 'mục':

Bản dịch của ví dụ trong ngôn ngữ truy vấn của chúng ta:

select id, password from user where email_address = "[email protected]"

để SQL chuẩn sẽ trông như thế này:

select 
    parent_id, -- user id
    data -- password
from 
    items 
where 
    spec_id = 3 -- make sure this is a 'password' item
    and 
    parent_id in 
    ( -- get the 'user' item to which this 'password' item belongs
        select 
            id 
        from 
            items 
        where 
            spec_id = 1 -- make sure this is a 'user' item
            and 
            id in 
            ( -- fetch all item id's with the desired 'email_address' child item
                select 
                    parent_id -- id of the parent item of the 'email_address' item
                from 
                    items 
                where 
                    spec_id = 2 -- make sure this is a 'email_address' item
                    and
                    data = "[email protected]" -- with the desired data value
            )
    )

Bạn sẽ cần phải lưu bảng thông số kỹ thuật vào một mảng kết hợp hoặc hàm băm hoặc một cái gì đó tương tự để lấy spec_id's từ tên spec. Nếu không, bạn sẽ cần chèn thêm một số chi phí SQL để lấy spec_id từ các tên, như trong đoạn trích này:

Ví dụ xấu, không sử dụng cái này, tránh cái này, thay vào đó là bộ đệm thông số kỹ thuật!

select 
    parent_id, 
    data 
from 
    items 
where 
    spec_id = (select id from specs where name = "password") 
    and 
    parent_id in (
        select 
            id 
        from 
            items 
        where 
            spec_id = (select id from specs where name = "user") 
            and 
            id in (
                select 
                    parent_id 
                from 
                    items 
                where 
                    spec_id = (select id from specs where name = "email_address") 
                    and 
                    data = "[email protected]"
            )
    )

Tôi hy vọng bạn có được ý tưởng và có thể tự xác định liệu phương pháp đó có khả thi với bạn không.

Thưởng thức! :-)

2
Oliver Konig

Trước đây tôi đã chọn tùy chọn C - Tạo bảng 'dài, hẹp' lưu trữ các giá trị cột động dưới dạng các hàng cần được xoay vòng để tạo một hàng 'ngắn, rộng' chứa tất cả các giá trị cho một thực thể cụ thể.. Tuy nhiên, tôi đã sử dụng ORM và điều đó THỰC SỰ khiến mọi thứ trở nên đau đớn. Tôi không thể nghĩ về cách bạn làm điều đó, nói, LinqToSql. Tôi đoán tôi phải tạo một Hashtable để tham chiếu các trường.

@Skliwz: Tôi đoán anh ấy quan tâm hơn đến việc cho phép người dùng tạo các trường do người dùng xác định.

0
Danimal

Tại wiki c2.com, ý tưởng về "Quan hệ động" đã được khám phá. Bạn không cần DBA: các cột và bảng là Tạo-Viết-Viết, trừ khi bạn bắt đầu thêm các ràng buộc để làm cho nó hoạt động giống như một RDBMS truyền thống: khi dự án đáo hạn, bạn có thể tăng dần "khóa nó".

Về mặt khái niệm, bạn có thể nghĩ mỗi hàng là một câu lệnh XML. Ví dụ: một hồ sơ nhân viên có thể được trình bày dưới dạng:

<employee lastname="Li" firstname="Joe" salary="120000" id="318"/>

Điều này không không ngụ ý rằng nó phải được triển khai dưới dạng XML, nó chỉ là một khái niệm tiện dụng. Nếu bạn yêu cầu một cột không tồn tại, chẳng hạn như "SELECT madeUpColumn ...", thì nó được coi là trống hoặc null (trừ khi các ràng buộc được thêm vào cấm như vậy). Và có thể sử dụng SQL , mặc dù người ta phải cẩn thận về việc so sánh vì mô hình kiểu ngụ ý. Nhưng khác với xử lý kiểu, người dùng của hệ thống Quan hệ động sẽ cảm thấy như ở nhà vì họ có thể tận dụng hầu hết kiến ​​thức RDBMS hiện có của họ. Bây giờ, nếu ai đó sẽ xây dựng nó ...

0
FloverOwe

Tìm kiếm đàn hồi. Bạn nên xem xét nó đặc biệt nếu bạn đang xử lý các bộ dữ liệu mà bạn có thể phân vùng theo ngày, bạn có thể sử dụng JSON cho dữ liệu của mình và không cố định khi sử dụng SQL để truy xuất dữ liệu.

ES nhập lược đồ của bạn cho bất kỳ trường JSON mới nào bạn gửi, tự động, với các gợi ý hoặc theo cách thủ công mà bạn có thể xác định/thay đổi bằng một lệnh HTTP ("ánh xạ"). Mặc dù nó không hỗ trợ SQL, nhưng nó có một số khả năng tra cứu tuyệt vời và thậm chí tổng hợp.

0
Oren