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

ฉันกำลังวางแผนในการจัดเก็บสแกนจากแมสสเปคโตรมิเตอร์ในฐานข้อมูล MySQL และต้องการทราบว่าการจัดเก็บและวิเคราะห์ข้อมูลจำนวนนี้เป็นไปได้จากระยะไกลหรือไม่ ฉันรู้ว่าประสิทธิภาพอาจแตกต่างกันไปขึ้นอยู่กับสภาพแวดล้อม แต่ฉันกำลังมองหาลำดับความสำคัญอย่างคร่าวๆ: ข้อความค้นหาจะใช้เวลา 5 วันหรือ 5 มิลลิวินาทีหรือไม่ รูปแบบอินพุต ไฟล์อินพุตแต่ละไฟล์มีสเปคโตรมิเตอร์วิ่งเดียว การทดสอบแต่ละครั้งประกอบด้วยชุดของการสแกนและการสแกนแต่ละครั้งจะมีชุดข้อมูลที่สั่งซื้อ มีข้อมูลเมตาเล็กน้อย แต่ส่วนใหญ่ของไฟล์ประกอบด้วยอาร์เรย์ int หรือ 32- หรือ 64- บิต ระบบโฮสต์ | ---------------- + ------------------------------- | | ระบบปฏิบัติการ | Windows 2008 64-bit | | รุ่น MySQL 5.5.24 (x86_64) | | ซีพียู | 2x Xeon E5420 (ทั้งหมด 8 คอร์) | …

283 mysql  database-design  performance 

ฉันจำได้ว่าอ่านบทความนี้เกี่ยวกับการออกแบบฐานข้อมูลและฉันยังจำได้ว่าคุณควรมีคุณสมบัติเขตข้อมูลของ NOT NULL ฉันจำไม่ได้ว่าทำไมถึงเป็นเช่นนั้น สิ่งที่ฉันคิดได้ก็คือในฐานะนักพัฒนาแอปพลิเคชันคุณไม่ต้องทดสอบค่า NULL และค่าข้อมูลที่ไม่มีอยู่ (ตัวอย่างเช่นสตริงว่างสำหรับสตริง) แต่คุณจะทำอย่างไรในกรณีของวันที่วันที่และเวลา (SQL Server 2008) คุณต้องใช้วันที่ในประวัติศาสตร์หรือจุดต่ำสุด ความคิดใด ๆ เกี่ยวกับเรื่องนี้?

125 database-design  null 

ตำแหน่งที่ดีที่สุดสำหรับการจัดเก็บไฟล์ไบนารีที่เกี่ยวข้องกับข้อมูลในฐานข้อมูลของคุณคืออะไร? คุณควร: เก็บในฐานข้อมูลด้วย blob เก็บในระบบไฟล์พร้อมลิงค์ในฐานข้อมูล เก็บในระบบไฟล์ แต่เปลี่ยนชื่อเป็นแฮชของเนื้อหาและจัดเก็บแฮชบนฐานข้อมูล บางสิ่งที่ฉันไม่ได้คิด ข้อดีของ (1) คือ (ในหมู่อื่น ๆ ) ที่มีการเก็บรักษาปรมาณูของการทำธุรกรรม ค่าใช้จ่ายคือคุณอาจเพิ่มความต้องการในการจัดเก็บ (และการสตรีม / สำรองข้อมูลที่เกี่ยวข้อง) เป็นอย่างมาก เป้าหมายของ (3) คือการรักษาอะตอมมิกให้อยู่ในระดับหนึ่ง - หากคุณสามารถบังคับใช้ว่าระบบไฟล์ที่คุณเขียนไม่อนุญาตให้เปลี่ยนหรือลบไฟล์และมีแฮชที่ถูกต้องเป็นชื่อไฟล์เสมอ ความคิดที่จะเขียนไฟล์ไปยังระบบไฟล์ก่อนที่จะอนุญาตให้มีการแทรก / อัปเดตอ้างอิงแฮ - ถ้าการทำธุรกรรมนี้ล้มเหลวหลังจากระบบไฟล์เขียน แต่ก่อน DML ฐานข้อมูลนั่นเป็นเรื่องดีเพราะระบบไฟล์ 'แกล้ง' เป็นที่เก็บของทั้งหมด ไฟล์และแฮชที่เป็นไปได้ - มันไม่สำคัญว่าจะมีไฟล์บางไฟล์ในนั้นที่ไม่ได้ชี้ไปที่ (และคุณสามารถล้างมันเป็นระยะถ้าคุณระวัง) แก้ไข: ดูเหมือนว่า RDBMS บางส่วนจะมีสิ่งนี้ครอบคลุมในแบบของตัวเอง - ฉันสนใจที่จะรู้ว่าคนอื่นทำได้อย่างไร - และโดยเฉพาะอย่างยิ่งในการแก้ปัญหาสำหรับ postgres

