อะไรคือข้อโต้แย้งต่อต้านหรือสำหรับการใส่ตรรกะของแอปพลิเคชันลงในเลเยอร์ฐานข้อมูล? [ปิด]


45

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

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

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

แก้ไขคำถามนี้รวมอยู่ในdba.seจากมุมมอง DBAs ในฐานะ programmers.se & dba.se มีกลุ่มเป้าหมายและอคติที่แตกต่างกันผู้อ่านในอนาคตอาจต้องการตรวจสอบคำตอบทั้งสองชุดก่อนที่จะตัดสินใจเลือกสิ่งที่ดีที่สุดสำหรับพวกเขา


13
ฉันยังสนใจถ้าผู้เสนอให้วางตรรกะของแอปลงในเลเยอร์ฐานข้อมูลสามารถให้วิธีการทดสอบหน่วยที่ตรรกะของแอป
Chris Buckett

@ChrisB: สำหรับ Oracle มีplunit.com/index.htm
Tony Andrews

10
โปรดใช้เหตุผลทางธุรกิจไม่ใช่ตรรกะของแอปพลิเคชัน - เป้าหมายควรเป็นโดเมนปัญหาไม่ใช่ตัวเลือกเทคโนโลยี!
Phil Lello

1
@ChrisB: ฉันสามารถเดิมพันได้ - เติมข้อมูลลงในตาราง (คุณต้องสร้างคลาสจำลองในเลเยอร์แอป) จากนั้นเรียก SP โดยอัตโนมัติพร้อมสคริปต์ สิ่งทั้งหมดสามารถเขียนเป็นสคริปต์ของคำสั่ง SQL ล้างและตั้งค่าตามที่มันไป นี่คือลิงค์สำหรับเครื่องมือทดสอบ SQL 3 หน่วย: toadworld.com/BLOGS/tabid/67/EntryId/67/…
gbjbaanb

ฉันเขียนความคิดของฉันเกี่ยวกับเรื่องนี้ในบล็อกของฉันเมื่อเร็ว ๆ นี้
ออกุสตุส

คำตอบ:


38

เหนือหัวของฉันข้อดีของการวางตรรกะในเลเยอร์แอปพลิเคชัน

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

5
เราสามารถเพิ่มความสามารถในการ frigging ที่มาของการควบคุมวัตถุขณะที่พวกมันถูกดัดแปลงได้หรือไม่? บางทีมันอาจเป็นแค่ความรู้สึกส่วนตัวของฉัน ... (ใช่ฉันเห็นได้ชัดว่าไม่สามารถทำได้ ... )
jcolebrand

6
Re: 4. เยี่ยม! ใช้ Let 's ตรรกะ VB ใน app Solaris Java ของฉัน ... โอ้แขวนบน ...
ฟิล Lello

11
ฟิลเยี่ยมมาก! มาใช้ตรรกะ Oracle ของคุณในแอพ SQL Server ของฉัน ... โอ้มาแฮงค์ ...
เครก

9
@Craig ความจริงก็คือองค์กรเปลี่ยนผู้จำหน่ายฐานข้อมูลบ่อยกว่าที่พวกเขาเปลี่ยนแอพพลิเคชั่นหรือภาษา อย่างไรก็ตามประเด็นของฉันก็ยิ่งมากกว่านั้นไม่ใช่ข้อได้เปรียบของ app vs db ไม่ใช่ว่า db นั้นเหนือกว่าที่นี่ มีทั้ง
ข้อดี

1
@ jcolebrand - ถ้าคุณกำลังพัฒนาฐานข้อมูลVS 2010 จะเป็นระเบิด ฉันเปลี่ยนกลุ่มของเราจาก SSMS เพื่อ VS สำหรับการทำงานการพัฒนาและการมองไปที่การนำสิ่งนี้ TDDนั่นคือทั้งหมดที่โกรธกับ devs มันเป็นการลงทุนที่คุ้มค่ากับเวลาสำหรับร้านค้าใด ๆ ที่มีงานพัฒนาฐานข้อมูลที่สำคัญ
Nick Chammas

11

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

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


