ฐานข้อมูลและการเขียนโปรแกรมเชิงฟังก์ชันมีความขัดแย้งกันหรือไม่?

ฉันเป็นนักพัฒนาเว็บมาระยะหนึ่งแล้วและเพิ่งเริ่มเรียนรู้การเขียนโปรแกรมเชิงฟังก์ชันบางอย่าง เช่นเดียวกับคนอื่น ๆ ฉันมีปัญหาสำคัญบางประการในการนำแนวคิดเหล่านี้ไปใช้กับงานวิชาชีพของฉัน สำหรับฉันเหตุผลหลักคือฉันเห็นความขัดแย้งระหว่างเป้าหมายของ FP ในเรื่องการไร้สัญชาติที่เหลืออยู่นั้นค่อนข้างขัดแย้งกับความจริงที่ว่างานพัฒนาเว็บส่วนใหญ่ที่ฉันทำนั้นมีความเชื่อมโยงกับฐานข้อมูลอย่างมากซึ่งมีข้อมูลเป็นศูนย์กลาง

สิ่งหนึ่งที่ทำให้ฉันเป็นนักพัฒนาที่มีประสิทธิผลมากขึ้นในด้าน OOP คือการค้นพบตัวทำแผนที่เชิงสัมพันธ์เชิงวัตถุเช่น MyGeneration d00dads สำหรับ. Net, Class :: DBI สำหรับ perl, ActiveRecord สำหรับทับทิม ฯลฯ สิ่งนี้ทำให้ฉันต้องอยู่ห่าง ๆ จากการเขียนแทรกและเลือกคำสั่งทั้งวันและมุ่งเน้นไปที่การทำงานกับข้อมูลได้อย่างง่ายดายเหมือนวัตถุ แน่นอนว่าฉันยังคงสามารถเขียนแบบสอบถาม SQL ได้เมื่อจำเป็นต้องใช้พลังงาน แต่อย่างอื่นมันก็เป็นนามธรรมเบื้องหลังอย่างดี

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

(หมายเหตุฉันไม่ได้ดู Weblocks หรือ Links อย่างใกล้ชิดมากนักฉันอาจเข้าใจผิดว่าใช้อย่างไร)

ดังนั้นคำถามคือสำหรับส่วนการเข้าถึงฐานข้อมูล (ซึ่งฉันเชื่อว่ามีขนาดใหญ่พอสมควร) ของเว็บแอปพลิเคชันหรือการพัฒนาอื่น ๆ ที่ต้องการส่วนต่อประสานกับฐานข้อมูล sql เราดูเหมือนจะถูกบังคับให้ใช้หนึ่งในเส้นทางต่อไปนี้:

1. อย่าใช้การเขียนโปรแกรมเชิงฟังก์ชัน
2. เข้าถึงข้อมูลด้วยวิธีที่น่ารำคาญและไม่เป็นนามธรรมซึ่งเกี่ยวข้องกับการเขียนลิงก์ SQL หรือโค้ดที่มีลักษณะคล้าย SQL ด้วยตนเอง
3. บังคับให้ภาษาที่ใช้งานได้ของเราเป็นกระบวนทัศน์หลอก OOP ดังนั้นจึงลบความสง่างามและความเสถียรของการเขียนโปรแกรมเชิงฟังก์ชันที่แท้จริงออกไป

เห็นได้ชัดว่าไม่มีตัวเลือกใดที่เหมาะ ได้พบวิธีหลีกเลี่ยงปัญหาเหล่านี้หรือไม่? มีปัญหาจริงๆหรือไม่?

หมายเหตุ: โดยส่วนตัวแล้วฉันคุ้นเคยกับ LISP มากที่สุดในส่วนหน้า FP ดังนั้นหากคุณต้องการยกตัวอย่างและรู้จักภาษา FP หลายภาษาเสียงกระเพื่อมน่าจะเป็นภาษาที่คุณต้องการ

ป.ล. : สำหรับปัญหาเฉพาะด้านอื่น ๆ ของการพัฒนาเว็บโปรดดูคำถามนี้

ก่อนอื่นฉันจะไม่บอกว่า CLOS (Common Lisp Object System) คือ "pseudo-OO" เป็น OO ชั้นหนึ่ง

ประการที่สองฉันเชื่อว่าคุณควรใช้กระบวนทัศน์ที่เหมาะกับความต้องการของคุณ

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