123 database-design  blob 

ช่วยให้พูดในตารางสุ่มบางท่านมีชื่อคอลัมน์สถานะ มันเป็นค่าที่แท้จริงของโลกจะได้รับการอย่างใดอย่างหนึ่งที่เปิดใช้งานหรือปิดการใช้งาน มันจะดีกว่าสำหรับชนิดข้อมูลของคอลัมน์นี้จะเป็น int / บูล (1 หรือศูนย์) หรือจะใช้ENUMกับค่าที่เป็นenabledและdisabled? ข้อดีหรือข้อเสียคืออะไร? สมมุติว่าแทนที่จะเป็นเพียงสองสถานะที่ถูกต้องคุณมี 4 หรือ 10 หรือมากกว่านั้น ข้อดีและข้อเสียจะแกว่งไปด้านใดด้านหนึ่งหรือไม่เมื่อจำนวนค่าที่ต้องการเพิ่มขึ้น?

110 mysql  database-design  datatypes 

มีแนวทางหรือกฎง่ายๆในการพิจารณาว่าจะเก็บค่ารวมและเมื่อใดในการคำนวณพวกเขาได้ทันทีหรือไม่ ตัวอย่างเช่นสมมติว่าฉันมีวิดเจ็ตที่ผู้ใช้สามารถให้คะแนน (ดูสคีมาด้านล่าง) ทุกครั้งที่ฉันแสดงวิดเจ็ตฉันสามารถคำนวณคะแนนผู้ใช้เฉลี่ยจากRatingsตาราง อีกทางเลือกหนึ่งฉันสามารถเก็บคะแนนเฉลี่ยบนWidgetโต๊ะ สิ่งนี้จะช่วยให้ฉันไม่ต้องคำนวณการจัดอันดับทุกครั้งที่ฉันแสดงวิดเจ็ต แต่จากนั้นฉันจะต้องคำนวณคะแนนเฉลี่ยใหม่ทุกครั้งที่ผู้ใช้ให้คะแนนวิดเจ็ต Ratings Widgets --------- ------- widget_id widget_id user_id name rating avg_rating <--- The column in question

96 mysql  database-design  aggregate 

สมมติว่าผมมีตารางที่มีสาขาและA Bฉันจะทำให้คำสั่งปกติA+ ดังนั้นฉันสร้างดัชนีคอมโพสิตในB (A,B)คำสั่งในการค้นหาAจะได้รับการปรับให้เหมาะสมอย่างเต็มที่โดยดัชนีคอมโพสิตหรือไม่ นอกจากนี้ผมสร้างดัชนีในAแต่ Postgres Aยังคงใช้ดัชนีคอมโพสิตสำหรับการค้นหาเท่านั้น หากคำตอบก่อนหน้าเป็นบวกฉันคิดว่ามันไม่สำคัญ แต่ทำไมมันถึงเลือกดัชนีคอมโพสิตตามค่าเริ่มต้นหากมีAดัชนีเดียว

