ตัวอย่างก่อนหน้านี้สำหรับเหตุผลที่ Prolog ได้รับความนิยมน้อยกว่า SQL ในการเขียนโปรแกรมเชิงซ้อน [ปิด]

12

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้

ปิดให้บริการใน5 ปีที่ผ่านมา

มันดูเหมือนว่าจะเขียนบอกเล่า SQLเป็นที่นิยมมากในการเขียนโปรแกรมจำเป็น อย่างไรก็ตามมันก็ดูเหมือนว่าการเขียนDeclarative Prologสามารถบันทึกความซับซ้อนมากมาย แต่นี่ไม่ใช่เรื่องธรรมดา

มีแบบอย่างในอดีตสำหรับการตั้งค่าที่ชัดเจนของ SQL มากกว่า Prolog นี้หรือไม่?

หากเหตุผลคือขาดการสนับสนุนดั้งเดิมโดยภาษาที่จำเป็นแล้วเป็นไปได้ไหมที่จะตอบว่าทำไมผู้สร้างภาษาไม่พบว่ามีประโยชน์ในการสนับสนุนโดยกำเนิดPrologตั้งแต่แรก?

เพื่อให้ตัวอย่างเฉพาะ:

ตัวอย่างที่ 1 การ
ประเมินแอปพลิเคชันสินเชื่ออาจเป็นโค้ดเพียงไม่กี่บรรทัดPrologเช่นSELECT/JOINข้อความค้นหาที่เป็นโค้ดเพียงไม่กี่บรรทัดSQLแต่ดูเหมือนว่าข้อดีจะไม่ชัดเจนเท่าที่SQLควร

ตัวอย่างที่ 2
นี่คือปัญหาตัวอย่างอื่นและวิธีแก้ไขใน Prolog โปรแกรมตรรกะข้อ จำกัด ต่อไปนี้แสดงชุดข้อมูลที่ง่ายของประวัติของ john ในฐานะครู:

teaches(john, hardware, T) :- 1990 ≤ T, T < 1999.
teaches(john, software, T) :- 1999 ≤ T, T < 2005.
teaches(john, logic, T) :- 2005 ≤ T, T ≤ 2012.
rank(john, instructor, T) :- 1990 ≤ T, T < 2010.
rank(john, professor, T) :- 2010 ≤ T, T < 2014.

ประโยคเป้าหมายต่อไปนี้จะสืบค้นชุดข้อมูลเพื่อหาว่าเมื่อใด John ได้สอนตรรกะและเป็นอาจารย์ :

:- teaches(john, logic, T), rank(john, professor, T).

ผลลัพธ์:

2010 ≤ T, T ≤ 2012.

ในตัวอย่างด้านบนมันจะง่ายที่SQLจะได้ผลลัพธ์เดียวกัน Arrayแต่สมมติว่าคุณมีข้อมูลนี้ในการ SQLแล้วมันไม่ได้เป็นเรื่องง่ายที่จะได้รับผลเดียวกันโดยใช้ และในกรณีของข้อมูลที่เก็บไว้ในอาร์เรย์ฉันเชื่อว่ารหัส Prolog จะง่ายต่อการเขียนและบำรุงรักษา

— 53777A
แหล่งที่มา

8

คุณอาจต้องการลดระดับการคุยโว

4

ข้อความส่วนใหญ่ดูเหมือนจะพูดจาโผงผางกับคนที่ไม่ใช้ Prolog มีคำถามที่น่าถามอยู่ในนั้น แต่สิ่งอื่น ๆ (ผู้โวยวาย) ดึงดูด downvotes และปิดผู้ที่สามารถมีส่วนร่วมในการตอบคำถาม ฉันขอแนะนำให้คุณลองใช้ถ้อยคำของคุณในแบบที่เป็นกุศลมากกว่า

6

"ตัวอย่างเช่นการประเมินแอปพลิเคชันสินเชื่ออาจเป็นโค้ดเพียงไม่กี่บรรทัดใน Prolog" ฉันไม่ได้ซื้อเพราะเหตุผลเดียวกับแอปพลิเคชันใด ๆ ที่มีค่าเพราะเกลือจะใช้เคียวรี SQL แบบกำหนดเองหรือสร้างขึ้นจำนวนมาก

— ร่าเริง

7

บางทีฉันหายไปบางอย่าง แต่ผมคิดว่าคำตอบที่นี่คือ'คนใช้ SQL เนื่องจากว่าสิ่งที่ฐานข้อมูลสนับสนุน'

