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

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

ฉันไม่พบการสนทนาเกี่ยวกับ dba ในเรื่องนี้แล้วและโพสต์ต้นฉบับบอกว่ามันทั้งหมดดังนั้น:

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

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

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

NB ฉันไม่ใช่ OP สำหรับคำถามนั้น แต่ทิ้งถ้อยคำดั้งเดิมไว้เหมือนเดิม

ความคิดที่หลากหลาย ...

รหัสฐานข้อมูลของคุณจะอยู่ได้นานกว่าเทคโนโลยีไคลเอ็นต์แอปพลิเคชันของคุณ คิดถึง ADO.NET -> Linq -> EF รวมถึง ORM ที่หลากหลาย ในขณะที่คุณยังคงสามารถเรียกใช้รหัส SQL Server 2000 จากสหัสวรรษสุดท้ายกับเทคโนโลยีไคลเอ็นต์ข้างต้นทั้งหมด

คุณยังมีปัญหาไคลเอนต์หลาย: ฉันมี. net, java และ Excel นั่นคือตรรกะแอปพลิเคชัน 3 ชุด

"ตรรกะทางธุรกิจ" ไม่ควรสับสนกับ "ตรรกะความสมบูรณ์ของข้อมูล" หากคุณมีลูกค้าที่เริ่มต้นการทำธุรกรรมและทำการตรวจสอบที่แตกต่างกันนั่นคือการโทร db จำนวนมากและการทำธุรกรรมที่ยาวนาน

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

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

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

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

อัตราต่อรองคืออะไร?

นี่ไม่ใช่ซิงเกิ้ลที่ใหญ่ที่สุด " อย่าพูดซ้ำตัวเอง " บนโลกใบนี้หรือ

ฉันย้ายคำตอบเก่า ๆ ของฉันไปแล้วโดยไม่ต้องมีการแก้ไขจากโปรแกรมเมอร์

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

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

ข้อเสียคือ: - นักพัฒนาถูกคุกคามเมื่อผู้ใช้พึ่งพานักพัฒนาน้อยลงสำหรับรายงานที่กำหนดเอง - นักพัฒนาจำเป็นต้องเรียนรู้ภาษาการเขียนโปรแกรมอื่น

ไม่ควรคำนึงถึงนักพัฒนาที่มีทักษะ

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

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

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

…
3. เพิ่มความสมบูรณ์ / ตรวจสอบข้อ จำกัด ไปยังฐานข้อมูลพื้นฐานด้วยรหัสที่ซับซ้อนมากขึ้นนำมาใช้ในภาษาขั้นตอนการจัดเก็บของฐานข้อมูล จากจุดนี้เราจะได้สถานที่ส่วนกลางหนึ่งแห่งเพื่อบำรุงรักษาและเราได้รับการบังคับใช้อย่างสมบูรณ์ของกฎแม้สำหรับแอปพลิเคชันที่เราไม่ทราบ! เราได้รับหนึ่งภาษาเพื่อแสดงกฎเกณฑ์ทางธุรกิจตลอดทั้งแอปพลิเคชันและวงจรชีวิตทั้งหมดเนื่องจากภาษามีการเปลี่ยนแปลงบ่อยกว่าฐานข้อมูล และมันทำงานบนระบบที่มีภารกิจสำคัญเป็นแอพพลิเคชั่นที่สำคัญที่สุด ข้อผิดพลาดได้รับการจัดการโดยรหัสที่มีอยู่ซึ่งจัดการข้อผิดพลาดของฐานข้อมูลในแอปพลิเคชันเหล่านั้น ยังคงมีความเสี่ยงที่แอปพลิเคชั่นอาจทำลายได้ แต่ในสามสถานการณ์นี้เป็นขั้นต่ำและเฉพาะแอปพลิเคชันที่เสียหายเท่านั้นที่ต้องการการแก้ไขใด ๆ ไม่ใช่ทั้งหมด (และกลไก SP / ฐานข้อมูลส่วนใหญ่จะอนุญาตให้มีข้อยกเว้นสำหรับแอปพลิเคชันเดียวหากจำเป็นจริงๆ) คิดว่าสิ่งนี้ไม่สำคัญสำหรับไซต์ greenfield หรือ บริษัท ขนาดเล็กของคุณใช่ไหม ถ้าธุรกิจของคุณประสบความสำเร็จในเวลา 30 ปีคุณจะขอให้คุณได้ใส่ใจกับภูมิปัญญาของฉัน!

…บาง [คัดค้าน] ฉันมักจะได้ยิน:

• เป็นการยากที่จะควบคุมเวอร์ชันรหัส SP ที่ปรับใช้ในฐานข้อมูล ฉันไม่คิดว่านี่เป็นเรื่องจริงยิ่งไปกว่าการบอกว่าเป็นการยากที่จะควบคุมเวอร์ชันโค้ด Java ที่ปรับใช้ในแอพเซิร์ฟเวอร์ซึ่งกล่าวได้ว่ามันไม่ยากเลยมันเป็นเรื่องธรรมดา และใน Ruby-land หนังสือทั้งหมดเขียนขึ้นเกี่ยวกับวิธีนำโค้ดของคุณจากสภาพแวดล้อมการพัฒนาไปสู่การผลิตซึ่งเป็นสิ่งที่ชุมชนภาษาอื่นไม่สามารถแก้ไขได้ แต่เวอร์ชันที่ควบคุมขั้นตอนการจัดเก็บนั้นยากเกินไป
• ขั้นตอนการจัดเก็บยากที่จะทดสอบ นี่เป็นสิ่งที่แปลก สำหรับการเริ่มต้น SP จะถูกพิมพ์อย่างมาก คอมไพเลอร์จะบอกคุณว่ามีเส้นทางรหัสเข้าหรือออกที่ไม่สมเหตุสมผลและอย่างน้อยใน Oracle จะคำนวณการอ้างอิงทั้งหมดสำหรับคุณ นั่นคือชุดทดสอบทั่วไปหนึ่งชุดที่คุณอาจจำเป็นต้องใช้ใน Ruby กำจัดค้างคาว ในการทดสอบรหัส OO ต้องมีการเยาะเย้ยเพื่อบังคับวัตถุเข้าสู่สถานะภายในที่ต้องการเพื่อแสดงสถานการณ์จำลองการทดสอบ - การตั้งค่าข้อมูลทดสอบแตกต่างกันอย่างไร มีโปรดิวเซอร์ TAP สำหรับ PL / SQL และเครื่องมืออื่น ๆ มี debuggers และ profilers ด้วย
• ภาษาของกระบวนงานที่เก็บไว้ไม่ใช่ภาษาที่มีคุณลักษณะครบถ้วน เราไม่ได้พยายามเขียนแอปพลิเคชั่นทั้งหมดในขั้นตอนการจัดเก็บ! ภาษา SP เฉพาะส่วนใหญ่มีโครงสร้างที่ทันสมัยทั้งหมดที่คุณคาดหวังและอย่างน้อยใน Oracle คุณสามารถใช้ Java Stored Procedure กับคุณสมบัติภาษาทั้งหมดที่นักพัฒนา OO คุ้นเคยหรือเป็นโพรซีเดอร์ภายนอกในภาษาใดก็ได้ สิ่งที่สำคัญคือการที่ตรรกะถูกนำไปใช้ - ในที่เดียวใกล้กับข้อมูล - ภาษาจริงเป็นเพียงรายละเอียด PL / SQL คอมไพล์รหัสเนทีฟและรันระหว่างกระบวนการกับฐานข้อมูล ไม่มีสถาปัตยกรรมประสิทธิภาพสูงกว่านั้น
• ฉันไม่ต้องการเรียนรู้ภาษาอื่น มองหาวินาทีนี่คือธงสีแดงขนาดใหญ่ในนักพัฒนา (โดยเฉพาะอย่างยิ่งที่เสนอการปรับเปลี่ยนแอปที่ใช้งานซึ่งอาจเป็นภาษาอื่น ๆ อยู่แล้ว!) มีหลายสิ่งให้เรียนรู้ที่จะทำงานในสภาพแวดล้อมสมัยใหม่: ร้าน Java ทั่วไปอาจมี Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion และอีกมากมายที่คุณต้องเรียนรู้ก่อนที่จะเขียนโค้ดแอปพลิเคชันบรรทัดเดียว ความรู้เกี่ยวกับการทำงานของภาษา SP ระดับสูงนั้นตรงไปตรงมาในการเปรียบเทียบและจะมีผู้เชี่ยวชาญหรือ DBA มากกว่าที่จะช่วยเหลือคุณเช่นกัน ไม่ต้องพูดถึงรายการโปรดของนักพัฒนา Hibernate ที่มาพร้อมกับภาษาคิวรีของตัวเอง ...

...

SQL ทำสิ่งต่าง ๆ เช่นตั้งค่าลอจิกและการกรองผลลัพธ์เชิงแอ็พพลิเคชันหรือไม่? SQL เป็นภาษาการจัดการชุดที่ยอดเยี่ยม

นอกจากนี้ตามที่ GBN ชี้ให้เห็นข้างต้นโค้ด SQL กำลังจะอยู่เหนือระดับแอพพลิเคชั่นของโค้ดเกือบทั้งหมด

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

ข้อโต้แย้งหนึ่งที่ผู้คนไม่จำเป็นต้องพูดถึง - ข้อดีได้หมดลงแล้วที่นี่ - ค่าใช้จ่าย

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

ที่นี่คือที่ที่การประชุมของจิตใจกล่าวคือจิตใจของนักพัฒนา (DVs) และ DBAs จะต้องเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ การทำงานกับ Business Logic (BL) และการจัดเก็บดังกล่าวในฐานข้อมูลสามารถมีผลกระทบที่สามารถเชิดชูหรือทำให้เกิดความน่ากลัวในการนำไปใช้