86 postgresql  database-design  performance  index  index-tuning 

ถ้าฉันมีตารางที่มีคอลัมน์: id | name | created_date และต้องการเพิ่มคอลัมน์ฉันใช้: alter table my_table add column email varchar(255) จากนั้นคอลัมน์จะถูกเพิ่มหลังcreated_dateคอลัมน์ มีวิธีใดบ้างที่ฉันสามารถระบุตำแหน่งสำหรับคอลัมน์ใหม่ได้ เช่นเพื่อให้ฉันสามารถเพิ่มหลังจากnameได้รับตารางเช่น: id | name | email | created_date

74 postgresql  database-design 

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

74 database-design 

ฉันกำลังเขียนแอปพลิเคชันที่ต้องการจัดเก็บและวิเคราะห์ข้อมูลไฟฟ้าและอุณหภูมิจำนวนมาก โดยทั่วไปฉันจำเป็นต้องจัดเก็บการวัดปริมาณการใช้ไฟฟ้ารายชั่วโมงเป็นจำนวนมากในช่วงหลายปีที่ผ่านมาและเป็นเวลาหลายปีที่จะมาถึงที่ตั้งหลายหมื่นแห่งจากนั้นวิเคราะห์ข้อมูลในลักษณะที่ไม่ซับซ้อนมาก ข้อมูลที่ฉันต้องการจัดเก็บ (ตอนนี้) คือรหัสสถานที่, เวลาประทับ (วันที่และเวลา), อุณหภูมิและการใช้ไฟฟ้า เกี่ยวกับปริมาณข้อมูลที่ต้องจัดเก็บนี่เป็นเพียงการประมาณ แต่มีบางสิ่งตามสายเหล่านี้: 20 000+ ตำแหน่ง 720 บันทึกต่อเดือน (วัดรายชั่วโมงประมาณ 720 ชั่วโมงต่อเดือน), 120 เดือน (สำหรับ 10 ปีย้อนหลัง ) และอีกหลายปีในอนาคต การคำนวณอย่างง่ายให้ผลลัพธ์ต่อไปนี้: 20 000 สถาน x 720 x 120 บันทึกเดือน (10 ปีหลัง) = 1 728 000 000 ระเบียน เหล่านี้เป็นบันทึกที่ผ่านมาบันทึกใหม่จะถูกนำเข้ารายเดือนเพื่อให้เป็นประมาณ 20 000 x 720 = 14 400 …

74 database-design  database-recommendation  nosql 

เราประมวลผลฟีดข้อมูลประจำจากลูกค้าที่เพิ่งปรับโครงสร้างฐานข้อมูลของพวกเขาจากรูปแบบที่ดูเหมือนคุ้นเคย (หนึ่งแถวต่อเอนทิตี้หนึ่งคอลัมน์ต่อแอตทริบิวต์) ไปยังอันที่ดูเหมือนฉันไม่คุ้นเคย (หนึ่งแถวต่อเอนทิตีต่อแอตทริบิวต์): ก่อนหน้า: หนึ่งคอลัมน์ต่อแอตทริบิวต์ ID Ht_cm wt_kg Age_yr ... 1 190 82 43 ... 2 170 60 22 ... 3 205 90 51 ... หลัง: หนึ่งคอลัมน์สำหรับแอตทริบิวต์ทั้งหมด ID Metric Value 1 Ht_cm 190 1 Wt_kg 82 1 Age_yr 43 1 ... 2 Ht_cm 170 2 Wt_kg 60 2 Age_yr …

68 database-design  schema  eav  ontology 

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

57 database-design 