4
"ไม่ตรงไปตรงมากับรหัสแอปพลิเคชัน" ทำไมไม่
NimChimpsky

@ นิมิต - หากฉันทำผิดมันเกี่ยวข้องกับโครงการฐานข้อมูลมากกว่า "แก้ไขและเรียบง่าย" คุณจะได้รับเมื่อการควบคุมแหล่งรวมเข้ากับ IDE ของคุณ
ChrisF

1
ฉันเดาทำให้คุณสามารถทำการเปลี่ยนแปลงฐานข้อมูลของคุณโดยไม่ก่อให้มันควบคุมรุ่น แต่คุณไม่สามารถจริงๆทำเช่นเดียวกันกับรหัส ...
Jaco Pretorius

5
@Jaco No แต่คุณสามารถเรียกใช้ / ปล่อยรหัสได้โดยไม่ต้องใส่ใน SCM การจัดการปล่อยเลอะเทอะคือการจัดการปล่อยเลอะเทอะสิ่งที่เทคโนโลยีที่คุณใช้
Phil Lello

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

8

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


การขยายขนาดของทีมนั้นยากพอโดยไม่รวมถึงคนที่ไม่ให้ความร่วมมือ (ไม่แน่ใจว่าทำไมบุคคลที่รับผิดชอบอนุญาตทางเลือกนี้) หรือต้องการ 'เซสชั่นการสอน' ของพวกเขาเอง
JeffO

1
ฉันเดาว่าเป็นเพราะพวกเขานั่งรอบ ๆ โดยไม่ทำอะไรเลยดังนั้นเมื่อคุณให้บางสิ่งบางอย่างแก่พวกเขาเพื่อทบทวนพวกเขาต้องการให้ความสนใจกับนมจริง ๆ บางทีมันอาจจะเป็นเพียงฉัน ...
Jaco Pretorius

5
@Jeff O ทำไม DBA ไม่เกี่ยวข้องกับการออกแบบ DBA มีแนวโน้มที่จะรู้มากขึ้นเกี่ยวกับการเพิ่มประสิทธิภาพฐานข้อมูลมากกว่านักพัฒนาคนอื่นและควรได้รับการปฏิบัติในฐานะเป็นส่วนหนึ่งของทีม
Phil Lello

8
@Phil Lello: เนื่องจากนักพัฒนาซอฟต์แวร์ส่วนใหญ่เป็นคนที่หยิ่งยะโสที่คิดว่าพวกเขาสามารถเรียนรู้ได้ด้วยตนเอง นี่คือเหตุผลที่ฐานข้อมูลจำนวนมากเป็นกองขยะ
เพียงความคิดเห็นที่ถูกต้องของฉัน

2
เสียงเหมือน dba ของคุณสร้างรั้วรอบ ๆ เขตที่วางทุ่นระเบิดเพื่อให้คุณปลอดภัย จะขอบคุณ!
James Anderson

7

การใส่ตรรกะของแอปพลิเคชันลงใน DB ดูเหมือนเป็นความคิดที่ไม่ดี OTOH วางตรรกะในฐานข้อมูลที่เป็นส่วนหนึ่งของการบำรุงรักษาสถานะ DB (เช่นทริกเกอร์ / sprocs เพื่อปรับปรุงตาราง de-normalized) เป็นข้อเสนอที่แตกต่างกันมาก


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


นี้. คุณต้องการให้ฐานข้อมูลของคุณมีความยืดหยุ่น ดังนั้นตรรกะที่เชื่อมโยงกับข้อมูลของคุณควรอยู่ที่นั่น
Arkh

6

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

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

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

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


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

5

longish ดูสรุปที่ด้านล่าง

RDBMS

RDBMS หมายถึงระบบการจัดการฐานข้อมูลเชิงสัมพันธ์ มันเป็นระบบในการจัดการฐานข้อมูลเชิงสัมพันธ์ ข้อมูลถูกเก็บไว้ที่นั่น ข้อมูล. ไม่ได้พูดถึงตรรกะทางธุรกิจ

กระบวนการทางธุรกิจ

ตรรกะทางธุรกิจหมายถึงอะไรจริงเหรอ? สำหรับฉันมันเป็นคำอธิบายของกระบวนการทางธุรกิจในแง่ตรรกะ

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