สำหรับผลิตภัณฑ์ RDBMS บางส่วนนั้นมีไลบรารี่ / เครื่องมือ / API ที่ยอดเยี่ยมสำหรับ Business Logic และ Object Infrastructures ที่หนึ่งสามารถเรียนรู้และใช้งานได้อย่างรวดเร็วในแอปพลิเคชันของพวกเขา สำหรับ RDBMS อื่นไม่มีไลบรารี / เครื่องมือ / API อยู่

ในอดีตแอปเซิร์ฟเวอร์ไคลเอนต์ทำให้บริดจ์เป็น BL ผ่าน Stored Procedure (SP) สำหรับผลิตภัณฑ์เช่น Oracle และ SQL Server สิ่งนี้ทำก่อน เนื่องจากฐานข้อมูลโอเพ่นซอร์สเช่น PostgreSQL และ MySQL กลายเป็นฐานข้อมูลผู้ที่ใช้ฐานข้อมูลเหล่านี้มีความเสี่ยงที่จะแตกฐานใหม่ด้วยกระบวนการจัดเก็บใน BL PostgreSQL นั้นมีการพัฒนาอย่างรวดเร็วเนื่องจากไม่เพียง แต่มีการจัดเก็บขั้นตอนการดำเนินการ แต่ยังสามารถสร้างภาษาของลูกค้าได้ โดยทั่วไปแล้ว MySQL หยุดการพัฒนาในโลกของขั้นตอนการจัดเก็บและมาในรูปแบบของภาษาที่มีข้อ จำกัด มากมาย ดังนั้นเมื่อพูดถึง BL แล้วคุณจะอยู่ในความเมตตาของ MySQL และภาษา Stored Procedure ของมันอย่างสมบูรณ์

มีเพียงคำถามเดียวเท่านั้น: โดยไม่คำนึงถึง RDBMS ควร BL อยู่ทั้งหมดหรือบางส่วนในฐานข้อมูลหรือไม่

คิดว่านักพัฒนา เมื่อสิ่งต่าง ๆ เกิดความผิดพลาดในแอปพลิเคชันกระบวนการดีบั๊กจะมี Developer hop เข้าและออกจากฐานข้อมูลเพื่อติดตาม chanages ข้อมูลที่อาจหรืออาจไม่ถูกต้องเป็นระยะ มันเหมือนกับการเข้ารหัสแอปพลิเคชัน C ++ และเรียกรหัสแอสเซมเบลอร์ที่อยู่ตรงกลาง คุณต้องเปลี่ยนจากซอร์สโค้ดคลาสและ structs เป็นอินเตอร์รัปต์รีจิสเตอร์และออฟเซ็ตและย้อนกลับ !!! การแก้จุดบกพร่องในระดับเดียวกัน

นักพัฒนาอาจสามารถสร้างวิธีความเร็วสูงในการดำเนินการ BL ร่วมกับการกำหนดค่าภาษา (ธงคอมไพเลอร์สำหรับ C ++, การตั้งค่าที่แตกต่างกันสำหรับ PHP / Python, ฯลฯ ) ผ่านวัตถุธุรกิจนั่งอยู่ในหน่วยความจำมากกว่าในฐานข้อมูล บางคนพยายามเชื่อมโยงอุดมการณ์นี้เพื่อให้ได้รหัส runnng ที่เร็วขึ้นลงในฐานข้อมูลโดยการเขียนไลบรารีที่การดีบักกระบวนงานที่เก็บไว้และทริกเกอร์รวมอยู่ในฐานข้อมูลได้ดีและดูเหมือนใช้งานไม่ได้

ดังนั้นผู้พัฒนาจึงถูกท้าทายในการพัฒนาตรวจแก้จุดบกพร่องและบำรุงรักษาซอร์สโค้ดและ BL ในสองภาษา

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

ตอนนี้สำหรับการประชุมของจิตใจ !!!

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

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

สรุปผลการศึกษา

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

เป็นคำถามที่ดีที่จะถามเว็บไซต์ที่เต็มไปด้วย DBA หวังว่าคำตอบส่วนใหญ่จะ "โปร" ต่อการรักษาฐานข้อมูลในสถานะกรดและทำให้ตรรกะทางธุรกิจในฐานข้อมูล :-)

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

ดังที่ Adam Musch กล่าวไว้ข้างต้นมีอะไรให้พิจารณาอีกมากสำหรับการแสดงที่นี่ การใช้งาน CPU การใช้ความจำ.

บล็อกสิ่งที่ผิดอย่างชัดเจนจากการไปยังฐานข้อมูล

• กำจัดที่อยู่อีเมลที่ไม่สอดคล้องกับวิธีการพื้นฐาน
• ตรวจสอบความยาว

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

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

ใช้จุดแข็งของแต่ละปลายเพื่อผลประโยชน์ของคุณ