กระบวนงานที่เก็บไว้ละเมิดการแยกแบบสามระดับหรือไม่

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

ฉันคิดว่าโลกจะเป็นสถานที่ที่น่ากลัวมากโดยไม่มีขั้นตอนการจัดเก็บ

พวกเขาละเมิดการแยกแบบสามระดับจริง ๆ หรือไม่

เพื่อนร่วมงานของคุณกำลังสร้างความสับสนให้กับสถาปัตยกรรมด้วยการใช้งาน

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

ลองดูที่แอพพลิเคชั่นสามชั้นที่สองระดับได้ถูกนำไปใช้ในฐานข้อมูล:

• ข้อมูลเงินกองทุนชั้นที่: ประกอบด้วยตารางฐานข้อมูลเข้าถึงได้โดยใช้การดำเนินงานตารางมาตรฐานสี่ ( INSERT, UPDATE, DELETEและSELECT)
• ชั้นตรรกะ:ประกอบด้วยขั้นตอนการจัดเก็บที่ใช้ตรรกะทางธุรกิจเท่านั้นและเข้าถึงชั้นข้อมูลโดยใช้วิธีการที่ระบุไว้ข้างต้นเท่านั้น
• Presentation Tier: ประกอบด้วยเว็บเซิร์ฟเวอร์ที่ใช้รหัสที่เข้าถึงระดับตรรกะโดยทำการโทรตามขั้นตอนที่เก็บไว้เท่านั้น

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

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

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

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

คำแนะนำของ Atwood ในปี 2004 ยังคงเป็นจริงในปัจจุบันมีเพียงเราเท่านั้นที่ได้รับประโยชน์จาก ORM เช่นกัน

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

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

สรุปโดยย่อ:ขึ้นอยู่กับการใช้งานของขั้นตอนการจัดเก็บและข้อกำหนดทางธุรกิจของคุณ

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

การพูดเกี่ยวกับคำศัพท์โดยทั่วไปชั้นเหล่านี้อธิบายว่า:

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

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

ประโยชน์ของการออกแบบสามระดับคือ:

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

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

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

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

ในความคิดของฉันมีสองปัญหาสำคัญกับการสร้างตรรกะทางธุรกิจในฐานข้อมูล:

1. โค้ดและไลบรารี: คุณจะพบโปรแกรมเมอร์น้อยลงที่สามารถเขียนโปรแกรมใน SQL, PL / SQL, TSQL เป็นต้นใน C #, Java และอื่น ๆ ภาษาการเขียนโปรแกรมยังมีข้อดีของ IDE ที่ยอดเยี่ยม, ไลบรารีและกรอบงานที่ยอดเยี่ยม

2. scalability แนวนอน: วิธีเดียวที่คุณสามารถขยายระบบของคุณคือการเปลี่ยนเซิร์ฟเวอร์จริงซึ่งฐานข้อมูลที่มีประสิทธิภาพมากกว่าซึ่งค่อนข้างแพง (เซิร์ฟเวอร์ที่มี RAM 64 GB) ฐานข้อมูลเชิงสัมพันธ์มีขนาดที่แย่มากในแนวนอนและแม้กระทั่งค่าใช้จ่ายที่มากขึ้น ในขณะที่ด้วยตรรกะทางธุรกิจในเซิร์ฟเวอร์ที่สร้างขึ้น OO คุณสามารถปรับขนาดแนวนอนได้ค่อนข้างดีโดยการวางเซิร์ฟเวอร์ไว้ในหลาย ๆ โหนด (ใน Java แอพพลิเคชันเซิร์ฟเวอร์จำนวนมากสนับสนุนสิ่งนี้)

เรามีการถกเถียงกันในสำนักงานของเราหลายครั้งย้อนหลังฉันชอบการพัฒนาฐานข้อมูลฉันมีมุมมองต่อไปนี้

1. หากคุณใช้ฐานข้อมูล Oracle คุณควรใช้ PL / SQL ให้มากที่สุดเพราะ บริษัท ที่ลงทุนจะติดอยู่กับ oracle อย่างน้อย 10 ปีนับจากนี้ ขณะที่อยู่ในแอปพลิเคชันเมื่อวานนี้คุณกำลังใช้ Oracle Forms ในวันนี้. เว็บฟอร์มสุทธิจากนั้น MVC จากนั้นในวันพรุ่งนี้คุณจะใช้ angularjs และเพียงแค่ต้องการ restfull apis หากตรรกะสูงสุดของคุณอยู่ในฐานข้อมูลคุณสามารถย้ายไปยังเทคโนโลยีส่วนหน้าใหม่ได้อย่างง่ายดาย
2. การพัฒนาฐานข้อมูลนั้นรวดเร็วและมีประสิทธิภาพอย่างชาญฉลาด เพียงแค่ให้โอกาสคุณ ในโครงการของเรามีผู้พัฒนาแอพพลิเคชั่น 7 คนและผู้พัฒนาฐานข้อมูลหนึ่งคนและ 80% ของตรรกะอยู่ในฐานข้อมูล
3. หากคุณใช้ oracle คุณสามารถใช้ยูทิลิตี้เพื่อแปลงโพรซีเดอร์ฐานข้อมูลของคุณเป็น Res เต็ม API ได้โดยตรง

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