Thống nhất lập trình và truy vấn cơ sở dữ liệu [đã đóng]

Xem xét một hướng dẫn chung cho các ngôn ngữ lập trình hướng đối tượng như C ++ hoặc Java: tạo một hệ thống xử lý đơn hàng đơn giản với các đối tượng đại diện cho tài khoản, đơn hàng, vật phẩm, v.v. (hoặc một cái gì đó tương đương ít nhiều). Làm cho cảm giác trực quan hoàn hảo, nhưng con voi ở bàn ăn là nó không có thật vì đây là những vật thể trong bộ nhớ; trong một hệ thống thực, tài khoản, đơn đặt hàng, v.v. không thực sự sống trong bộ nhớ ở nơi đầu tiên, chúng sống trong cơ sở dữ liệu, với biểu diễn bộ nhớ chỉ là một tấm gương ngắn.

Bạn có thể tự viết rất nhiều mã để đọc và viết từ cơ sở dữ liệu, nhưng điều đó rất tẻ nhạt và dễ bị lỗi mà không ai thực sự làm điều đó.

Mọi người cuối cùng đều sử dụng ORM, nhưng những thứ đó rất có vấn đề theo cách riêng của họ đến nỗi một bài báo nổi tiếng gọi họ là 'Việt Nam của ngành công nghiệp của chúng ta'.

Tôi không nghĩ đó là sự không phù hợp giữa đối tượng và quan hệ nhiều đến mức không khớp giữa ngôn ngữ lập trình và cơ sở dữ liệu là những điều riêng biệt không biết về nhau . Phỏng đoán: giải pháp là có một ngôn ngữ duy nhất là ngôn ngữ truy vấn cơ sở dữ liệu và lập trình, do đó sẽ yêu cầu thời gian chạy ngôn ngữ cũng là cơ sở dữ liệu và trình biên dịch JIT cũng là trình tối ưu hóa truy vấn.

Vì vậy, đó là tóm tắt của các vấn đề tôi thấy nó. Câu hỏi của tôi là, có ai chưa,

1. Thực tế xây dựng một hệ thống thống nhất như vậy

2. Đã thử nhưng không xây dựng được một hệ thống thống nhất như vậy

3. Viết bất cứ điều gì đáng kể về chủ đề bạn sẽ xây dựng như thế nào, hoặc tại sao hoặc tại sao không

4. Hãy đến với một cách khác để giải quyết vấn đề?

Đây là ý kiến ​​của tôi. Trong khi tôi thấy bạn đến từ đâu, tôi không thể thấy điều đó xảy ra từ quan điểm thiết kế.

Kiên trì dữ liệu là chủ đề cực kỳ phức tạp. Và ngôn ngữ lập trình cũng vậy. Kết hợp cả hai sẽ dẫn đến vụ nổ phức tạp. Sẽ mất rất nhiều nỗ lực để thực sự làm cho cả hai đủ tốt để mọi người thực sự muốn sử dụng nó. Tôi nghĩ rằng đã đề cập MUMPS là ví dụ tốt. Hoặc bạn có thể xem xét các biến thể SQL khác nhau có ngôn ngữ đầy đủ được đặt ở trên đầu chúng. Chúng có thể sử dụng được, nhưng tôi không nghĩ mọi người sẽ sẵn lòng sử dụng chúng.

Vì vậy, tách chúng là cách rõ ràng để giải quyết sự phức tạp này. Ngoài ra, bằng cách không buộc chúng lại với nhau, nó cho phép cả hai được thay đổi và phát triển theo thời gian. Ví dụ, SQL đã cũ và không thay đổi nhiều kể từ khi nó được tạo. Nhưng các ngôn ngữ được sử dụng để chạy các ứng dụng đã thay đổi mạnh mẽ so với cùng kỳ. Và bây giờ, điều ngược lại đang xảy ra. Ngôn ngữ vẫn chủ yếu giống nhau trong khi cơ sở dữ liệu đang được thay đổi và phát triển.