ให้ฉันสวมหมวกธุรกิจและอธิบายว่าธุรกิจมีความหมายที่นี่ สำหรับบางคนนี่อาจเป็นเรื่องที่น่าประหลาดใจ

ธุรกิจ

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

ทางอ้อมอย่างรวดเร็ว: คุณต้องการ 40 ล้านหมุดใน 2 วันคุณจะไม่ได้รับคำสั่งจากคนในอินเทอร์เน็ตด้วยบัญชี paypal ไม่ว่าราคาของเขาจะถูกกว่าผู้ขายปกติของคุณเท่าใด

ความรู้กระบวนการ

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

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

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

แอปพลิเคชันลอจิก

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

ข้อมูล

ฉันยังกล่าวด้วยว่าข้อมูลนั้นมีประสิทธิภาพมากกว่าแอปพลิเคชันดังนั้นความพยายามในการทำให้มาตรฐานของข้อมูลไม่ควรใช้เฉพาะแอพพลิเคชั่นและไม่ใช่แม้แต่เฉพาะธุรกิจ แต่ควรเป็นเรื่องทั่วไป คุณเก็บรหัสรัฐหรือไม่ คุณควรใช้ INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) เนื่องจากเป็นแบบพกพาข้ามธุรกิจ นอกจากนี้ยังช่วยให้แอปพลิเคชันหลายตัวจัดการข้อมูลได้ง่ายขึ้น

NoSQL?

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

รหัสจริง