— GrandmasterB

3

พวกเขาไม่ใช้เปิดฉาก ... ดี ... จริง ... พวกเขาทำใช้กฎเครื่องยนต์ซึ่งเป็น"เฉพาะกิจทางการระบุข้อผิดพลาดสลัดการดำเนินงานช้าของครึ่งหนึ่งของเปิดฉาก"

— Jörg W Mittag

19

ฉันเชื่อว่านี่เป็นเรื่องทางประวัติศาสตร์เป็นหลัก

SQL ถูกใช้เป็นหลักในการทำธุรกิจสำหรับการใช้งานทางธุรกิจ บริษัท บางแห่งสร้างความมีชีวิตชีวาในการขายโซลูชัน SQL และใช้เงินเพื่อโฆษณาและผลักดัน SQL ให้เป็นที่สนใจของหลาย ๆ คน นี่คือพลังโดยเฉพาะอย่างยิ่งข้อมูลสำคัญสำหรับนักธุรกิจ นี่คือเหตุผลที่ SQL ชนะใจคู่แข่งมากมายและเป็นที่รู้จักและใช้กันอย่างแพร่หลายในทุกวันนี้

อารัมภบทในทางอื่นเป็นที่รู้จักกันดีในวงการวิชาการมักจะอยู่ในพื้นที่ของปัญญาประดิษฐ์ นักวิชาการไม่ค่อยผลักดันเครื่องมือและแนวคิดให้กับผู้อื่นในแบบที่ธุรกิจทำ มันมักจะต้องมี บริษัท บางแห่งในการโฆษณาเทคโนโลยีที่เกิดในสถาบันการศึกษาเพื่อให้แพร่กระจายในหมู่นักพัฒนาทั่วไป ในขณะที่ข้อมูลมีความสำคัญอย่างยิ่ง "กฎเกณฑ์ทางธุรกิจ" ก็ไม่เป็นเช่นนั้น ในขณะที่พวกเขาอาจดูเหมือนมีความสำคัญพวกเขามีความสำคัญน้อยกว่าข้อมูล กฎเกณฑ์ทางธุรกิจสามารถแก้ไขได้อย่างง่ายดาย การพยายามแก้ไขข้อมูลที่ "แตก" มักเป็นปัญหาที่ยากกว่ามาก ดังนั้นธุรกิจจึงให้ความสำคัญกับการแก้ปัญหาข้อมูลมากกว่าโซลูชันกฎเกณฑ์ทางธุรกิจ

— ร่าเริง
แหล่งที่มา

2

"โดยปกติแล้ว บริษัท บางแห่งต้องการโฆษณาเทคโนโลยีที่เกิดขึ้นในสถาบันการศึกษาเพื่อให้แพร่หลายในหมู่นักพัฒนาทั่วไป": จริง แนวคิดที่ดีมากมายได้รับการพัฒนาในด้านวิชาการและต่อมาได้รับความนิยมจาก บริษัท ที่มีอำนาจทางการตลาดในการทำเช่นนั้น +1

— Giorgio

6

เหตุผลง่ายจริง ๆ มันไม่มีส่วนเกี่ยวข้องกับการใช้ภาษาที่มีประโยชน์สำหรับงานที่ได้รับและทุกอย่างเกี่ยวกับวิธีการดูแลรักษาโค้ด

การอ่านคำสั่ง SQL ผู้พัฒนาจำนวนมากจะสามารถกำหนดสิ่งที่แบบสอบถามพื้นฐานส่วนใหญ่ทำโดยไม่ทราบภาษา พวกเขาอาจมีเวลายากขึ้นในกรณีของตัวอย่างที่ซับซ้อน แต่การดัดแปลงโค้ดที่มีอยู่หรือการทำงานจากตัวอย่างนั้นค่อนข้างง่าย อุปสรรคต่อความเข้าใจค่อนข้างต่ำสำหรับการค้นหาส่วนใหญ่

คุณอ่านบทประพันธ์สองสามบรรทัดและนักพัฒนาหลายคนจะไขว้เขวเล็กน้อยและออกจากงานเพื่อคนอื่นและอาจไปนอน ไวยากรณ์ของภาคอารัมภบทของอารัมภบทไม่ได้เป็นการง่ายที่จะอ่าน

ปรับปรุง:

จากตัวอย่างรหัสภาษาที่ใช้งานคอลเลกชันน่าจะทำได้ดี ฉันใช้วิธีแก้ปัญหาใน C # / Linq และมันก็ไม่ได้ใหญ่กว่าตัวอย่าง prolog (เมื่อคุณคิดการพิมพ์และคำจำกัดความคงที่) มีขั้นตอนพิเศษที่เกี่ยวข้องในการทำงานชั่วคราวบางรายการเพื่อรวมรายการเพื่อสร้างไทม์ไลน์เดียวเพื่อค้นหา แต่มันก็ไม่ได้เป็นงานที่มีจำนวนมาก

— James Snell
แหล่งที่มา

14

มันเป็นความจริงที่ SQL เข้าสู่คลาส ultra-verbose ของ COBOL และไวยากรณ์ "natural" ที่ทำให้อ่านง่าย แต่ผมอย่างรุนแรงข้อสงสัยว่าคนที่ไม่ได้รู้ SQL จะสามารถที่จะต้องทำความเข้าใจคำสั่งที่ซับซ้อนขนาดกลางที่มีไม่กี่joinหรือcount(*)หรืออะไรอย่างนั้น ถ้าเราเข้าใจพื้นฐานของ SQL เป็นเพราะเราต้องใช้ภาษานั้นเป็นครั้งคราวดังนั้นจึงต้องเรียนรู้พื้นฐานเหล่านี้ การจัดเก็บข้อมูลเชิงสัมพันธ์เป็นความต้องการทั่วไปมากกว่าการแก้ระบบตรรกะดังนั้นจึงไม่มีความจำเป็นอย่างยิ่งที่จะเรียนรู้ภาษาโปรล็อก

— amon

3

@amon ฟังดูเหมือนคำตอบที่ดี :-)

— svick

1

อุปสรรคในการเรียนรู้ SQL อาจลดลงเนื่องจากความสามารถในการอ่าน prolog อาจปิดกั้นผู้คนเนื่องจากไวยากรณ์ฉันเห็นด้วยอย่างยิ่ง แต่แท้จริงแล้วโดยไม่ทราบว่าแบบสอบถามย่อยเข้าใจ SQL และเข้าร่วมไม่กี่เรื่องไม่สำคัญ แต่อุปสรรคที่ต่ำกว่าเมื่อเริ่มต้นด้วยการค้นหาที่เรียบง่ายย่อมเป็นเหตุผลที่ผู้คนจะใช้ SQL แทน Prolog เพื่อเริ่มต้น :)

— Dylan Meeus

4

@JamesSnell ขออภัย แต่ -1 สิ่งที่คุณจะอ้างว่าไม่ตรงกับRegEx