หากคุณมีความต้องการหลายอย่างผสมผสานกันให้ผสมผสานกระบวนทัศน์ของคุณ อย่า จำกัด ตัวเองให้ใช้เฉพาะมุมขวาล่างของกล่องเครื่องมือของคุณ

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

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

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

ฉันจะไม่พยายามเขียน T-SQL หรือใช้แนวคิดการออกแบบฐานข้อมูลเพื่อสร้างอินเทอร์เฟซผู้ใช้ของคุณทำไมคุณถึงพยายามใช้ภาษาอินเทอร์เฟซและแนวคิดการออกแบบเพื่อเข้าถึงฐานข้อมูลของฉัน เพราะคุณคิดว่า SQL ไม่สวย (หรือใหม่) พอ? หรือคุณไม่สบายใจกับมัน? เพียงเพราะบางอย่างไม่เข้ากับโมเดลที่คุณรู้สึกสบายใจที่สุดไม่ได้หมายความว่ามันไม่ดีหรือผิด หมายความว่ามันแตกต่างกันและอาจแตกต่างกันด้วยเหตุผลที่ถูกต้อง คุณใช้เครื่องมืออื่นสำหรับงานอื่น

คุณควรดูกระดาษ "Out of the Tar Pit" ของ Ben Moseley และ Peter Marks ที่มีอยู่ที่นี่: "Out of the Tar Pit" (6 กุมภาพันธ์ 2549)

เป็นคลาสสิกสมัยใหม่ที่ให้รายละเอียดเกี่ยวกับกระบวนทัศน์ / ระบบการเขียนโปรแกรมที่เรียกว่า Functional-Relational Programming แม้ว่าจะไม่เกี่ยวข้องโดยตรงกับฐานข้อมูล แต่จะกล่าวถึงวิธีการแยกปฏิสัมพันธ์กับโลกภายนอก (เช่นฐานข้อมูล) จากแกนการทำงานของระบบ

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

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

1. ภาษาที่ใช้งานได้ไม่ได้มีเป้าหมายที่จะอยู่ในสถานะไร้สัญชาติ แต่มีเป้าหมายเพื่อให้การจัดการของรัฐมีความชัดเจน ตัวอย่างเช่นใน Haskell คุณสามารถพิจารณา State monad เป็นหัวใจของสถานะ "ปกติ" และ IO monad เป็นตัวแทนของสถานะที่ต้องมีอยู่นอกโปรแกรม monads ทั้งสองนี้อนุญาตให้คุณ (a) แสดงถึงการกระทำที่มีสถานะอย่างชัดเจนและ (b) สร้างการดำเนินการที่มีสถานะโดยการเขียนโดยใช้เครื่องมือที่โปร่งใสอ้างอิง

2. คุณอ้างอิง ORM จำนวนหนึ่งซึ่งตามชื่อฐานข้อมูลนามธรรมเป็นชุดของวัตถุ แท้จริงแล้วนี่ไม่ใช่สิ่งที่ข้อมูลในฐานข้อมูลเชิงสัมพันธ์แสดงถึง! ตามชื่อมันแสดงถึงข้อมูลเชิงสัมพันธ์ SQL เป็นพีชคณิต (ภาษา) สำหรับจัดการความสัมพันธ์บนชุดข้อมูลเชิงสัมพันธ์และจริงๆแล้วค่อนข้าง "ใช้งานได้" ฉันนำสิ่งนี้มาพิจารณาว่า (ก) ORM ไม่ใช่วิธีเดียวในการแมปข้อมูลฐานข้อมูล (b) SQL เป็นภาษาที่ดีสำหรับการออกแบบฐานข้อมูลบางอย่างและ (c) ภาษาที่ใช้งานได้มักจะมีพีชคณิตเชิงสัมพันธ์ การแมปซึ่งแสดงให้เห็นถึงพลังของ SQL ในสำนวน (และในกรณีของ Haskell แบบพิมพ์ดีด)

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

ฉันไม่คิดว่าลักษณะไร้สัญชาติของภาษา fp เป็นปัญหาในการเชื่อมต่อกับฐานข้อมูล Lisp เป็นภาษาโปรแกรมที่ใช้งานได้จริงดังนั้นจึงไม่ควรมีปัญหาในการจัดการกับสถานะ และภาษาโปรแกรมที่ใช้งานได้จริงเช่น Haskell มีวิธีจัดการกับอินพุตและเอาต์พุตที่สามารถนำไปใช้กับการใช้ฐานข้อมูล

