Tiền tố ST_ có phù hợp với các chức năng không có trong SQL / MM Phần 3 không?

Tôi đã đọc một chủ đề về phần mở rộng không gian địa lý cho Presto trong vấn đề Github này , nơi một chức năng line_locate_point, đã được giới thiệu. Nó được dựa trên ST_LineLocatePointchức năng của PostGIS , trả về một số float biểu thị phân số dọc theo một điểm của điểm gần nhất trên dòng đó đến một vị trí nhất định.

Câu hỏi được đưa ra tại sao nó được đặt tên line_locate_pointvà không ST_LineLocatePointgiống như phiên bản PostGIS. Câu trả lời là chức năng này không tồn tại trong tiêu chuẩn SQL / MM Phần 3 và vì vậy nó không nên bắt đầu bằng ST_.

Đọc nhanh qua tiêu chuẩn, tôi không thấy bất kỳ bình luận nào về cách xử lý các trường hợp bạn giới thiệu chức năng không gian cho cơ sở dữ liệu của bạn không có trong tiêu chuẩn. Là tinh thần của ST_tiền tố để phân biệt các chức năng không gian với các chức năng không phải không gian (dường như là trường hợp của PostGIS), hay là để chỉ ra rằng chức năng này tuân thủ chức năng tương đương trong SQL / MM Phần 3?

Nhìn vào trạng thái hiện tại của API của Presto , tôi phải nói rằng cách tiếp cận sau có vẻ không rõ ràng và đưa ra một số nhầm lẫn về lý do tại sao các tên không nhất quán, nhưng có lẽ điều này có thể được giải quyết bằng một ghi chú đơn giản ở trên cùng.

Sau đó, câu hỏi của tôi là liệu có một khía cạnh nào của tiêu chuẩn mà tôi đang xem xét cho phép các phần mở rộng của nó vượt ra ngoài tập hợp các đối tượng không gian được xác định hay nói cách khác, nếu điều này bị cấm theo một số quy tắc được viết hoặc không thành văn của các tiêu chuẩn theo .

— Cầu
nguồn

Tôi nghĩ rằng đó là một câu hỏi công bằng, nhưng, về cơ bản là vấn đề quan điểm. Tôi hy vọng tất cả các hàm rõ ràng là không gian, tức là chúng hoạt động trên một vectơ, raster, cấu trúc liên kết, bề mặt 3D, v.v., để lấy tiền tố ST_. Tôi chưa bao giờ nghĩ rằng liệu đây có phải là cách sử dụng phù hợp hay không dựa trên việc nó có trong thông số kỹ thuật hay không. Mặc dù khả năng tương tác là quan trọng và mong muốn, tôi chắc chắn sẽ không muốn Postgis giữ lại bằng cách chỉ thực hiện các chức năng trong thông số SQL / MM. Và tôi nghĩ rằng việc sử dụng một số tiền tố khác sẽ gây ra nhiều nhầm lẫn.

— John Powell

Tôi không hiểu tại sao câu hỏi của tôi bị hoãn lại vì "dựa trên quan điểm". Câu hỏi của tôi là dứt khoát về việc liệu nó là dựa vào ý kiến, hoặc nếu có một số khía cạnh của tiêu chuẩn Tôi nhìn mà làm cho quyết định này dựa trên thực tế.

— Brideau

Xin lỗi, tôi vừa đọc lại câu hỏi của bạn và thực sự có một câu hỏi rõ ràng, không dựa trên ý kiến trong đó. 2c của tôi là nếu nó rõ ràng là không gian, nó sẽ có ST_, bất kể nó có trong tiêu chuẩn hay không. Tôi đã bỏ phiếu mở lại.

— John Powell

Đối với tâm trí của tôi đó là ý kiến dựa. Tiêu chuẩn SQL / MM không thể từ chối các nhà phát triển tạo các hàm riêng của họ với tiền tố ST_ nếu họ muốn, ngay cả các hàm không phải không gian. Tuy nhiên, các nhà phát triển có thể muốn làm điều đó theo một cách khác. Để so sánh, SpatiaLite có nhiều hàm không gian nhưng không phải SQL / MM có từ đồng nghĩa ST_, một số khác không có gaia-gis.it/gaia-sins/spatialite-sql-latest.html .

— dùng49584

Liệu SQL / MM có thể hoặc không thể buộc nhà phát triển làm điều gì đó không phải là câu hỏi tôi đang hỏi. Tôi đang hỏi về những gì tiêu chuẩn tự đề nghị. Tiêu chuẩn dài 1500 trang và tôi chưa đọc từng dòng của nó, vì vậy tôi đang yêu cầu cộng đồng ở đây - một số người giúp viết nó và các tiêu chuẩn liên quan - những gì được khuyến nghị, hoặc có lẽ liệu nó có trì hoãn các quyết định này không một tiêu chuẩn khác hoặc rõ ràng đã chọn không giải quyết điều này. Đây là những yêu cầu dựa trên thực tế.

— Brideau

Các đặc tả OpenSpatial nói rất nhiều điều về vấn đề này,

Khi tích hợp SQL này với SQL / MM, tiền tố tên loại " ST_" nên được sử dụng khi thích hợp.

Và,

Tên lớp trong SQL / MM mang ST_tiền tố "". Đây là tùy chọn và việc triển khai có thể chọn bỏ tiền tố này như đã được thực hiện ở nhiều nơi trong tiêu chuẩn này.

Từ Ủy ban này Dự thảo ISO / IEC CD13249-3 ed 5

Phần này của ISO / IEC 13249 sử dụng tiền tố ST_cho loại, thuộc tính do người dùng định nghĩa, tên thường trình được gọi bằng SQL và tên xem. Phần này của ISO / IEC 13249 sử dụng tiền tố ' ST_Private' cho tên của các thuộc tính nhất định. Việc sử dụng ' ST_Private' chỉ ra rằng thuộc tính không dành cho sử dụng công cộng.

Vì vậy, đây là những gì chúng ta có,

SQL / MM đề nghị sử dụng tiền tố.
SQL / MM cho biết tiền tố là tùy chọn.
ISO cũng sử dụng ST_tiền tố ..

Tôi sẽ nói điều này,

Việc sử dụng ST_nên được coi là từ khóa không dành riêng cho người dùng cuối. Thực sự không có lý do để thực hiện các chức năng của người dùng cuối với tiền tố này. Bạn nên sử dụng tốt hơn STx_. Chúng tôi biết ít nhất hai cơ quan đã xuất bản với đề xuất tiền tố này (OpenSpatial) SQL / MM và ISO. Ngoài ra, nhiều biểu tượng gây ô nhiễm của RDBMS với tiền tố đó.

Có thể có nhiều hơn về lịch sử, nhưng tôi không thể tìm thấy bất kỳ thông tin hiện đại nào về điều này.

— Evan Carroll
nguồn