Lập trình khai báo so với lập trình mệnh lệnh


24

Tôi cảm thấy rất thoải mái với lập trình mệnh lệnh. Tôi không bao giờ gặp khó khăn khi diễn đạt bằng thuật toán những gì tôi muốn máy tính làm một khi tôi đã tìm ra những gì tôi muốn nó làm. Nhưng khi nói đến các ngôn ngữ như SQL hoặc tôi thường gặp khó khăn vì đầu tôi đã quá quen với lập trình mệnh lệnh.

Ví dụ: giả sử bạn có ban nhạc quan hệ (bandName, bandCountry), địa điểm (địa chỉ tên, địa điểmCountry), lượt chơi (bandName, địa chỉ đất nước đó chơi ở địa điểm của tên đó.

Ví dụ: Tôi muốn tất cả các địa điểm Tên trong đó các ban nhạc từ tất cả các quốc gia (bandCountry) đã chơi. Ngoài ra, theo "quan hệ", ý tôi là một bảng SQL.

Trong tâm trí tôi lập tức đi "cho từng địa điểm. Lặp đi lặp lại trên tất cả các bandCountries và cho mỗi bandCountry có được danh sách các ban nhạc đến từ đó. Nếu không ai trong số họ chơi ở địa chỉName, hãy đến địa điểm tiếp theo Lặp lại thêm địa chỉName vào tập hợp các địa điểm tốt ".

... nhưng bạn không thể nói như thế trong SQL và tôi thực sự cần phải suy nghĩ về cách xây dựng điều này, với giải pháp mệnh lệnh trực quan liên tục cằn nhằn sau gáy tôi. Có ai khác có vấn đề này? Làm thế nào bạn vượt qua điều này? Bạn đã tìm ra một sự thay đổi mô hình? Tạo một bản đồ từ các khái niệm Bắt buộc sang các khái niệm SQL để dịch các giải pháp Bắt buộc thành các Tuyên bố? Đọc một quyển sách tốt?

PS Tôi không tìm kiếm một giải pháp cho truy vấn trên, tôi đã giải quyết nó.


1
Đây là một câu hỏi hay vì bạn đang nói lên một điểm yếu mà nhiều người (bao gồm cả bản thân tôi) mắc phải.
David Weiser

Nó có thể hữu ích để xác định những gì bạn có nghĩa là "quan hệ" trong câu hỏi của bạn. Trong mô hình quan hệ (toán học đằng sau SQL), "quan hệ" gần giống với bảng SQL. Rất nhiều người sẽ nói "quan hệ" khi họ thực sự muốn nói "mối quan hệ".
Jason Baker

Tìm hiểu lý thuyết tập hợp, và toán học rời rạc.

1
@ Jase21, cá nhân tôi khá quen thuộc với cả hai, nhưng những thứ không tầm thường trong SQL vẫn cảm thấy buồn cười. Không có ví dụ toán học sạch nào đối phó với những thứ kỳ lạ trong thế giới thực. Ngoài ra, người ta có thể sử dụng LINQ và do đó không bị làm phiền với SQL. Cuối cùng, với người hỏi: bạn sẽ quen với nó với thời gian.
Công việc

Câu trả lời:


12

Ý tưởng đằng sau việc thực hiện mọi thứ là bạn phải chỉ định cái gì chứ không phải làm thế nào .

Đối với tôi, có vẻ như bạn đang đi đúng hướng. Vấn đề không phải là bạn đang nghĩ về những điều sai lầm. Đó là bạn đang đi quá xa. Hãy nhìn vào những gì bạn đang cố gắng làm:

Ví dụ: giả sử bạn có ban nhạc quan hệ (bandName, bandCountry), địa điểm (địa chỉ tên, địa điểmCountry), lượt chơi (bandName, địa chỉ đất nước đó chơi ở địa điểm của tên đó.

Cho đến nay, điều này là tuyệt vời. Nhưng sau đó bạn làm điều này:

Trong tâm trí tôi lập tức đi "cho từng địa điểm. Lặp đi lặp lại trên tất cả các bandCountries và cho mỗi bandCountry có được danh sách các ban nhạc đến từ đó. Nếu không ai trong số họ chơi ở địa chỉName, hãy đến địa điểm tiếp theo Lặp lại thêm địa chỉName vào tập hợp các địa điểm tốt ".

Về bản chất, bạn đang làm những việc không cần thiết. Bạn biết những gì bạn muốn, đó là tất cả những gì bạn thực sự cần. Nhưng sau đó bạn tiếp tục và cố gắng tìm ra cách để có được nó.

Nếu tôi là bạn, tôi sẽ cố gắng tập thói quen sau:

  1. Xác định những gì bạn muốn.
  2. Có ý thức ngăn mình khỏi việc xác định làm thế nào để có được nó.
  3. Chỉ ra cách thể hiện những gì bạn muốn trong SQL.

Nó có thể mất một chút thời gian và nỗ lực từ phía bạn, nhưng một khi bạn thực sự mò mẫm lập trình khai báo, nó sẽ trở nên rất hữu ích. Trong thực tế, bạn có thể thấy mình sử dụng lập trình khai báo trong phần còn lại của mã.

Nếu bạn đang tìm kiếm một cuốn sách, tôi khuyên bạn nên sử dụng SQL và Lý thuyết quan hệ . Nó thực sự giúp bạn hiểu lý thuyết đằng sau cơ sở dữ liệu SQL. Chỉ cần nhớ thực hiện các khuyến nghị của Date với một hạt muối. Anh ấy cung cấp thông tin rất tốt, nhưng đôi khi anh ấy có thể có một chút quan điểm.


Tôi không hiểu làm thế nào để tìm ra làm thế nào để có được một cái gì đó là cách tiếp cận sai. Không quan trọng bạn đang sử dụng loại ngôn ngữ nào, bạn phải tìm ra cách nói với ngôn ngữ đó để làm những gì bạn muốn.
davidk01

9

suy nghĩ về các bộ, không lặp; các câu lệnh sql xác định các thuộc tính của tập hợp đầu ra mong muốn (còn gọi là bảng / quan hệ)

tất cả các địa điểm Tên như vậy cho mỗi ban nhạc. Có một ban nhạc từ quốc gia đó chơi ở địa điểm đó

kết quả của việc này (nếu tôi hiểu chính xác ý định của bạn!) sẽ là tập hợp các địa điểm có ít nhất một ban nhạc chơi ở địa điểm đó. Việc lặp lại trên bandCountry là không cần thiết, vì mối quan hệ PLAYS đã có thông tin mà bạn tìm kiếm, bạn chỉ cần loại bỏ các bản sao

Vì vậy, trong SQL, đây sẽ là:

select 
    distinct venueName
from PLAYS

EDIT: ok, vì vậy bộ thực tế mong muốn phức tạp hơn một chút. Câu hỏi đang được hỏi về cơ sở dữ liệu là: địa điểm nào đã tổ chức các ban nhạc từ tất cả các quốc gia?

Vì vậy, chúng tôi xác định tiêu chí thành viên cho một yếu tố của tập hợp mong muốn làm mục tiêu, sau đó làm việc ngược lại để đưa vào tập hợp. Địa điểm là thành viên của tập hợp đầu ra nếu nó có hàng PLAYS cho ít nhất một ban nhạc từ mọi quốc gia. Làm thế nào để chúng ta có được thông tin này?

Một cách là đếm các quốc gia riêng biệt cho từng địa điểm và so sánh nó với số lượng của tất cả các quốc gia. Nhưng chúng tôi không có mối quan hệ QUỐC GIA. Nếu chúng ta nghĩ về mô hình được đưa ra trong một thời điểm, chúng ta thấy rằng tập hợp của tất cả các quốc gia không phải là tiêu chí phù hợp; đó là tập hợp tất cả các quốc gia có ít nhất một ban nhạc. Vì vậy, chúng tôi không cần một bảng quốc gia (mặc dù đối với mô hình được chuẩn hóa, chúng tôi nên có một bảng) và chúng tôi không quan tâm đến quốc gia của địa điểm, chúng tôi chỉ có thể đếm các quốc gia có các ban nhạc, ví dụ: (trong MS-SQL )

declare @BandCountryCount int
select
    @BandCountryCount = COUNT(distinct bandCountry)
from BAND

Chúng tôi có thể đếm các quốc gia ban nhạc cho từng địa điểm

select
    P.venueName, COUNT(distinct B.bandCountry) as VenueBandCountryCount
from PLAYS P
    inner join BAND B on B.bandName = P.bandName

và chúng ta có thể ghép hai người lại với nhau bằng cách sử dụng một truy vấn con

select
    venueName
from (
    select
        P.venueName, COUNT(distinct B.bandCountry) as VenueBandCountryCount
    from PLAYS P
        inner join BAND B on B.bandName = P.bandName
) X
where X.VenueBandCountryCount = @BandCountryCount

Bây giờ, đó không phải là truy vấn đẹp nhất có thể (NHÓM THEO và HAVING có thể được coi là một giải pháp 'thanh lịch' hơn các biến tạm thời và một truy vấn phụ) nhưng rõ ràng chúng ta sẽ để nó theo mục đích của OP .

Mục đích của OP là học cách chuyển suy nghĩ từ mệnh lệnh sang khai báo. Cuối cùng, hãy nhìn vào những gì giải pháp bắt buộc được mô tả đang làm:

cho mỗi địa điểm Tên lặp đi lặp lại trên tất cả các bandCountries và cho mỗi bandCountry có được danh sách các ban nhạc xuất phát từ đó. Nếu không ai trong số họ chơi trong địa chỉName, hãy đến địa chỉ tiếp theo. Khác, ở cuối ban nhạc Lặp đi lặp lại thêm địa điểm Tên vào tập hợp địa điểm tốtNames

Các tiêu chí xác định ở trên là gì? Tôi nghĩ rằng nó là:

... Nếu không ai trong số họ [nhóm các ban nhạc từ một quốc gia cụ thể] chơi ở địa điểm ...

Đây là một tiêu chí không đạt chuẩn . Quá trình suy nghĩ cấp bách đang bắt đầu với một thùng đầy đủ và loại bỏ những thứ không phù hợp với tiêu chí. Chúng tôi đang lọc dữ liệu.

Điều đó tốt cho những thứ đơn giản, nhưng nó giúp suy nghĩ về mặt xây dựng tập kết quả mong muốn; các tiêu chí đủ điều kiện tương ứng sẽ cho phép một người điền vào thùng thay thế là gì?

  • người không đủ tiêu chuẩn: nếu không có ban nhạc từ ban nhạcCountry chơi tại một địa điểm, địa điểm đó sẽ bị loại
  • (một phần) vòng loại: nếu có ít nhất một ban nhạc từ một ban nhạcCountry chơi tại một địa điểm, thì địa điểm đó có thể ổn; tiếp tục kiểm tra phần còn lại của bandCountries
  • (đầy đủ) vòng loại: nếu có ít nhất một ban nhạc từ mỗi ban nhạcCountry phát tại một địa điểm, thì địa điểm đó đủ điều kiện

Vòng loại cuối cùng có thể được đơn giản hóa bằng cách sử dụng số lượng: một bandCountry được 'hài lòng' nếu có ít nhất một ban nhạc từ đó chơi tại một địa điểm; số lượng quốc gia ban nhạc 'hài lòng' cho một địa điểm phải bằng số lượng quốc gia của ban nhạc để địa điểm đó đủ điều kiện.

Bây giờ chúng ta có thể lý luận qua các mối quan hệ bằng cách điều hướng:

  • bắt đầu với mối quan hệ VENUE [chúng tôi không cần nó cho câu trả lời, nhưng đó là điểm bắt đầu khái niệm cho điều hướng quan hệ]
  • tham gia CHƠI trên địa điểm
  • tham gia BAND trên bandName để nhận bandCountry
  • chúng tôi không quan tâm đến tên ban nhạc; chỉ chọn địa điểmName và bandCountry
  • chúng tôi không quan tâm đến bandCountries dư thừa; loại bỏ trùng lặp bằng cách sử dụng DISTRICT hoặc GROUP BY
  • chúng tôi chỉ quan tâm đến số lượng bandCountries riêng biệt, không phải tên
  • chúng tôi chỉ muốn các địa điểm có số lượng bandCountries khác nhau bằng tổng số bandCountries

dẫn đến giải pháp ở trên (hoặc một bản fax hợp lý)

TÓM LƯỢC

  • đặt lý thuyết
  • đường dẫn điều hướng quan hệ
  • bao gồm so với tiêu chí độc quyền (đủ điều kiện vs không đủ tiêu chuẩn)

Đó thực sự là "tập hợp các địa điểm mà các ban nhạc từ tất cả các quốc gia (bandCountry> = địa điểmCountry) đã chơi ở đó".
EpsilonVector

@EpsilonVector: xem các chỉnh sửa
Steven A. Lowe

4

Một cách để học cách suy nghĩ và lập trình theo kiểu khai báo là học một ngôn ngữ mảng có mục đích chung như APL hoặc J. SQL có lẽ không phải là phương tiện tốt nhất để học cách lập trình khai báo. Trong APL hoặc J, bạn học cách vận hành trên toàn bộ mảng (vectơ, ma trận hoặc mảng có thứ hạng cao hơn), mà không cần lặp hoặc lặp rõ ràng. Điều này làm cho việc hiểu SQL và đại số quan hệ dễ dàng hơn nhiều. Một ví dụ rất đơn giản, để chọn các mục từ vectơ V có giá trị lớn hơn 100, trong APL, chúng tôi viết:

(V>100)/V

Ở đây V> 100 ước tính cho một mảng boolean có cùng hình dạng với V, với 1 là đánh dấu các giá trị chúng ta muốn giữ. Điều này không xảy ra với APLer dày dạn rằng có sự lặp lại đang diễn ra, chúng ta chỉ đang áp dụng mặt nạ cho vectơ V, trả về một vectơ mới. Tất nhiên đây là khái niệm về một SQL mà mệnh đề hoặc đại số quan hệ hạn chế hoạt động đang làm.

Tôi không nghĩ rằng bạn có thể hiểu rõ về lập trình khai báo mà không cần thực hiện nhiều và SQL nói chung là quá cụ thể. Bạn cần phải viết rất nhiều mã mục đích chung, học cách làm mà không cần vòng lặp và cấu trúc if / then / other và tất cả các thiết bị tham gia lập trình theo kiểu bắt buộc, theo thủ tục và vô hướng.

Có thể có các ngôn ngữ chức năng khác cũng hỗ trợ cho cách suy nghĩ này, nhưng các ngôn ngữ mảng rất gần với SQL.


+1 cho "[bạn không thể] nắm bắt tốt ... mà không cần thực hiện nhiều". Không ai học lập trình mệnh lệnh (với các cấu trúc phản trực giác rõ ràng như thế a = a + 1) qua đêm. Phải mất thời gian để học các phong cách khai báo như logic, chức năng, và al al giống như mất thời gian để học lập trình mệnh lệnh.
CHỈ CẦN HOẠT ĐỘNG CỦA TÔI

1

Đầu tiên, bạn phải học cả hai. Bạn có thể có một sở thích, nhưng khi làm việc ở những nơi khác tốt hơn, đừng chống lại nó. Rất nhiều lập trình viên bị cám dỗ sử dụng các con trỏ trong cơ sở dữ liệu quan hệ vì chúng được sử dụng để bước qua từng bản ghi, nhưng cơ sở dữ liệu tốt hơn nhiều trong các bộ. Bạn không muốn đi vào suy nghĩ "Tôi biết cách làm theo cách này và tôi có quyền kiểm soát nhiều nhất, blah, blah, blah".


1

Bạn học cách suy nghĩ một cách khai báo giống như bạn đã học cách suy nghĩ bắt buộc: bằng cách thực hành bắt đầu với những vấn đề đơn giản hơn và làm việc khi bạn "hiểu".

Những trải nghiệm đầu tiên của bạn với lập trình mệnh lệnh bao gồm cả một loạt các tuyên bố phản trực giác (và trên thực tế, hoàn toàn vô lý) như " a = a + 1". Bạn bao bọc suy nghĩ của mình xung quanh vấn đề đó đến mức bây giờ bạn thậm chí có thể không nhớ lại việc thu hồi từ sự không trung thực rõ ràng của tuyên bố. Vấn đề của bạn với các kiểu khai báo là bạn trở lại vị trí của mình khi bạn bắt đầu với các kiểu bắt buộc: một "newb cluless". Tệ hơn nữa, bạn đã có nhiều năm luyện tập với một phong cách hoàn toàn mâu thuẫn với phong cách mới này và có nhiều năm thói quen để hoàn tác - như thói quen "kiểm soát bằng mọi giá".

Phong cách khai báo hoạt động với một cách tiếp cận khác mà bây giờ bạn thiếu trực giác (trừ khi bạn giữ kỹ năng toán học của mình rất sắc bén trong nhiều năm - điều mà hầu hết mọi người không làm được). Bạn phải học lại cách suy nghĩ và cách duy nhất để học lại đó là làm điều đó, một bước đơn giản tại một thời điểm.

Chọn SQL là bước đột phá đầu tiên của bạn vào lập trình khai báo có thể là một sai lầm nếu bạn thực sự muốn tìm hiểu các khái niệm. Chắc chắn tính toán tuple mà nó dựa trên là khai báo, thực sự, nhưng thật không may, độ tinh khiết của tính toán tuple đã bị ảnh hưởng xấu bởi thực tế triển khai và ngôn ngữ, thực tế, đã trở thành một mớ hỗn độn. Thay vào đó, bạn có thể muốn xem xét các ngôn ngữ khai báo khác hữu ích hơn (theo nghĩa bạn đã từng sử dụng) như Lisps (đặc biệt là Scheme ), HaskellML cho lập trình chức năng (chủ yếu) hoặc, thay vào đó, PrologMercury cho (chủ yếu) lập trình logic.

Học các ngôn ngữ khác này sẽ giúp bạn hiểu rõ hơn, theo ý kiến ​​của tôi, về cách lập trình khai báo hoạt động vì một vài lý do:

  1. Chúng rất hữu ích cho lập trình "từ nôi đến mộ" - vì bạn có thể viết một chương trình đầy đủ bằng các ngôn ngữ này từ đầu đến cuối. Chúng rất hữu ích khi đứng một mình, không giống như SQL, thứ thực sự khá vô dụng đối với hầu hết mọi người như một ngôn ngữ độc lập.

  2. Mỗi người cung cấp cho bạn một thái độ khác nhau về lập trình khai báo có thể cung cấp cho bạn những con đường khác nhau để cuối cùng "hiểu được".

  3. Họ cũng cung cấp cho bạn một suy nghĩ khác nhau về lập trình nói chung. Họ sẽ cải thiện khả năng suy luận về các vấn đề và mã hóa của bạn ngay cả khi bạn không bao giờ trực tiếp sử dụng chúng.

  4. Các bài học bạn học được từ chúng cũng sẽ giúp bạn với SQL của bạn - đặc biệt là nếu bạn theo dõi các tính toán tuple đằng sau cơ sở dữ liệu quan hệ cho hình thức suy nghĩ thuần túy về dữ liệu.

Tôi đặc biệt khuyên bạn nên học một trong những ngôn ngữ chức năng ( Clojure , là một trong những ngôn ngữ Lisps, có lẽ là một lựa chọn tốt ở đây) một trong những ngôn ngữ logic (tôi thích nhất Mercury, nhưng Prolog có nhiều tài liệu hữu ích hơn cho việc học) để mở rộng quá trình suy nghĩ tối đa.


1

Không sai khi nghĩ bắt buộc trong một thiết lập khai báo như SQL. Chỉ là suy nghĩ cấp bách nên xảy ra ở cấp độ cao hơn một chút so với những gì bạn mô tả. Bất cứ khi nào tôi cần truy vấn cơ sở dữ liệu sử dụng SQL, tôi luôn tự nghĩ:

  • Đây là những mảnh tôi cần.
  • Tôi sẽ kết hợp chúng theo cách này.
  • Tôi sẽ giảm bớt những gì tôi vừa đạt được với các vị từ sau để có được thứ tôi thực sự đang tìm kiếm.

Trên đây là một thuật toán mệnh lệnh cấp cao và nó hoạt động khá tốt đối với tôi trong cài đặt SQL. Tôi nghĩ rằng đây được coi là một cách tiếp cận từ trên xuống và Steven A. Lowe mô tả một cách tiếp cận từ dưới lên khá tốt .


1

Chìa khóa cho câu hỏi của bạn nằm ở những gì bạn đã nói trong đoạn kế tiếp: "Bạn không thể nói như thế trong SQL." Ở giai đoạn này có thể hữu ích hơn cho bạn khi tiếp cận SQL như một ngôn ngữ nước ngoài thay vì ngôn ngữ lập trình. Nếu bạn nghĩ về nó theo cách này, viết một truy vấn SQL thực sự đang dịch một câu tiếng Anh về những gì bạn muốn thành "SQLish". Máy tính hiểu hoàn toàn SQLish và sẽ thực hiện chính xác những gì bạn nói, vì vậy bạn không cần phải lo lắng về việc triển khai miễn là bạn dịch đúng.

Điều đó nói rằng, cách tốt nhất để học ngoại ngữ là gì? Bạn rõ ràng phải học ngữ pháp và từ vựng mà bạn có thể nhận được từ tài liệu SQL của mình. Điều quan trọng nhất là thực hành. Bạn nên đọc và viết càng nhiều SQL càng tốt, và đừng cảm thấy rằng bạn phải biết kỹ cú pháp trước; bạn có thể, và nên, tìm kiếm mọi thứ khi bạn đi cùng. Bạn sẽ biết bạn đã có nó khi bạn thấy việc mô tả dữ liệu nào bạn muốn bằng SQL dễ dàng hơn bằng tiếng Anh.


1

Tôi cũng mất một thời gian dài để quấn đầu quanh SQL. Chúng tôi đã làm một số lý thuyết quan hệ tại trường đại học và tại thời điểm đó, chỉ phục vụ để làm phức tạp vấn đề. Cuối cùng, quá trình học tập của tôi là rất nhiều thử nghiệm và lỗi được thông báo bởi các tài liệu học tập và ví dụ khác nhau mà tôi thấy hữu ích trên đường đi. Về cơ bản, cuối cùng bạn sẽ quen với nó, và thêm một cách suy nghĩ mới về dữ liệu và truy vấn sẽ có giá trị cho sự phát triển tinh thần của bạn.

Tôi thấy rằng tôi có thể tăng tốc học tập bằng cách xây dựng dần một tập hợp các tập lệnh đơn giản thể hiện cách sử dụng từng tính năng ngôn ngữ và cách đạt được kết quả nhất định trên một bảng đã biết (bao gồm các định nghĩa bảng để tham khảo).

Đầu năm nay tôi đã thực hiện một số khóa đào tạo chính thức liên quan đến một dự án di chuyển dữ liệu trên cơ sở dữ liệu Oracle lộn xộn, nơi tôi phải dần dần ghép các đoạn từ thư viện của mình để lọc kết quả truy vấn theo nhiều cách khác nhau cho đến khi tôi có chính xác những gì tôi muốn, sau đó chuyển đổi chúng thành cần thiết, v.v. Một số truy vấn trở nên rất phức tạp và khó gỡ lỗi. Tôi nghi ngờ tôi có thể đọc chúng ngay bây giờ, nhưng tôi hy vọng tôi có thể đi đến một giải pháp tương tự một lần nữa bằng cách sử dụng các khối xây dựng tham chiếu của tôi.

Các cách khác để tăng nhận thức trực quan của bạn về không gian khai báo và chức năng là học lý thuyết tập hợp và ngôn ngữ lập trình phù hợp hơn với mô hình cụ thể. Tôi hiện đang trong quá trình học một số Haskell, ví dụ, để duy trì và cải thiện khả năng toán học của mình.


0

Khi bạn đối mặt với một vấn đề bạn thường nghĩ làm thế nào để giải quyết nó. Nhưng nếu bạn biết làm thế nào máy tính giải quyết nó cho bạn! Sau đó, bạn quan tâm về việc sẽ bị loại như thế nào .

Tôi cố gắng nói làm thế nào nó xảy ra.

Bạn có thể đã quen thuộc với các chương trình đệ quy, trong các chương trình đệ quy, bạn xác định vấn đề thay vì nói nó được giải quyết như thế nào. bạn xác định cơ sở và xác định n dựa trên n-1 . (ví dụ factorial(n) = n * factorial(n-1)) Nhưng bạn có thể đã biết máy tính giải quyết nó như thế nào . nó bắt đầu từ hàm và gọi hàm đệ quy cho đến khi đạt được định nghĩa cơ sở, sau đó đánh giá tất cả các hàm khác dựa trên giá trị cơ sở.

Đó là những gì xảy ra trong lập trình khai báo. bạn xác định mọi thứ dựa trên các định nghĩa hiện có. Và máy tính biết làm thế nào để rút ra câu trả lời cho bạn dựa trên các chức năng cơ bản.

Trong SQL, bạn không thể liên kết các định nghĩa với nhau nhưng bạn liên quan đến các đối tượng hoặc thông tin với nhau, bạn chỉ định những gì bạn muốn và tìm kiếm trên máy tính với một cái gì đó (đối tượng, thông tin) dựa trên các mối quan hệ bạn đã cung cấp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.