เหตุใดฐานข้อมูล Web SQL จึงเลิกใช้แล้ว

ฉันกำลังสร้างแอพ Android ไฮบริด

ตอนแรกฉันตัดสินใจที่จะใช้ localStorage หลังจากใช้เวลา 2 วันฉันรู้ว่ามันแปลกมากและทำให้มันลดลง

จากนั้นฉันก็เก็บดรรชนี DB หลังจากใช้เวลาทั้งวันของวันนี้และได้รับผลลัพธ์ใน Google Chrome จริง ๆ แล้วมันไม่ได้ทำงานภายใน WebView ของแอพ android

และฉันไม่เคยใช้ฐานข้อมูล Web SQL เลยเพราะมันเลิกใช้แล้ว อย่างไรก็ตามมีสิ่งที่ฉันสังเกตเห็นว่า PhoneGap ยังคงใช้เบราว์เซอร์ของ Web SQL และ android ที่รองรับ

เพราะเหตุใด Web SQL จึงเลิกใช้ตั้งแต่แรก และเป็นความคิดที่ดีที่ฉันจะไปกับ Web SQL ตอนนี้หรือไม่

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

คุณรู้สึกแปลกใจกับ localStorage อะไร มันเป็นเพียงที่เก็บคู่คีย์ / ค่า ฉันอยากรู้ว่าคุณไม่ชอบอะไรเกี่ยวกับมันและปัญหาที่คุณพบเจอ ฉันใช้มันในโครงการและต้องการทราบถึงปัญหาที่คุณพบ

— jmq

@ oligofren หากคุณใช้ SQL ที่เกินกว่าจะเป็นแค่สมองง่าย ๆ ในเว็บ SQL คุณจะไม่สามารถแปลสิ่งนั้นเป็น localStorage และอื่น ๆ ได้อย่างแน่นอน

— Pacerier

แต่ช่วยตัวเองยุ่งยากของการสร้างชั้น abstraction (ซึ่งผมได้) และเพียงแค่ใช้ YDN-DB สำหรับตอนนี้dev.yathit.com/ydn-db/index.html มันจะใช้เทคโนโลยีที่ดีที่สุดสำหรับอุปกรณ์นั้น

— oligofren

คุณมักจะใช้เลเยอร์นามธรรมของการเรียงลำดับบางอย่าง นั่นคือการเขียนโปรแกรมและวิธีการที่คุณทำงานอย่างสอดคล้องโดยไม่คำนึงถึงข้อผิดพลาดในการใช้งานในเบราว์เซอร์ Dummy js โทรเกิน 5,000 ต่อ ms ดังนั้นเว้นแต่ผู้เขียน YDN-DB ได้ทำสิ่งที่โง่เขลาอย่างน่าขันคุณไม่ควรได้รับผลการทำงานที่ใดก็ได้ใกล้เคียง 100ms เช่น 1ms, สำหรับ 1: 1 ops, บนแพลตฟอร์มที่ไม่รองรับ IndexedDB ซึ่งในขณะนี้เป็นรุ่นที่เก่ากว่าเท่านั้น เบราว์เซอร์ปัจจุบันทั้งหมดรองรับ IndexedDB WebSQL เลิกใช้แล้ว และลองทำโปรไฟล์แบบง่าย ๆ ก่อนที่คุณจะ "เพิ่มประสิทธิภาพ" ห่างเทคโนโลยี :-)

— oligofren

@ oligofren คุณไม่มีจุดแสดงความคิดเห็นของฉัน ฉันไม่ได้พูดเกี่ยวกับค่าใช้จ่ายของฟังก์ชั่นหนึ่งที่เรียกอีกอย่างและ viceversa ฉันกำลังบอกว่าเมื่อคุณใช้เลเยอร์ abstraction db คุณกำลัง จำกัด ตัวเองให้เป็นชุดย่อยของรูปแบบการสืบค้น SQL ที่คุณสามารถใช้ได้โดยไม่ต้องทนทุกข์ทรมานกับการลงโทษประสิทธิภาพ คุณไม่สามารถปรับจูนได้เพราะไลบรารี่ทำเพื่อคุณโดยอัตโนมัติและไม่ทำให้ถูกต้องเสมอไป มันจะไม่เป็น 1 มิลลิวินาทีเว้นแต่ว่าคุณจะเก็บข้อมูลเพียง 1 แถวเท่านั้น