ฉันกำลังเขียนคีสำหรับฐานข้อมูลธนาคารที่เรียบง่าย นี่คือคุณสมบัติพื้นฐาน: ฐานข้อมูลจะเก็บธุรกรรมกับผู้ใช้และสกุลเงิน ผู้ใช้ทุกคนมียอดดุลหนึ่งรายการต่อหนึ่งสกุลเงินดังนั้นแต่ละยอดดุลเป็นเพียงผลรวมของธุรกรรมทั้งหมดต่อผู้ใช้และสกุลเงิน ยอดคงเหลือต้องไม่ติดลบ แอปพลิเคชันธนาคารจะสื่อสารกับฐานข้อมูลผ่านขั้นตอนการจัดเก็บ ฉันคาดหวังว่าฐานข้อมูลนี้จะยอมรับการทำธุรกรรมใหม่หลายแสนรายการต่อวันรวมทั้งคำสั่งยอดคงเหลือในลำดับความสำคัญที่สูงขึ้น ในการให้บริการยอดคงเหลืออย่างรวดเร็วฉันต้องรวมไว้ล่วงหน้า ในเวลาเดียวกันฉันต้องรับประกันว่ายอดเงินจะไม่ขัดแย้งกับประวัติการทำธุรกรรม ตัวเลือกของฉันคือ: มีbalancesตารางแยกต่างหากและทำสิ่งใดสิ่งหนึ่งต่อไปนี้: ใช้ธุรกรรมกับทั้งtransactionsและbalancesตาราง ใช้TRANSACTIONตรรกะในเลเยอร์ของโพรซีเดอร์ที่เก็บไว้เพื่อให้แน่ใจว่ายอดคงเหลือและการทำธุรกรรมมีการซิงค์อยู่เสมอ (รองรับโดยแจ็ค ) ใช้ธุรกรรมกับtransactionsตารางและมีทริกเกอร์ที่อัปเดตbalancesตารางให้ฉันด้วยจำนวนธุรกรรม ใช้ธุรกรรมกับbalancesตารางและมีทริกเกอร์ที่เพิ่มรายการใหม่ในtransactionsตารางให้ฉันด้วยจำนวนธุรกรรม ฉันต้องพึ่งพาวิธีการรักษาความปลอดภัยเพื่อให้แน่ใจว่าไม่มีการเปลี่ยนแปลงใด ๆ นอกกระบวนการที่เก็บไว้ มิฉะนั้นตัวอย่างเช่นกระบวนการบางอย่างสามารถแทรกธุรกรรมลงในtransactionsตารางโดยตรงและภายใต้โครงการ1.3ยอดคงเหลือที่เกี่ยวข้องจะไม่ซิงค์กัน มีbalancesมุมมองที่จัดทำดัชนีที่รวมการทำธุรกรรมอย่างเหมาะสม เครื่องมือเก็บข้อมูลรับประกันยอดคงเหลือเพื่อให้สอดคล้องกับการทำธุรกรรมของพวกเขาดังนั้นฉันไม่จำเป็นต้องพึ่งพาวิธีการรักษาความปลอดภัยเพื่อรับประกันสิ่งนี้ ในทางกลับกันฉันไม่สามารถบังคับยอดคงเหลือให้เป็นค่าที่ไม่เป็นลบได้อีกต่อไปนับตั้งแต่การดู - แม้แต่การดูที่มีการจัดทำดัชนี - ไม่สามารถมีCHECKข้อ จำกัด ได้ (สนับสนุนโดยDenny ) มีเพียงtransactionsตารางแต่มีคอลัมน์เพิ่มเติมเพื่อจัดเก็บยอดคงเหลือที่มีประสิทธิภาพหลังจากทำรายการนั้นแล้ว ดังนั้นบันทึกธุรกรรมล่าสุดสำหรับผู้ใช้และสกุลเงินจึงมียอดดุลปัจจุบัน (แนะนำโดยAndrewด้านล่าง; ตัวแปรที่เสนอโดยgarik ) ครั้งแรกที่ผมจัดการปัญหานี้ผมอ่านเหล่านี้ สอง2การอภิปรายและการตัดสินใจในตัวเลือก สำหรับการอ้างอิงคุณสามารถดูการดำเนินงานที่เปลือยกระดูกของมันนี่ คุณออกแบบหรือจัดการฐานข้อมูลเช่นนี้ด้วยโปรไฟล์การโหลดสูงหรือไม่ คุณมีวิธีแก้ไขปัญหานี้อย่างไร คุณคิดว่าฉันได้เลือกการออกแบบที่ถูกต้องหรือไม่? มีอะไรบ้างที่ฉันควรจำไว้? ตัวอย่างเช่นฉันรู้ว่าการเปลี่ยนสคีมาในtransactionsตารางจะต้องมีการสร้างbalancesมุมมองใหม่ แม้ว่าฉันจะเก็บถาวรธุรกรรมเพื่อทำให้ฐานข้อมูลมีขนาดเล็ก (เช่นย้ายไปที่อื่นและแทนที่ด้วยธุรกรรมสรุป) การสร้างมุมมองใหม่จากการทำธุรกรรมหลายสิบล้านครั้งด้วยการปรับปรุง schema ทุกครั้งอาจหมายถึงการหยุดทำงานต่อการปรับใช้ …