ไม่คุณต้องถือว่าฐานข้อมูลเป็นที่เก็บข้อมูลทั่วไปสำหรับหลายแอปพลิเคชันทั้งในปัจจุบันและอนาคต ตอนนี้เรามาถึงปมการโต้แย้งของฉัน กระบวนการทางธุรกิจเปลี่ยนแปลงไปด้วยความหลากหลายของตลาดการเมืองและแฟชั่น บ่อยครั้งที่พวกเขาเปลี่ยนเร็วกว่าตัวแปลงสัญญาณที่สามารถจัดการได้ด้วยภาษาคอมพิวเตอร์ระดับวิทยาศาสตร์ (Java, C #, C ++ ฯลฯ ) และจบลงด้วยการเขียนใน VBA ใน excel spreadsheets ในแผนกบัญชีหรือการตลาด (และเฉพาะในกรณีที่ไม่สามารถแสดงใน vlookups แฟนซี ... )

การย่อยสลายฐานข้อมูล

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

สรุป

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

ข้อแม้

ฉันแชร์ dba-ing เรียบร้อยแล้วและฉันได้อ่านคำตอบที่ dba.se แต่จริงๆแล้วสิ่งที่พวกเขากำลังพูดถึงก็คือเรื่องความถูกต้องของข้อมูลและปัญหาด้านประสิทธิภาพ ฉันเห็นด้วยอย่างสมบูรณ์ว่าผู้ที่สัมผัสข้อมูลองค์กรควรรู้ว่าพวกเขากำลังทำอะไรไม่ว่าจะเป็น dba หรือโปรแกรมเมอร์หรือนักวิเคราะห์อาวุโสของ SAS ที่มีสิทธิ์เข้าถึงแบบอ่าน / เขียน

ฉันยังกล่าวว่าพวกเขาแนะนำให้รู้จัก coders รู้ SQL ฉันเห็นด้วย. เป็นภาษาเขียนโปรแกรมคอมพิวเตอร์ดังนั้นฉันจึงไม่เห็นว่าทำไมโปรแกรมเมอร์คอมพิวเตอร์จึงไม่ต้องการที่จะรู้

ต่อมาหลังจากคิดเกี่ยวกับมัน

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


5
ฉันไม่ปฏิบัติตามจุดลดฐานข้อมูล โดยการใส่ตรรกะในฐานข้อมูลคุณจะต้องเปลี่ยนกฎในที่เดียว (ฐานข้อมูล) มีแอปพลิเคชั่นไม่มากที่เขียนในหลายภาษา อย่างไรก็ตาม +1 สำหรับการตอบสนองที่ดี
Phil Lello

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

1
ข้อมูลนั้นดีเท่าแอปพลิเคชันเท่านั้น ขยะในถังขยะหมดแล้ว หากคุณมีคนที่คร่ำครวญมีความแม่นยำน้อยกว่าการเขียนแอพมีน้อยมากที่คุณสามารถทำได้ในฐานะ DBA เพื่อแก้ไขขยะ
Christopher Mahan

1
@ChristopherMahan มีหลายสิ่งที่คุณสามารถทำได้ในการออกแบบฐานข้อมูลเพื่อป้องกันข้อมูลที่ไม่ดี
HLGEM

4

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

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

ผู้ใช้หนึ่งรายในการแลกเปลี่ยน DBA สแต็กระบุสิ่งนี้ ...

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

ฟอร์จูน 500 ครั้งล่าสุดที่ฉันทำงานที่มีแอพพลิเคชั่นเขียนอย่างน้อย 25 ภาษาที่ส่งผลกระทบต่อฐานข้อมูล OLTP ของพวกเขา บางส่วนของโปรแกรมเหล่านั้นย้ายไปผลิตในปี 1970

... ตามด้วยความเชื่อของเขาว่าสิ่งนี้เป็นการบ่งบอกถึงการละเมิดหลักการ DRY

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

ฐานข้อมูล OLTB ของพวกเขาให้ข้อมูลที่น่าเชื่อถือและมีประสิทธิภาพแก่แอปพลิเคชั่นมากกว่า 25+ มานานหลายทศวรรษ! ที่น่าตื่นตาตื่นใจ! (ทางที่จะไป!)

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

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


พูดได้ดี. ข้อผิดพลาดขนาดใหญ่ของฉันที่มีขั้นตอนการจัดเก็บอ้างอิงความสมบูรณ์และอื่น ๆ คือการจัดการข้อผิดพลาด บ่อยครั้งที่ผู้ใช้ปลายทางจะได้รับการนำเสนอด้วย "ข้อผิดพลาดวัตถุคลุมดิน YYYY ขั้นตอน XXXXXX - sqlcode -666" ซึ่งส่งผลให้เสียเวลาโทรสนับสนุน เมื่อ "ลูกค้าไม่มีรหัสภาษี" ง่าย ๆ จะช่วยให้ผู้ใช้แก้ไขปัญหาและทำงานของเขาต่อไป
James Anderson

3

แอปพลิเคชันผู้ไม่เชื่อเรื่องพระเจ้าของฐานข้อมูลต้องการตรรกะออกจากฐานข้อมูล มันยากมากที่จะสร้างและรักษารหัสให้กับผู้ให้บริการฐานข้อมูลที่แตกต่างกัน


3
มันยากมากที่จะสร้างคลังข้อมูลผู้ไม่เชื่อเรื่องพระเจ้าของแอปพลิเคชันด้วยตรรกะตามแอปพลิเคชัน
Phil Lello

3

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

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

ตรวจสอบให้แน่ใจว่ามีการตั้งค่าฟิลด์การดูแลรักษาบ้านเมื่อแถวถูกแทรกและอัพเดตเป็นความรับผิดชอบของ DBA ทริกเกอร์จะถูกใช้

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

มันเป็นเรื่องของการสื่อสารระหว่างทีมและเรื่องของการตระหนักถึงข้อดีข้อเสียในแต่ละโอกาส

ความคิดเห็นของฉันคือ: อย่าทำให้ตรรกะการใช้งานลึกเกินไปในฐานข้อมูล


2

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

คุณใส่ตรรกะในฐานข้อมูลเพราะคุณต้องการที่จะสามารถแก้ไขตรรกะนั้นได้อย่างง่ายดาย

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

คุณสามารถติดตามสิ่งนี้ใน VCS แบบใช้ไฟล์เพิ่มเติม แต่แล้วประโยชน์ของฐานข้อมูลคืออะไร


รหัสฐานข้อมูลทั้งหมดควรอยู่ในการควบคุมแหล่งที่มาในทุกกรณี มันเป็นรหัสเหมือนคนอื่น ๆ
HLGEM

1

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.