Thời gian chạy triển khai là một vấn đề khác. Kết hợp cả hai có nghĩa là cả cơ sở dữ liệu và ứng dụng hoặc máy chủ web sẽ phải chạy trong cùng một quy trình. Điều này là vô cùng hạn chế, cả từ quan điểm bảo trì và từ khả năng chạy chúng trên các máy tính riêng biệt hoặc trong các mối quan hệ nhiều-một.

Chia hai phần thành các mô-đun riêng biệt với API rõ ràng giữa chúng là cách tốt nhất để giảm độ phức tạp và cho bạn sự linh hoạt trong những công nghệ bạn muốn sử dụng và cách thức triển khai các phần cuối cùng.

Có vẻ như bạn đang thực hiện một số giả định chính. Ví dụ: bạn cho rằng mọi người đang viết vào cơ sở dữ liệu quan hệ. Điều đó chỉ đơn giản là không phải vậy, có rất nhiều ví dụ về cơ sở dữ liệu của các hương vị khác (dbs đối tượng, dbs tài liệu, v.v.) sử dụng ngôn ngữ lập trình gốc để viết tất cả mã và quản lý sự bền bỉ.

Ví dụ, Db4O tương thích với cả Java và C #, ObjectDB trong Java, VelocityDB bằng nhiều ngôn ngữ. Tất cả các trình điều khiển của MongoDB cuối cùng đều yêu cầu bạn viết nội dung bằng ngôn ngữ lập trình gốc của bạn (phần thưởng nếu bạn đang sử dụng JavaScript, vì điều đó có nghĩa là trình bao cũng sử dụng cùng một cú pháp), v.v.

Có rất nhiều cuộc thảo luận ở nhiều nơi về việc động cơ DB nào tốt hơn trong bối cảnh nào, và tại sao, quá nhiều cho phạm vi của câu trả lời này, để bao gồm một câu hỏi đóng trên chính trang web này. Kết quả cuối cùng là chúng được tối ưu hóa cho những thứ khác nhau và cho đến gần đây SQL được coi là một loại 'mẫu số chung thấp nhất' cho các ứng dụng kinh doanh vì bạn nhận được rất nhiều miễn phí về ACID và hiệu suất (mặc dù cả hai đều thay đổi gần đây khi kiến ​​trúc và yêu cầu thay đổi).

Cũng đáng lưu ý rằng thực sự có rất nhiều cách tiếp cận "tất cả trong một" trước đây. Các ngôn ngữ máy tính lớn thường có logic kiên trì riêng được tích hợp và có những ngôn ngữ như Smalltalk không phân biệt giữa mã và dữ liệu. Một lần nữa, chúng thường tốt cho một số trường hợp sử dụng nhưng không phải tất cả.

1. Có (không phải tôi). Nó được gọi là MUMPS .

2. Theo câu hỏi trước đây của SE.SE , hoặc bài viết này , MUMPs không được thiết kế tốt. Nhưng thực sự đã được sử dụng trong ngành y tế (và tôi đoán vẫn còn các hệ thống hiện có sử dụng nó), vì vậy không phải là một thất bại hoàn toàn.

3. Bạn chắc chắn sẽ tìm thấy thông tin về nó bây giờ bạn biết những gì cần tìm kiếm. Bắt đầu với liên kết Wikipedia ở trên.

4. Tìm kiếm cơ sở dữ liệu hướng đối tượng, nhiều trong số đó là ngôn ngữ cụ thể. Họ đã cố gắng giải quyết sự không phù hợp liên quan đến đối tượng theo những cách đơn giản hơn ORM.

Thực sự có nhiều hệ thống hợp nhất cơ sở dữ liệu và ngôn ngữ lập trình thành một môi trường duy nhất.

Smalltalk có lẽ là gần nhất với những gì bạn mô tả. Đối tượng trong bộ nhớ được duy trì trong một "hình ảnh", vì vậy môi trường ngôn ngữ có thể được sử dụng cơ sở dữ liệu (đối tượng) ngoài hộp. Và hầu hết các ngôn ngữ hiện đại đều có một số loại cơ chế bền vững tích hợp, có nghĩa là các đối tượng trong môi trường ngôn ngữ có thể được duy trì và truy vấn bằng chính ngôn ngữ đó.