57 sql-server  sql-server-2008  database-design  aggregate  materialized-view 

ฉันต้องการย้ายแอปพลิเคชั่นฐานข้อมูลที่ขับเคลื่อนด้วยฐานข้อมูลอย่างง่าย ๆ จาก SQLite3 ไปยัง PostgreSQL 9.3 และกระชับสิทธิ์ใน DB ขณะที่ฉันดำเนินการ แอปพลิเคชันในปัจจุบันประกอบด้วยคำสั่งเพื่ออัปเดตข้อมูล และหนึ่งในการค้นหา โดยปกติฉันจะต้องบำรุงรักษาฐานข้อมูลด้วยวิธีอื่น (สร้างตารางมุมมองทริกเกอร์ ฯลฯ ) ใหม่ ในขณะที่แอปพลิเคชันนี้จะเป็นโฮสต์เดียวบนเซิร์ฟเวอร์ในตอนแรกฉันต้องการอบในสมมุติฐานว่ามันอาจจะโฮสต์บนเซิร์ฟเวอร์ที่มีฐานข้อมูลอื่น ๆ ในอนาคตแทนที่จะต้องแย่งภายหลังหากจำเป็น อนาคต. ฉันคิดว่าสิ่งเหล่านี้เป็นข้อกำหนดที่พบได้ทั่วไป แต่ฉันมีปัญหาในการค้นหาบทช่วยสอนที่อธิบายวิธีตั้งค่าฐานข้อมูลใหม่ใน PostgreSQL โดยมีการแยกผู้ใช้ / สิทธิ์แบบนี้ การอ้างอิงดำเนินไปอย่างมีความยาวเกี่ยวกับกลุ่มผู้ใช้บทบาทฐานข้อมูลสกีมาและโดเมน แต่ฉันพบว่าพวกเขาสับสน นี่คือสิ่งที่ฉันได้ลองมาแล้ว (จากภายในpsqlเป็น 'postgres'): CREATE DATABASE hostdb; REVOKE ALL ON DATABASE hostdb FROM public; \connect hostdb CREATE SCHEMA hostdb; CREATE USER hostdb_admin …

48 postgresql  database-design  permissions 

