คำถามติดแท็ก database-development

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

3
แนวทางปฏิบัติที่ดีที่สุดในปัจจุบันของ Microsoft สำหรับการสร้าง. NET data Tier? และความจริงเหรอ?
ทีมพัฒนาที่ฉันกำลังทำงานด้วยกำลังจะย้ายไปที่. NET 4.0 ในไม่ช้าอย่างไรก็ตามไลบรารีคลาสการเข้าถึงข้อมูลที่เราใช้ยังคงใช้ ADO.NET "คลาสสิค" หมายถึงSqlDataReader , DataTable และอื่น ๆ ขณะเดียวกันก็ดูเหมือนว่าไมโครซอฟท์และน่าจะเป็นส่วนที่เหลือของโลกจะก้าวไปข้างหน้ากับ Entity Framework และบริการข้อมูล WCF ฉันไม่พบสิ่งใดบน MSDN ที่ระบุว่าเทคโนโลยีการเข้าถึงข้อมูลใดที่ Microsoft พิจารณาถึงแนวทางปฏิบัติที่ดีที่สุด Microsoft มีการตั้งค่าหรือไม่? การเข้าถึงข้อมูลใดที่คนส่วนใหญ่ใช้อยู่ในปัจจุบัน มีเหตุผลที่ดีที่จะอยู่กับ ADO.NET classic และไม่ย้ายไปที่ Entity Framework หรือไม่

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

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

2
ฉันจะทำให้โครงการฐานข้อมูล visualstudio ของฉันสอดคล้องกับฐานข้อมูลของฉันได้อย่างไร
ฉันต้องการให้สคีมาฐานข้อมูลของฉันตรงกับโครงการฐานข้อมูล. dbproj ของ Visual Studio ตอนนี้ฉันกำลังใช้ SSMS สำหรับงานพัฒนาฐานข้อมูลส่วนใหญ่ของฉันและฉันจะใช้เครื่องมือเปรียบเทียบ schema ของ visual studio ด้วยตนเองเมื่อฉันต้องการ db schema และ. dbproj เพื่อซิงโครไนซ์ ทำไมฉันต้องการสิ่งนี้ เพราะ : เป็นวิธีเดียวที่จะตรวจสอบการเปลี่ยนแปลง เป็นวิธีเดียวที่จะใช้การเปลี่ยนแปลง การล้มเหลวในการทำเช่นนั้นจะทำให้เกิดปัญหาการรวมบางอย่างเมื่อรับไฟล์ (โดยทั่วไปถ้า "รับล่าสุด" มีการเปลี่ยนแปลงฐานข้อมูลบางอย่างในวัตถุฐานข้อมูลที่ฉันได้รับการอัปเดตโดยไม่ต้องตรวจสอบพวกเขาการผสานจะไม่ทำงาน ติดตามเวอร์ชันที่เป็น) ยินดีที่ได้ใช้คุณลักษณะการค้นหาของ VisualStudio บนสคีมารุ่นล่าสุด เป็นเรื่องดีที่จะสามารถแก้ไขขั้นตอนการจัดเก็บจาก VS (โดยทั่วไปเมื่อคุณเปลี่ยนชื่อไฟล์) โดยใช้ผลการค้นหา นอกเหนือจากการใช้เครื่องมือ "schema เปรียบเทียบ" โดยอัตโนมัติเพื่อให้มันทำงานทุก ๆ 5 นาที (ซึ่งฟังดูเหมือนเป็นโซลูชันที่ "สะอาด") มีวิธีใดที่จะทำให้บรรลุผลนี้ ฉันต้องการใช้ SSMS ต่อไปหากเป็นไปได้ แต่ฉันก็สนใจที่จะเผยแพร่การเปลี่ยนแปลงที่ทำโดยอัตโนมัติโดยใช้ "การเชื่อมต่อเซิร์ฟเวอร์ …

4
ขั้นตอนการจัดเก็บ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว หนึ่งในนักพัฒนาอาวุโสของเราระบุว่าเราควรใช้แบบแผนการตั้งชื่อสำหรับกระบวนการจัดเก็บด้วยรูปแบบการตั้งชื่อแบบ "objectVerb" เช่น ("MemberGetById") แทนการตั้งชื่อแบบ "verbObject" ("GetMemberByID") เหตุผลสำหรับมาตรฐานนี้คือกระบวนการที่เก็บไว้ทั้งหมดที่เกี่ยวข้องจะถูกจัดกลุ่มเข้าด้วยกันโดยวัตถุแทนที่จะกระทำ ในขณะที่ฉันเห็นตรรกะของวิธีการตั้งชื่อสิ่งต่าง ๆ นี่เป็นครั้งแรกที่ฉันได้เห็นกระบวนงานที่เก็บไว้ซึ่งตั้งชื่อด้วยวิธีนี้ ความเห็นของฉันเกี่ยวกับหลักการตั้งชื่อก็คือชื่อนั้นไม่สามารถอ่านได้อย่างเป็นธรรมชาติและใช้เวลาพอสมควรในการพิจารณาว่าคำพูดกำลังพูดถึงอะไรและกระบวนการนั้นควรทำอย่างไร คุณทำอะไรกับสิ่งนี้ วิธีการตั้งชื่อ proc ที่จัดเก็บโดยทั่วไปวิธีใดและคุณใช้อนุสัญญาการตั้งชื่อประเภท proc ที่เก็บไว้หรือไม่

5
เป็นความคิดที่ดีที่จะสร้างตารางใหม่สำหรับลูกค้าแต่ละรายของ webapp หรือไม่?
นี่คือกึ่งสมมุติและเนื่องจากฉันไม่เคยมีประสบการณ์ในการจัดการกับตารางฐานข้อมูลขนาดใหญ่ฉันจึงไม่ทราบว่ามันน่ากลัวด้วยเหตุผลบางประการ ตามสถานการณ์: ลองนึกภาพแอปพลิเคชันบนเว็บ - สมมติว่าซอฟต์แวร์บัญชีซึ่งมีลูกค้า 20,000 รายและลูกค้าแต่ละรายมีรายการมากกว่า 1,000 รายการในตาราง นั่นคือ 20 ล้านแถวซึ่งฉันรู้ว่าสามารถชะลอการค้นหาที่ซับซ้อนได้อย่างแน่นอน ในกรณีเช่นนี้การสร้างตารางใหม่ในฐานข้อมูลสำหรับไคลเอ็นต์แต่ละเครื่องเหมาะสมหรือไม่ ฐานข้อมูลมีปฏิกิริยาอย่างไรกับการมีตารางขนาด 20k (หรือมากกว่านั้น)?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.