ฐานข้อมูลควรใช้ตรรกะทางธุรกิจเท่าใด

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

วิธีใดบ้างที่ดีกว่า

ข้อดีของการใช้ตรรกะทางธุรกิจในฐานข้อมูลที่ฉันนึกได้คือ:

• การรวมศูนย์ของตรรกะทางธุรกิจ
• ความเป็นอิสระของประเภทแอปพลิเคชันภาษาการเขียนโปรแกรมระบบปฏิบัติการ ฯลฯ
• ฐานข้อมูลมีแนวโน้มน้อยที่จะโยกย้ายเทคโนโลยีหรือปรับโครงสร้างครั้งใหญ่ (AFAIK);
• ไม่มีการทำงานซ้ำในการโยกย้ายเทคโนโลยีแอปพลิเคชัน (เช่น. NET เป็น Java, Perl เป็น Python เป็นต้น)

ข้อเสีย:

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

หมายเหตุ: ฐานข้อมูลที่ฉันกำลังพูดถึงนั้นเป็นฐานข้อมูลเชิงสัมพันธ์ฐานข้อมูลยอดนิยมเช่น SQL Server, Oracle, MySql เป็นต้น

ขอบคุณ!

ตรรกะทางธุรกิจไม่ได้อยู่ในฐานข้อมูล

หากเรากำลังพูดถึงแอพพลิเคชั่นหลายระดับดูเหมือนว่าชัดเจนว่าตรรกะทางธุรกิจซึ่งเป็นหน่วยสืบราชการลับที่ดำเนินธุรกิจโดยเฉพาะนั้นอยู่ใน Business Logic Layer ไม่ใช่ใน Data Access Layer

ฐานข้อมูลทำบางสิ่งได้ดีมาก:

1. พวกเขาจัดเก็บและดึงข้อมูล
2. พวกเขาสร้างและบังคับใช้ความสัมพันธ์ระหว่างหน่วยงานข้อมูลที่แตกต่างกัน
3. พวกเขามีวิธีการสอบถามข้อมูลสำหรับคำตอบ
4. พวกเขาให้การเพิ่มประสิทธิภาพ
5. พวกเขาให้การควบคุมการเข้าถึง

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

และแน่นอนอาจมีสิ่งต่าง ๆ ที่ดำเนินการในฐานข้อมูลเพื่อประสิทธิภาพและเหตุผลอื่น ๆ :

1. การปิดงวดบัญชี
2. จำนวนกระทืบ
3. กระบวนการแบทช์ทุกคืน
4. ไม่เกิน

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

ขั้นตอนการจัดเก็บทุกที่

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

แต่คุณมีความเสี่ยงอะไร

1. การล็อคอินของผู้ขาย
2. ความต้องการสำหรับนักพัฒนาที่มีทักษะพิเศษชุด
3. เครื่องมือการเขียนโปรแกรมสปาร์ตันโดยรวม
4. ข้อต่อซอฟต์แวร์ที่แน่นหนาที่สุด
5. ไม่มีการแยกความกังวล

และแน่นอนถ้าคุณต้องการบริการบนเว็บ (ซึ่งน่าจะเป็นที่ที่ทุกอย่างมุ่งไป) คุณจะต้องสร้างมันขึ้นมา

ดังนั้นการปฏิบัติทั่วไปคืออะไร?

ฉันจะบอกว่าวิธีการทั่วไปที่ทันสมัยคือการใช้ Mapper Object-Relational (เช่น Entity Framework) เพื่อสร้างคลาสที่สร้างแบบจำลองตารางของคุณ จากนั้นคุณสามารถพูดคุยกับฐานข้อมูลของคุณผ่านที่เก็บที่ส่งคืนคอลเลกชันของวัตถุสถานการณ์ที่คุ้นเคยกับนักพัฒนาซอฟต์แวร์ที่มีความสามารถ ORM สร้าง SQL ที่สอดคล้องกับตัวแบบข้อมูลของคุณและข้อมูลที่ร้องขอซึ่งเซิร์ฟเวอร์ฐานข้อมูลจะประมวลผลเพื่อส่งคืนผลลัพธ์แบบสอบถาม