จากคำถามของคุณดูเหมือนว่าปัญหาหลักของคุณอยู่ที่การหาวิธีที่ดีในการแยกข้อมูลแบบบันทึกที่คุณได้รับกลับมาจากฐานข้อมูลของคุณไปสู่สิ่งที่เป็น lisp-y (lisp-ish?) โดยไม่ต้องเขียน SQL จำนวนมาก รหัส. ดูเหมือนว่าจะเป็นปัญหากับเครื่องมือ / ไลบรารีมากกว่าปัญหาเกี่ยวกับกระบวนทัศน์ภาษา หากคุณต้องการทำ FP ที่บริสุทธิ์บางทีการกระเพื่อมอาจไม่ใช่ภาษาที่เหมาะกับคุณ เสียงกระเพื่อมทั่วไปดูเหมือนจะเกี่ยวกับการบูรณาการแนวคิดที่ดีจาก oo, fp และกระบวนทัศน์อื่น ๆ มากกว่าเกี่ยวกับ fp บริสุทธิ์ บางทีคุณควรใช้ Erlang หรือ Haskell ถ้าคุณต้องการไปตามเส้นทาง FP ที่แท้จริง

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

คำเตือน: ฉันไม่ใช่ผู้เชี่ยวชาญด้านเสียงกระเพื่อม ฉันสนใจภาษาโปรแกรมเป็นส่วนใหญ่และเคยเล่นกับ Lisp / CLOS, Scheme, Erlang, Python และ Ruby นิดหน่อย ในชีวิตการเขียนโปรแกรมประจำวันฉันยังคงถูกบังคับให้ใช้ C #

หากฐานข้อมูลของคุณไม่ทำลายข้อมูลคุณสามารถทำงานกับมันในลักษณะการทำงานที่สอดคล้องกับค่าการเขียนโปรแกรม "ฟังก์ชันที่แท้จริง" โดยทำงานในฟังก์ชันของฐานข้อมูลทั้งหมดเป็นค่า

หากในขณะนั้น T ฐานข้อมูลระบุว่า "Bob ชอบ Suzie" และคุณมีฟังก์ชันที่ชอบซึ่งยอมรับฐานข้อมูลและผู้ชอบดังนั้นตราบใดที่คุณสามารถกู้คืนฐานข้อมูลได้ในขณะนั้น T คุณมีโปรแกรมที่ใช้งานได้จริงซึ่งเกี่ยวข้องกับฐานข้อมูล . เช่น

# Start: Time T
likes(db, "Bob")
=> "Suzie"
# Change who bob likes
...
likes(db "Bob")
=> "Alice"
# Recover the database from T
db = getDb(T)
likes(db, "Bob")
=> "Suzie"

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

นี่คือแนวคิดหลักที่อยู่เบื้องหลังDatomicเช่น

ไม่ใช่เลย. มีฐานข้อมูลประเภทหนึ่งที่เรียกว่า 'ฐานข้อมูลการทำงาน' ซึ่งMnesiaอาจเป็นตัวอย่างที่สามารถเข้าถึงได้มากที่สุด หลักการพื้นฐานคือการเขียนโปรแกรมเชิงฟังก์ชันมีการประกาศดังนั้นจึงสามารถปรับให้เหมาะสม คุณสามารถใช้การเข้าร่วมได้โดยใช้List Compiltyionsบนคอลเลกชันแบบถาวรและเครื่องมือเพิ่มประสิทธิภาพการสืบค้นสามารถกำหนดวิธีใช้การเข้าถึงดิสก์โดยอัตโนมัติ

Mnesia เขียนด้วยภาษาErlangและมีเว็บเฟรมเวิร์ก ( Erlyweb ) อย่างน้อยหนึ่งเว็บสำหรับแพลตฟอร์มนั้น Erlang นั้นขนานกันโดยเนื้อแท้กับโมเดลเธรดแบบไม่ใช้ร่วมกันดังนั้นในบางวิธีจึงใช้สถาปัตยกรรมที่ปรับขนาดได้