Điều này rất thuận tiện cho các ứng dụng người dùng đơn. Nhưng cách tiếp cận sẽ không mở rộng cho nhiều người dùng, vì họ sẽ cần chia sẻ cùng một không gian bộ nhớ, điều này rõ ràng đặt ra giới hạn về số lượng người dùng. Một giải pháp có thể mở rộng yêu cầu một máy chủ cơ sở dữ liệu riêng biệt quản lý đồng thời. Thậm chí sau đó, có nhiều cơ sở dữ liệu NoSql tích hợp với một môi trường ngôn ngữ cụ thể và cho phép bạn duy trì và truy vấn các đối tượng bằng chính ngôn ngữ đó.

Từ khía cạnh quan hệ của những thứ chúng ta có các ngôn ngữ như T-SQL, một ngôn ngữ lập trình chính thức, là siêu ngôn ngữ của SQL, do đó, truy vấn và DML có thể được xen kẽ với logic thủ tục phức tạp tùy ý. Ứng dụng kinh doanh phức tạp đã được xây dựng bằng T-SQL, vì vậy điều này chắc chắn là có thể thực hiện được, nhưng xu hướng hiện nay là logic kinh doanh theo thủ tục ra khỏi cơ sở dữ liệu.

Trong những trường hợp này, thực sự rất thanh lịch và thuận tiện khi có cơ sở dữ liệu được tích hợp với ngôn ngữ lập trình và tránh "sự không phù hợp trở kháng". Vậy tại sao mọi người vẫn sử dụng các cơ sở dữ liệu quan hệ tách biệt khỏi môi trường lập trình và cố gắng kết nối với một số ORM-kydge?

Nó chỉ ra rằng có một số lợi thế để có dữ liệu và truy vấn tách biệt với bất kỳ ngôn ngữ và môi trường lập trình cụ thể.

• Độc lập dữ liệu. Trong hầu hết các tổ chức dữ liệu thực sự được truy cập bởi nhiều ứng dụng. Cửa hàng có thể có cơ sở dữ liệu được sử dụng bởi giao diện web, bởi công cụ hỗ trợ khách hàng, công cụ báo cáo, v.v. Các dữ liệu thường tồn tại lâu dài, trong khi các ứng dụng đến và đi. Việc kết hợp dữ liệu với một môi trường lập trình cụ thể sẽ được khóa trong một môi trường lập trình cụ thể. Nhưng ngôn ngữ lập trình đến và đi, trong khi dữ liệu sống mãi mãi.
• Truy vấn ad hoc. Nó rất thuận tiện để có thể mở một dấu nhắc cơ sở dữ liệu và viết một truy vấn. Nếu truy vấn được kết hợp chặt chẽ với môi trường lập trình thì đây sẽ là một nhiệm vụ lập trình và chỉ có các nhà phát triển mới có thể làm điều đó.
• Tránh khóa trong. Vì SQL là một tiêu chuẩn, nhiều nhà cung cấp có thể cung cấp các hệ thống quản lý cơ sở dữ liệu có thể thay thế ít nhiều. Điều này tránh khóa nhà cung cấp và giúp so sánh sản phẩm dễ dàng hơn.
• Khớp nối lỏng lẻo. Có một giao diện được xác định rõ giữa lớp ứng dụng và cơ sở dữ liệu giúp có thể điều chỉnh và tối ưu hóa cơ sở dữ liệu độc lập với logic ứng dụng.
• Giao diện dùng chung. Do giao diện cơ sở dữ liệu độc lập với logic ứng dụng, các công cụ có sẵn có thể được sử dụng để định hình, sao chép, phân tích, v.v.