มันใช้งานได้ดีแค่ไหน? ดีมากและรวดเร็วกว่าการเขียนขั้นตอนและมุมมองที่เก็บไว้ โดยทั่วไปจะครอบคลุมประมาณ 80% ของข้อกำหนดการเข้าถึงข้อมูลของคุณซึ่งส่วนใหญ่เป็น CRUD ครอบคลุมอะไรอีก 20% คุณเดา: ขั้นตอนการจัดเก็บซึ่ง ORM สำคัญทั้งหมดสนับสนุนโดยตรง

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

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

ฉันโต้แย้งข้อดีข้อเสียของคุณ

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

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

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

วิธีแก้ปัญหาทั่วไปสำหรับปัญหาข้างต้นคือการแยกลอจิกจากฟังก์ชั่นและผสานเข้ากับแบบสอบถาม ตอนนี้คุณมี encapsulation และตรรกะที่ซ้ำซ้อน

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

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

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

โดยทั่วไปแล้วฉันพบว่าฐานข้อมูลไม่ดีที่:

1. การคำนวณ
2. การวนซ้ำ (เหมาะสำหรับการตั้งค่า)
3. โหลดบาลานซ์
4. วจีวิภาค

ฐานข้อมูลดีที่:

1. การล็อคและปลดล็อค
2. รักษาข้อมูลและความสัมพันธ์ของพวกเขา
3. สร้างความมั่นใจในความซื่อสัตย์

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

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

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

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

ฉันทำงานใน บริษัท ต่าง ๆ 2 แห่งที่มีวิสัยทัศน์ที่แตกต่างกัน

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

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

ดังนั้นใช้ Stored Procedure ด้วยความระมัดระวังเมื่อจำเป็น

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

ดังที่คุณได้กล่าวไว้ T-SQL (หรือเทียบเท่าใน RDBMS ยอดนิยมอื่น ๆ ) ไม่ใช่สถานที่ที่ดีที่สุดในการเข้ารหัสตรรกะทางธุรกิจที่ซับซ้อน

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

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

http://en.wikipedia.org/wiki/Set_operations_(SQL)

ถ้าตรรกะทางธุรกิจเกี่ยวข้องกับการคำนวณบางประเภทมันอาจเป็นของนอกฐานข้อมูล / ขั้นตอนการจัดเก็บเนื่องจากฐานข้อมูลไม่ได้ออกแบบมาสำหรับการวนซ้ำและการคำนวณ

แม้ว่ากฎเหล่านี้จะไม่ยากและเร็ว แต่มันก็เป็นจุดเริ่มต้นที่ดี

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

ในสภาพแวดล้อมที่ไม่ใช่กฎข้อบังคับเมื่อคุณไม่สนใจมากเกี่ยวกับชุดระเบียนทั้งหมดและมีเพียงหนึ่งหรือสองแอปพลิเคชันที่เข้าถึงฐานข้อมูล

หลังจากผ่านไปไม่กี่ปีคำถามก็ยังสำคัญ ...

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

หลีกเลี่ยงการทิ้งดัมพ์ DBs

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

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

นิพจน์ (ตั้งค่า) แทนรหัสขั้นตอน

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

ใช้กลไกความสมบูรณ์ของข้อมูล DB

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

ขั้นตอนการจัดเก็บ?

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

ในขณะที่ด้านแอปพลิเคชันซึ่งรวมถึง ORM ที่สร้างขึ้น SQL จะไม่อยู่ในฐานข้อมูลอีกต่อไปซึ่งแตกต่างจาก Stored Procedure ฉันยังคงนับเป็นรหัสฐานข้อมูล เนื่องจากมันยังต้องการความรู้ SQL และฐานข้อมูล (ยกเว้น CRUD ที่ง่ายที่สุด) และหากใช้อย่างถูกต้องจะทำงานแตกต่างอย่างมากจากรหัสขั้นตอนที่มักสร้างด้วยภาษาโปรแกรมเช่น C # หรือ Java

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

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

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

บ่อยครั้งที่มีปัจจัยที่เกี่ยวข้องกับสภาพแวดล้อมที่ไม่ใช่ด้านเทคนิคจำนวนมากที่เกี่ยวข้องที่นี่ไม่มีคำตอบทั่วไปสำหรับคำถามนี้

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

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

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