— Pacerier

คำตอบ:

เวอร์ชั่นย่อ: Web SQL ถูกคัดค้านเนื่องจากมาตรฐานมีความสำคัญจริง ๆ และการเปลี่ยน Web SQL ให้เป็นมาตรฐานที่เหมาะสมนั้นยากที่จะห้าม

เนื่องจากการใช้งานที่มีอยู่แล้วของ Web SQL นั้นโดยทั่วไปแล้วล้อมรอบ SQLite ความพยายามใด ๆ ในการกำหนดมาตรฐานของมันก็คือ "ทำสิ่งที่ SQLite ทำ" มันไม่ดีพอ มาตรฐานที่แท้จริงจะต้องมีอยู่ในตัวเองเพื่อกำหนดอินเทอร์เฟซและมุมกรณีและข้อยกเว้นตัวเองแทนที่จะชี้ไปที่การใช้งานที่มีอยู่ (โดยเฉพาะการใช้งานของบุคคลที่สามเช่น SQLite) มิฉะนั้นคุณจะเสี่ยงต่อการรับนิสัยใจคอของการใช้งานที่เฉพาะเจาะจงและยืนยันว่าพวกเขาเป็นมาตรฐาน จากสิ่งที่ฉันได้อ่าน W3C ชอบการนำมาตรฐานไปใช้งานที่เป็นอิสระหลายอย่างมาใช้เพื่อช่วยให้แน่ใจว่าสิ่งนี้จะเกิดขึ้น เนื่องจาก Web SQL นั้นเชื่อมโยงกับ SQLite ดังนั้นมันจะไม่เกิดขึ้น

บล็อกของ Mozillaให้รายละเอียดเพิ่มเติมเกี่ยวกับเหตุผลของพวกเขาโดยเฉพาะที่ไม่รองรับ Web SQL; เห็นได้ชัดว่าพวกเขาเป็นหนึ่งในเสียงหลักในการเลิกใช้งาน SQL ของเว็บ

คุณควรไปกับ Web SQL ตอนนี้หรือไม่ ฉันไม่ได้คาดหวังว่าผู้ขายที่ปัจจุบันสนับสนุน (เช่น Google และ Apple) ที่จะวางมันได้เร็ว ๆ นี้ แต่ IE และ Firefox จะไม่เพิ่มมันและเนื่องจากมันเลิกใช้แล้วทำไมต้องลงทุนกับมัน? (ตัวอย่างเช่นIdo Green ที่มี Google Developer Relations ไม่แนะนำให้ใช้)

— Josh Kelley
แหล่งที่มา

โพสต์นั้นโดย Ido นั้นเป็นขั้นพื้นฐานสุด ๆ และไม่แม้แต่จะขีดข่วนพื้นผิวว่าทำไมจึงควรใช้อย่างใดอย่างหนึ่ง ความจริงก็คือฐานข้อมูล noSQL ได้รับการออกแบบโดยคำนึงถึงขนาดใหญ่และนั่นไม่ได้ใช้กับฐานข้อมูลที่ทำงานบนคอมพิวเตอร์เครื่องเดียวของผู้ใช้ คุณอาจได้รับข้อดีบางประการที่เกี่ยวข้องกับข้อมูลขนาดใหญ่ แต่คุณสูญเสียสิ่งต่างๆเช่น JOIN ไม่มีทางที่ฉันจะสามารถพัฒนาส่วนขยายโครเมี่ยมโอเพนซอร์ซ "Plus for Trello" ได้ถ้าฉันต้องใช้ indexedDb (และฉันใช้ noSQL datastore ใน appengine) ดังนั้นฉันจึงไปที่เว็บ sql

— Zig Mandel