ผมจำได้จากพอดคาสต์ StackOverflow ว่าหมอกครีกใช้ฐานข้อมูลต่อลูกค้าสำหรับFogbugz ฉันคิดว่านั่นหมายถึงเซิร์ฟเวอร์ Fogbugz On Demand มีฐานข้อมูลนับหมื่น ๆ เราเพิ่งเริ่มพัฒนาเว็บแอปและมีปัญหาคล้ายกันในการแก้ปัญหา (ลูกค้าจำนวนมากที่มีข้อมูลแยกต่างหากของตัวเอง) ฉันควรคาดหวังปัญหาอะไรบ้างเมื่อใช้ฐานข้อมูลต่อลูกค้าหนึ่งราย ฉันจะแก้ปัญหาได้อย่างไร ความคิดเริ่มต้นของฉัน ข้อดีของฐานข้อมูลต่อลูกค้า สคีมาฐานข้อมูลที่ง่ายขึ้น การสำรองข้อมูลที่ง่ายขึ้น - คุณสามารถสำรองข้อมูลลูกค้าแต่ละรายโดยไม่ส่งผลกระทบต่อลูกค้ารายอื่น ทำให้ง่ายต่อการส่งออกข้อมูลลูกค้าที่ระบุ ประสิทธิภาพแคชที่ดีขึ้น - การเขียนลงในหนึ่งในแอ็คทีฟตารางจะมีผลกับลูกค้ารายเดียวที่ดำเนินการเขียนเท่านั้น ง่ายต่อการปรับขนาดข้ามฮาร์ดแวร์ ตัวอย่างเช่นเมื่อเราต้องไปจากเซิร์ฟเวอร์ 1 ถึง 2 เราเพิ่งย้ายลูกค้าของเราครึ่งหนึ่งไปยังเซิร์ฟเวอร์ใหม่ ข้อเสีย MySQL สามารถรับมือกับ 5,000 ฐานข้อมูลได้หรือไม่ ประสิทธิภาพจะแย่ไหม? การเปลี่ยนแปลงสคีมานั้นยากที่จะทำซ้ำในฐานข้อมูลทั้งหมด เราจะต้องมีแผนอัตโนมัติสำหรับสิ่งนี้เช่นการกำหนดเวอร์ชันของสคีมาและสคริปต์ที่เข้าใจวิธีการใช้ฐานข้อมูลจากรุ่นหนึ่งไปยังอีกรุ่นหนึ่ง การทำสิ่งใด ๆ ที่เป็นเรื่องปกติสำหรับลูกค้าของเราทุกคนอาจทำให้เกิดความอึดอัดหรือเป็นไปไม่ได้ คล้ายกับข้างต้น แต่การวิเคราะห์ใด ๆ ที่เราต้องการดำเนินการกับลูกค้าทั้งหมดของเราอาจเป็นไปไม่ได้ เราควรติดตามการใช้งานของลูกค้าทั้งหมดอย่างไร

48 mysql  database-design  database-recommendation 

คำตอบและความคิดเห็นเกี่ยวกับรุ่น dba.seและprogrammers.se รุ่นของคำถาม"สิ่งที่ขัดแย้งกับหรือสำหรับการวางตรรกะของโปรแกรมประยุกต์ในชั้นฐานข้อมูลหรือไม่" มีการเปิดเผยเกี่ยวกับการแบ่งระหว่าง DBA และโปรแกรมเมอร์ในที่ทำงานบางแห่ง DBA ทำอะไรได้บ้างเพื่อให้ทำงานได้ดีขึ้นกับโปรแกรมเมอร์ในประเด็นเช่นนี้ เราควร: ศึกษาเครื่องมือและภาษาที่โปรแกรมเมอร์ของเราใช้เพื่อทำความเข้าใจปัญหาที่พวกเขาเผชิญโดยเฉพาะเมื่อทำงานกับฐานข้อมูลที่ออกแบบมาอย่างดี? ส่งเสริมให้โปรแกรมเมอร์ให้ความรู้เกี่ยวกับฐานข้อมูลและข้อดีของการมีตรรกะทางธุรกิจในระดับฐานข้อมูลดีขึ้นหรือไม่ เปลี่ยนวิธีที่เรากำหนดอินเทอร์เฟซให้กับข้อมูลของเรา - เช่นโดยใช้ API การทำธุรกรรมที่เป็นมิตรกับโปรแกรมเมอร์มากขึ้น (เช่นสำหรับปัญหาเช่นความเข้ากันได้ย้อนหลัง)?

46 database-design  best-practices