Đó là câu hỏi khá hay mà tôi đã xử lý trong đầu nhiều lần. Một ví dụ về giải pháp hiện có giải quyết vấn đề của bạn là cơ sở dữ liệu đồ thị ArangoDB trong đó bạn sử dụng JavaScript (chạy trên công cụ nội bộ) để viết các bộ điều khiển có thể tạo toàn bộ trang web. Dữ liệu được truyền đến / từ bộ lưu trữ bằng JSON để nó có thể truy cập được trong JavaScript và các truy vấn được thực hiện bằng ngôn ngữ truy vấn được nhúng. Vì vậy, trường hợp này là một ví dụ về việc mở rộng JavaScript để chạy trong cơ sở dữ liệu.

Trong thực tế, các bộ điều khiển như vậy không nên được công khai vì lý do bảo mật vì một lỗ hổng trong cấu hình cơ sở dữ liệu hoặc một lỗi sẽ dẫn đến việc lộ dữ liệu quý giá của bạn ra công chúng.

Theo ý kiến ​​cá nhân của tôi, đây là một cách tiếp cận tốt và xem xét liệu cơ sở dữ liệu có hỗ trợ một loại tính năng ánh xạ / thu nhỏ sẽ cập nhật các chỉ mục dữ liệu / văn bản tổng hợp và dữ liệu thường được truy vấn khác trong thời gian thực hay không, thêm một lớp bảo mật mỏng ở giữa (gọi là tải balancer) sẽ làm cho một ứng dụng chức năng chạy trong cơ sở dữ liệu phân tán.

1. Thực tế xây dựng một hệ thống thống nhất như vậy

Vâng, tôi đã làm điều đó trong Sciter .

Kịch bản của Sciter là một " JavaScript ++ " được tích hợp sẵn:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Trong trường hợp ndb.rootlà đối tượng bình thường trong điều kiện của JS. Tất cả các thuộc tính và đối tượng phụ của nó có thể truy cập được từ nó là bền vững - được lưu trữ và tìm nạp trong DB khi cần - trong suốt cho mã:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Dữ liệu được lưu trữ trong DB theo chu kỳ GC, khi không đủ bộ nhớ hoặc trong ndb.commit()cuộc gọi rõ ràng .

Storagelớp được đi kèm với Indexlớp - bộ sưu tập đối tượng được sắp xếp bền vững với các khóa duy nhất / không duy nhất.

Bộ tính năng tương tự như MongoDB hoặc các cơ sở dữ liệu NoQuery khác nhưng id không yêu cầu ORM riêng biệt - truy cập db được thực hiện bằng phương tiện tập lệnh thuần túy.

Tôi hoàn toàn cho nó và tôi không biết bắt đầu từ đâu. SQL có thể rất tuyệt vời và tôi tưởng tượng rằng sẽ rất tuyệt nếu có tất cả sức mạnh đó và đảm bảo giao dịch ngay trong ngôn ngữ lập trình đa mục đích của bạn (thay vì phải viết các truy vấn dưới dạng tập hợp chuỗi hoặc sử dụng, không cho phép, ORM).

Hệ thống duy nhất tiếp cận ý tưởng của bạn mà tôi biết được gọi là aquameta (dòng thẻ: "web dev stack được xây dựng trong PostgreQuery"; xem https://github.com/aquametalabs/aquameta , http://aquameta.org ). Có một số video giới thiệu không điên rồ hơn một chút so với ý tưởng (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), và khi tôi nói điên, ý tôi là họ đã triển khai trình soạn thảo của riêng họ và hệ thống kiểm soát phiên bản của riêng họ bên trong Postgres.

Tôi nghĩ rằng đây chính xác là lý do cho phát minh LINQ của Microsoft. Nó đã được sử dụng ở quy mô đầy đủ trong vài năm, vì vậy thật dễ dàng tìm thấy tài liệu về nó và những phản ánh từ kinh nghiệm trong thế giới thực, cả tích cực và tiêu cực. (Hầu hết các cửa hàng phát triển .net đều nắm lấy nó.)

Một điểm khởi đầu tốt trên linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/