ฐานข้อมูลเป็นวิธีที่สมบูรณ์แบบในการติดตามสถานะใน stateless API หากคุณสมัครใช้งาน REST เป้าหมายของคุณคือการเขียนรหัสไร้รัฐที่โต้ตอบกับที่เก็บข้อมูล (หรือแบ็กเอนด์อื่น ๆ ) ที่ติดตามข้อมูลของรัฐอย่างโปร่งใสเพื่อไม่ให้ลูกค้าของคุณต้องทำ

แนวคิดของ Object-Relational Mapper ซึ่งคุณนำเข้าบันทึกฐานข้อมูลเป็นวัตถุจากนั้นแก้ไขข้อมูลนั้นสามารถใช้ได้และเป็นประโยชน์กับการเขียนโปรแกรมเชิงฟังก์ชันเช่นเดียวกับการเขียนโปรแกรมเชิงวัตถุ ข้อแม้ประการหนึ่งคือการเขียนโปรแกรมเชิงฟังก์ชันไม่ได้แก้ไขวัตถุที่อยู่ในตำแหน่ง แต่ API ฐานข้อมูลสามารถอนุญาตให้คุณแก้ไขบันทึกได้ ขั้นตอนการควบคุมลูกค้าของคุณจะมีลักษณะดังนี้:

• นำเข้าบันทึกเป็นวัตถุ (API ฐานข้อมูลสามารถล็อกบันทึก ณ จุดนี้)
• อ่านวัตถุและสาขาตามเนื้อหาตามที่คุณต้องการ
• รวมวัตถุใหม่ด้วยการปรับเปลี่ยนที่คุณต้องการ
• ส่งผ่านอ็อบเจ็กต์ใหม่ไปยังการเรียก API ที่เหมาะสมซึ่งอัพเดตเร็กคอร์ดบนฐานข้อมูล

ฐานข้อมูลจะอัปเดตบันทึกตามการเปลี่ยนแปลงของคุณ การเขียนโปรแกรมที่ใช้งานได้จริงอาจไม่อนุญาตให้กำหนดตัวแปรใหม่ภายในขอบเขตของโปรแกรมของคุณของคุณ แต่ API ฐานข้อมูลของคุณยังอนุญาตให้อัปเดตแบบแทนที่ได้

ฉันสบายใจที่สุดกับ Haskell เว็บเฟรมเวิร์ก Haskell ที่โดดเด่นที่สุด (เทียบได้กับ Rails และ Django) เรียกว่า Yesod ดูเหมือนว่าจะมี ORM หลายแบ็กเอนด์ที่ค่อนข้างเท่และปลอดภัย ดูบท Persistanceในหนังสือของพวกเขา

ฐานข้อมูลและการเขียนโปรแกรมเชิงฟังก์ชันสามารถหลอมรวมกันได้

ตัวอย่างเช่น:

Clojure เป็นภาษาโปรแกรมเชิงฟังก์ชันตามทฤษฎีฐานข้อมูลเชิงสัมพันธ์

               Clojure -> DBMS, Super Foxpro
                   STM -> Transaction，MVCC
Persistent Collections -> db, table, col
              hash-map -> indexed data
                 Watch -> trigger, log
                  Spec -> constraint
              Core API -> SQL, Built-in function
              function -> Stored Procedure
             Meta Data -> System Table

หมายเหตุ: ใน spec2 ล่าสุด spec จะเหมือน RMDB มากกว่า ดู: spec-alpha2 wiki: Schema-and-select

ฉันสนับสนุน: การสร้างแบบจำลองข้อมูลเชิงสัมพันธ์ที่ด้านบนของแฮชแมปเพื่อให้ได้ข้อดีของ NoSQL และ RMDB ร่วมกัน นี่คือการนำ posgtresql ไปใช้แบบย้อนกลับ

เป็ดพิมพ์ดีด: ถ้าดูเหมือนเป็ดและต้มตุ๋นเหมือนเป็ดก็ต้องเป็นเป็ด

หากโมเดลข้อมูลของ clojure เช่น RMDB สิ่งอำนวยความสะดวกของ Clojure เช่น RMDB และการจัดการข้อมูลของ clojure เช่น RMDB clojure จะต้องเป็น RMDB

Clojure เป็นภาษาโปรแกรมเชิงฟังก์ชันตามทฤษฎีฐานข้อมูลเชิงสัมพันธ์

ทุกอย่างคือ RMDB

ใช้โมเดลข้อมูลเชิงสัมพันธ์และการเขียนโปรแกรมตาม hash-map (NoSQL)