เนื่องจากคู่แข่งของ Google GMail MS-Outlook สามารถทำการค้นหาแบบเต็มและเนื่องจาก "กอดขยายขยายกำจัด" เป็นไปไม่ได้เมื่อมีการใช้ SQLite เพียงหนึ่งเดียว (MS) และเนื่องจาก Jonas Sicking (Mozilla) ไม่ชอบ SQL การเก็บค่าคีย์ด้วยอินเทอร์เฟซที่ซับซ้อนนั้นแน่นอนว่าดีกว่ามาก (หรือที่รู้จักในการใส่ยัติภังค์) โดยเฉพาะอย่างยิ่งเนื่องจากวัตถุ JavaScript ทุกตัวมีอาร์เรย์ที่เชื่อมโยงกันอยู่แล้ว และมาดูกันว่าการทำข้อมูลให้เป็นมาตรฐานความสมบูรณ์ของการอ้างอิงและการดำเนินงานแบบ set-revolting สำหรับคนที่ไม่เข้าใจ (ต้องการ) เข้าใจ SQL หรือที่ว่า "ผู้ใช้ไม่ต้องการ SQL"

— แน่ใจ

แดกดัน WebSQL เหมาะสำหรับการโต้ตอบกับ SQLite ถ้านั่นคือสิ่งที่คุณต้องการทำ (และไม่ต้องการ PRAGMA)

— Michael

โมซิลล่าจึงฆ่าโครงการและเทคโนโลยีที่มีประโยชน์อย่างยิ่งในหลาย ๆ สถานการณ์เพราะบางคนที่นั่นไม่ชอบและผู้คนปกป้องพวกเขา ทำไม? พวกเขาสามารถใช้ทั้ง IndexedDB และ WebSQL

— yoyo_fun

Safari 13 ได้ยกเลิกการสนับสนุน WebSQLที่มีเวอร์ชันก่อนหน้านี้แล้ว

— Thunderforge

คำตอบของ Josh Kelley เป็นคำตอบที่ดีที่สุดเท่าที่ฉันเคยพบมาเกี่ยวกับสาเหตุของงานมาตรฐานที่ต้องหยุด ที่กล่าวว่าฉันคิดว่ามีมุมมองเพิ่มเติมเพื่อพิจารณาเกี่ยวกับฐานผู้ใช้

แม้ว่าฉันจะไม่เห็นด้วยกับวิธีการของ Ido Green ในเรื่องนี้ ("นี่เป็นคำแนะนำสำหรับนักพัฒนาเว็บที่จะไม่ใช้เทคโนโลยีอย่างมีประสิทธิภาพอีกต่อไป") ...

ฉันเชื่อ (ในฐานะ vi4m ระบุไว้ในความคิดเห็นของบทความของ Ido Green):

เรา (นักพัฒนาซอฟต์แวร์) ยังสามารถใช้เทคโนโลยีนี้ได้ ไม่มีผู้จำหน่ายเบราว์เซอร์ที่ขอให้ลบเทคโนโลยีนี้หรือวางแผนที่จะลบ นักพัฒนาคือเสียงของเว็บ เรายังคงสามารถใช้งานได้บางที Mozilla จะเปลี่ยนใจ ;-)

และฉันจะเพิ่มวิธีการทางตรรกะอื่น: หากคุณกำลังพัฒนาสำหรับสภาพแวดล้อมมือถือ ... ¿สภาพแวดล้อมที่อยู่ในมือมากขึ้น? คำตอบ: iOS และ Android ... ดังนั้นถ้าทั้งสองสนับสนุน webSQL และเป้าหมายของคุณคือ MASSIVE MOBILE ไปเลย!

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

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

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

ฉันเชื่อว่าเจตนารมณ์ของ IndexedDB ในการเป็นทางเลือกที่มีความเป็นไปได้ที่กว้างและใหม่กว่านั้นเป็นแนวทางที่ดีอยู่เสมอ แต่อย่างใดมันก็คล้ายกับฉันสำหรับความต้องการในการพัฒนาซอฟต์แวร์ที่ต้องการติดตั้ง (แม้ว่าจะเป็นโซลูชันหลัก ในโลกที่มีแนวโน้มที่จะเชื่อมโยงกับมันดูเหมือนว่า A) เรื่องของการควบคุมและการครอบครองหรือ B) มุ่งเน้นไปที่การพัฒนาสัตว์ประหลาดสำหรับฝั่งไคลเอ็นต์ ... แต่สำหรับความต้องการเหล่านั้นมีอยู่ (ในโลกมือถือ) และซอฟต์แวร์ (ในโลก PC) ฉันเชื่อว่าเป้าหมายของ Webapps ควรอยู่ที่การขยายเว็บเป็นหลักไม่ว่าจะเป็นอุปกรณ์ใด