^(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[13-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$

.

— 53777A

1

@JamesSnell RegEx มีความลับยากที่จะเขียนแก้ปัญหาบำรุงรักษาและแก้ไขหรือขยาย แต่ก็เป็นที่นิยมอย่างมาก หากคุณพูดถูก RegEx ไม่ควรได้รับความนิยมในปัจจุบันระหว่างผู้พัฒนาและผู้สร้างภาษา

— 53777A

4

มีอีกเหตุผลหนึ่งคือ พูดจริง SQL มีประโยชน์สำหรับข้อมูลคงอยู่บนดิสก์ ดังนั้นฐานข้อมูลจะถูกใช้เพื่อเก็บข้อมูลเป็นเวลา "นาน" (หลายเดือน) ฐานข้อมูล SQL ทุกตัว (เช่น PostgreSQL, MySQL, Oracle, .... ) กำลังจัดการข้อมูลบนดิสก์ (หรือ SSD เช่นฮาร์ดแวร์ที่สามารถเก็บข้อมูลได้หากปิดระบบไว้อย่างเหมาะสม) อย่างไรก็ตามการใช้งาน Prolog ส่วนใหญ่ที่ฉันรู้ว่ากำลังทำงานอยู่ในหน่วยความจำและไม่สามารถใช้ในการเก็บข้อมูลได้อย่างน่าเชื่อถือ (ข้อมูลยังคงอยู่หลังจากไฟดับอย่างน้อยหนึ่งโปรแกรม) และการใช้ SQL สามารถจัดการกับเทราไบต์ของข้อมูล ...

แน่นอน DBMS ไม่ได้เขียนลงในดิสก์ทันที (แต่ภายหลัง) แต่ล่ามภาษาอารัมภบทที่ฉันได้ยินไม่เคยเขียน (โดยปริยาย) ข้อเท็จจริงและกฎพื้นฐานของพวกเขาเพื่อให้พวกเขาอยู่ในดิสก์

(การปรับใช้ภาษาบางอย่างมีความสามารถในการคงอยู่เช่น SBCL กับsave-lisp-and-die... แต่ฉันรู้ว่าไม่มีภาษาอารัมภบททำเช่นนั้น)

ในทางปฏิบัติการพูด SQL สำหรับฐานข้อมูลบนดิสก์ - แต่ Prolog เป็นภาษาโปรแกรม (สำหรับซอร์สโค้ดในไฟล์ต้นฉบับ)

— Basile Starynkevitch
แหล่งที่มา

1

ฉันไม่คิดอย่างนั้นเนื่องจากไม่มีฐานข้อมูล SQL ที่ทำงานกับดิสก์ I / O อย่างเคร่งครัดเนื่องจากจะไม่มีประสิทธิภาพมาก (มีข้อมูลในหน่วยความจำอยู่ตลอดเวลา) และไม่มีสิ่งกีดขวางทางเทคนิคในการจัดลำดับข้อ จำกัด ของบทนำกับดิสก์ที่ฉัน สามารถคิดในขณะนี้

— idoby

3

ในทางทฤษฎี SQL เป็นภาษาแบบสอบถามและไม่สนใจว่าจะเก็บข้อมูลอย่างไรตราบใดที่ข้อมูลถูกอธิบายโดยโมเดลเชิงสัมพันธ์ SQL เป็นเพียงส่วนต่อประสานไม่ใช่กระบวนทัศน์ มีฐานข้อมูลที่ใช้ SQL ที่ทำงานอย่างหมดจดหรือบางส่วนในหน่วยความจำไม่ถาวร มันจะเป็นไปได้สำหรับฐานข้อมูลที่ใช้ SQL เพื่อเก็บข้อมูลในรูปแบบของข้อเท็จจริง Prolog! [อ้างจำเป็น] หลังจากทั้งหมดข้อเท็จจริงเพียงอธิบายความสัมพันธ์ ในทางกลับกันอาจเป็นไปได้ที่โปรแกรม Prolog จะเก็บข้อเท็จจริงในรูปแบบฐานข้อมูลบนดิสก์แทนที่จะโหลดทุกอย่างลงในหน่วยความจำ

— amon

1

ตามหลักวิชาใช่แล้ว แต่ SQL จริง ๆ แล้วกำลังเก็บอยู่บนดิสก์และนั่นก็เป็นสิ่งจำเป็น

— Basile Starynkevitch

1

@BasileStarynkevitch กฎ & ข้อเท็จจริงถูกเขียนลงบนซอร์สโค้ดซึ่งยังคงอยู่บนดิสก์ ทำไมคุณถึงเก็บไว้ในฐานข้อมูลแทน? Prolog หมายถึงอะไรไม่สามารถเก็บข้อมูลได้ ไม่ควรที่จะทำเช่นนั้น นั่นเป็นสาเหตุที่มีฐานข้อมูลอยู่ คุณช่วยอธิบายเพิ่มเติมได้ไหม

— 53777A

1

SQL จะใช้สำหรับฐานข้อมูลและ Prolog เป็นภาษาโปรแกรม นั่นคือประเด็นของฉัน

— Basile Starynkevitch

1

ด้านหนึ่งที่ไม่ได้กล่าวถึงคือการผลักดันให้ระบบ "เปิด" ในปี 1980 และ 1990 ในหลาย ๆ ที่ผู้จำหน่ายซอฟต์แวร์จะต้องให้การเข้าถึงมาตรฐานข้อมูลอุตสาหกรรมในฐานข้อมูลของพวกเขา ในเวลานั้น SQL เป็นมาตรฐานที่กำหนดไว้ซึ่งเป็นที่รู้จักและเข้าใจกันดี อารัมภบทเป็นเรื่องลึกลับและวิชาการ เมื่อคุณเริ่มรับอินเทอร์เฟซเช่น ODBC เพื่อเชื่อมต่อระบบได้อย่างง่ายดายไม่มีใครสนใจที่จะดูเทคโนโลยีอื่น ๆ

ฉันทำงานที่สถานที่แห่งหนึ่งในช่วงปลายยุค 80 ซึ่งมีฐานข้อมูล ISAM ที่ประสบความสำเร็จค่อนข้างมากซึ่งถูกบังคับโดยความกดดันของตลาด / ข้อบังคับการจัดหาเพื่อเพิ่มส่วนต่อประสาน SQL ให้

— dave
แหล่งที่มา