ฉันเชื่อว่าอินโฟกราฟิกที่ดีสามารถออกมาจากวิธีการนี้

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

โปรดทราบว่า Firefox รุ่นล่าสุดและ IE ไม่รองรับ WebSQL เลย

— ocodo

เท่าที่ฉันรู้พวกเขาไม่เคยสนับสนุน WebSQL คุณสามารถตรวจสอบได้ที่นี่: [ลิงค์] caniuse.com/#feat=sql-storage สิ่งเดียวที่ทำให้ฉันประหลาดใจคือ Opera Mini พวกเขากำลังทำตลาดแบบนี้ ยังไงก็ตามสำหรับฉันในฐานะนักพัฒนาคนเดียวที่สำคัญคือ iOS และ Android สำหรับ WebApps และ WebKit ที่ฉันเชื่อว่าเป็นกลไกของทั้งสองระบบ

— DavidTaubmann

อย่างไรก็ตามไม่มีการใช้มาตรฐานการจัดเก็บข้อมูลฝั่งไคลเอ็นต์โดยเบราว์เซอร์เชิงพาณิชย์ทั้งหมด: html5rocks.com/en/features/storage

— DavidTaubmann

Safari 13 ได้ยกเลิกการสนับสนุน WebSQLที่มีเวอร์ชันก่อนหน้านี้แล้ว ดังนั้น "ไม่มีผู้จำหน่ายเบราว์เซอร์ที่ขอให้ลบเทคโนโลยีนี้หรือวางแผนที่จะลบ" ไม่เป็นจริงอีกต่อไป

— Thunderforge

@ Thunderforge ขอบคุณสำหรับข้อมูล! ดีจริงๆที่จะรู้! คิดนิดหน่อยฉันไม่รู้ว่ามันจะแย่สำหรับ devs หรือแย่กว่าสำหรับ iOS เนื่องจากเครื่องมือนี้เสร็จสมบูรณ์และมีประโยชน์สำหรับเรามาหลายปีแล้ว เราอาจแนะนำให้ผู้ใช้ของเราไม่ใช้หรือซื้ออุปกรณ์ Mac หรือ iOS อีกต่อไปเว้นแต่ว่ามีบางคนจ่ายค่าใช้จ่ายสำหรับการทำโปรแกรมโครงการใหม่เพื่อทำดัชนี DB

— DavidTaubmann

ความจริงก็คือฝ่ายที่ให้ความช่วยเหลือไปถึงทางตันในทิศทางของมาตรฐาน ในระยะสั้นไม่มีใครเห็นด้วย

เว็บไซต์ W3C อธิบายสิ่งนี้

ข้อมูลจำเพาะมาถึงจุดด้อย: ผู้ดำเนินการที่สนใจทั้งหมดได้ใช้แบ็กเอนด์ SQL เดียวกัน (Sqlite) แต่เราต้องการการใช้งานอิสระหลายอย่างเพื่อดำเนินการตามเส้นทางมาตรฐาน

เว็บไซต์ WSC

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

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

— DavidTaubmann

สำหรับฉันเสียงที่ชอบ: พวกเขาไม่เห็นด้วยกับมันเพราะมันไม่อนุญาตให้ใช้คุณลักษณะเฉพาะของผู้ขาย

— แน่ใจ

ฉันเชื่อว่าเป็นความชอบเฉพาะของผู้ขายบางประโยคในประโยคถัดไประบุว่าการวิจัยยังดำเนินต่อไป ดังนั้นฉันจึงไม่แน่ใจว่าทุกฝ่ายพอใจกับสถานะปัจจุบัน ... "กลุ่มการทำงานของเว็บแอปพลิเคชั่นยังคงทำงานบนข้อกำหนดที่เกี่ยวข้องกับการจัดเก็บอีกสองรายการ: ที่เก็บข้อมูลบนเว็บและ API ฐานข้อมูลที่จัดทำดัชนี"

— htm11h