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

การพัฒนาสกีมาแนวคิดและ / หรือโมเดลเชิงตรรกะและ / หรือการตั้งค่าทางกายภาพของฐานข้อมูล

4
ฟอร์มปกติแรก: คำจำกัดความที่ชัดเจน
ฉันกำลังพยายามรับรุ่นที่ชัดเจนของแบบฟอร์มปกติที่หนึ่งคืออะไร ทุกสิ่งที่ฉันอ่านมีการหมุนที่แตกต่างกันเล็กน้อย เจ้าหน้าที่หลายคนเช่นวันที่บอกว่าตามคำจำกัดความความสัมพันธ์อยู่ในรูปแบบปกติครั้งแรกในขณะที่คนอื่น ๆ ให้รายการข้อกำหนด ซึ่งหมายความว่ามีตั้งแต่ศูนย์ถึงข้อกำหนดจำนวนมากสำหรับ 1NF ฉันคิดว่าความแตกต่างคือระหว่างตารางและความสัมพันธ์: ตารางสามารถเป็นระเบียบสมบูรณ์ในขณะที่ความสัมพันธ์ตามข้อ จำกัด บางอย่าง ข้อเท็จจริงที่ว่าความสัมพันธ์นั้นแสดงเป็นตารางใน SQL จึงสร้างความสับสนบางอย่าง ฉันมุ่งเน้นไปที่ 1NF โดยเฉพาะเนื่องจากเกี่ยวข้องกับฐานข้อมูล SQL คำถามคือ: คุณสมบัติใดที่จำเป็นเพื่อให้แน่ใจว่าตารางที่อยู่ในรูปแบบปกติครั้งแรก? เจ้าหน้าที่หลายคนแนะนำว่าหากตารางแสดงถึงความสัมพันธ์แสดงว่าเป็น 1NF แล้ว สิ่งนี้จะผลักดันความหมายของ 1NF กลับไปที่ความหมายของความสัมพันธ์ นี่คือคุณสมบัติบางส่วนของตารางใน 1NF: ลำดับคอลัมน์ไม่มีความสำคัญ [1] ลำดับแถวไม่มีนัยสำคัญ แถวทั้งหมดมีความยาวเท่ากัน (เช่นข้อมูลแถวตรงกับส่วนหัวของคอลัมน์) ไม่มีแถวที่ซ้ำกัน (สามารถรับประกันได้โดยใช้คีย์หลักของตัวแทนตัวแทน แต่ไม่จำเป็นต้องใช้ PK เอง) ไม่มีคอลัมน์ซ้ำกัน แต่ละคอลัมน์มีค่าเดียว (อะตอมมิก) [1] แอททริบิวต์ทางเทคนิคไม่ได้เรียงลำดับ แต่ในตารางข้อมูลแถวจะต้องอยู่ในลำดับเดียวกับส่วนหัวของคอลัมน์ อย่างไรก็ตามคำสั่งซื้อที่แท้จริงนั้นไม่มีนัยสำคัญ ในหลายข้อมูล : แนวคิดของข้อมูลอะตอมคือไอเท็มไม่สามารถแยกย่อยได้อีก แนวคิดนี้ได้รับการมีคุณสมบัติในการว่าถึงแม้ในทางเทคนิคทุกอย่างได้ถูกทำลายลงnauseum โฆษณาข้อมูลในคำถามที่ไม่สามารถจริงเสียลงเพิ่มเติมใด …

1
สิทธิ์ลำดับชั้นในตารางที่จัดเก็บลำดับชั้น
สมมติว่าโครงสร้างฐานข้อมูลต่อไปนี้ (แก้ไขได้ถ้าต้องการ) ... ฉันกำลังมองหาวิธีที่ดีในการพิจารณา "สิทธิ์ที่มีประสิทธิภาพ" สำหรับผู้ใช้ที่ได้รับในหน้าเว็บที่กำหนดในวิธีที่ช่วยให้ฉันกลับแถวที่มีหน้าและสิทธิ์ที่มีประสิทธิภาพ ฉันคิดว่าทางออกที่ดีที่สุดอาจรวมถึงฟังก์ชันที่ใช้ CTE เพื่อดำเนินการเรียกซ้ำที่จำเป็นในการประเมิน "การอนุญาตที่มีประสิทธิภาพ" สำหรับแถวหน้าที่กำหนดสำหรับผู้ใช้ปัจจุบัน ความเป็นมาและรายละเอียดการใช้งาน สคีมาด้านบนแสดงถึงจุดเริ่มต้นสำหรับระบบการจัดการเนื้อหาที่ผู้ใช้สามารถได้รับอนุญาตโดยการเพิ่มและลบออกจากบทบาท ทรัพยากรในระบบ (เช่นหน้า) เกี่ยวข้องกับบทบาทเพื่อให้กลุ่มผู้ใช้ที่เชื่อมโยงกับบทบาทนั้นได้รับอนุญาต แนวคิดคือเพื่อให้สามารถล็อกผู้ใช้ได้ง่ายโดยเพียงแค่ปฏิเสธบทบาททั้งหมดและเพิ่มเพจระดับรูทในทรีให้กับบทบาทนั้นจากนั้นเพิ่มผู้ใช้เข้ากับบทบาทนั้น สิ่งนี้จะช่วยให้โครงสร้างการอนุญาตยังคงอยู่เมื่อ (ตัวอย่าง) ผู้รับเหมาที่ทำงานให้ บริษัท ไม่พร้อมใช้งานเป็นเวลานานจากนั้นจะอนุญาตให้มีการอนุญาตแบบเดิมโดยเพียงแค่ลบผู้ใช้ออกจากบทบาทนั้น . การอนุญาตขึ้นอยู่กับกฎชนิด ACL ทั่วไปที่อาจนำไปใช้กับระบบไฟล์โดยทำตามกฎเหล่านี้ สิทธิ์ CRUD จะเป็นบิตที่ไม่สามารถใช้ได้ดังนั้นค่าที่มีอยู่จะเป็นจริง, เท็จ, ไม่ได้กำหนดไว้โดยที่ข้อมูลต่อไปนี้เป็นจริง: false + Anything = false จริง + ไม่ได้กำหนด = จริง จริง + จริง = จริง ไม่ได้กำหนด + ไม่ได้กำหนด = …

1
การออกแบบโครงสร้างฐานข้อมูลมิตรภาพ: ฉันควรใช้คอลัมน์ที่มีหลายค่าหรือไม่
ว่าฉันมีตารางที่เรียกว่าUser_FriendListซึ่งมีลักษณะดังต่อไปนี้: CREATE TABLE User_FriendList ( ID ..., User_ID..., FriendList_IDs..., CONSTRAINT User_Friendlist_PK PRIMARY KEY (ID) ); และให้เราสมมติว่าตารางดังกล่าวถือข้อมูลต่อไปนี้: + ---- + --------- + --------------------------- + | ID | User_ID | Friendlist_ID | + ---- + --------- + --------------------------- + | 1 | 102 | 2: 15: 66: 35: 26: 17: | + …

2
คลังข้อมูล: ฉันจะค้นหาภาพรวมรายวันได้อย่างไร
ฉันมีสแนปชอตของฐานข้อมูลที่ไม่ใช่ชุดเวลา ตัวอย่างเช่น: ภาพรวมวันที่ 1: +----+---------------+------------+------------+ | ID | Title | Category | Date | +----+---------------+------------+------------+ | 1 | My First Post | helloworld | 2015-01-01 | +----+---------------+------------+------------+ Snapshot day 2 (มีการโพสต์ใหม่ในวันนี้): +----+----------------+------------+------------+ | ID | Title | Category | Date | +----+----------------+------------+------------+ | 1 | My first post | helloworld …

2
NoSQL: ข้อมูลที่ไม่มีโครงสร้างคืออะไร
ขณะนี้เรากำลังใช้ทรัพยากรที่มีอยู่ด้วยโซลูชั่น mssql เซิร์ฟเวอร์ของเรา ขณะนี้เรามีตัวเลือกแบบดั้งเดิมมากมายเกี่ยวกับการย้ายครั้งต่อไปเพื่อรับมือกับโหลด: ซื้อ CPU และ IO เร็วขึ้น แยกลูกค้าบางรายออกเป็นเซิร์ฟเวอร์แยกต่างหาก ย้าย db ไปยังคลัสเตอร์ ทั้งหมดมีราคาแพงทั้งในแง่ของลิขสิทธิ์และฮาร์ดแวร์หรือเวลา ดังนั้นฉันต้องการเพิ่มตัวเลือกอื่นโดยการย้ายทั้งระบบไปยังโซลูชันที่ปรับขนาดได้ซึ่งสัญญาของคาสซานดราเครื่องยนต์ nosql แต่ฉันไม่แน่ใจและไม่มีประสบการณ์กับฐานข้อมูล noSQL ดังนั้นฉันต้องเข้าใจโครงสร้างของข้อมูล "ที่ไม่มีโครงสร้าง" ในแอปพลิเคชันของเราเราจะจัดเก็บข้อมูลที่ผู้ใช้ป้อนในรูปแบบต่างๆเป็นรายการ "คีย์ - ค่า" มีตารางหลักที่มีองค์ประกอบส่วนหัว (เช่นคำสั่งซื้อ) และมีตารางลูกที่มีคู่ค่าคีย์ประกอบไปด้วยเนื้อหาของคำสั่งซื้อ (เช่น Order_Lines) หน่วยธุรกิจที่ชาญฉลาดคำสั่งซื้อและคำสั่งซื้อเป็นหน่วย แต่เนื่องจาก RDBMS พวกเขาจะถูกเก็บไว้ในตารางและจะต้องเข้าร่วมตลอดเวลา ในระหว่างการดำเนินการบางครั้งเราเลือกที่จะโหลดเฉพาะส่วนบน แต่ส่วนใหญ่เราโหลดแถวหลัก + KVP บางส่วนเพื่อแสดงข้อมูลที่เป็นประโยชน์ ตัวอย่างเช่นในรายการภาพรวมเราจะแสดงตัวระบุส่วนหัว + ค่าบางค่าในคอลัมน์สำหรับแต่ละแถว ปรับปรุง: เราเก็บรูปแบบใด ๆ ดังนั้นโดยทั่วไปเราจัดเก็บ "เอกสาร" อย่างไรก็ตามเราต้องจัดเตรียมและค้นหาในรูปแบบเหล่านี้ด้วยค่าใด ๆ การเรียงลำดับ ฯลฯ …

3
มันมีเหตุผลที่จะทำเครื่องหมายคอลัมน์ทั้งหมด แต่เป็นหนึ่งในคีย์หลัก?
ฉันมีโต๊ะที่เป็นตัวแทนของภาพยนตร์ เขตข้อมูลคือ: id (PK), title, genre, runtime, released_in, tags, origin, downloads. ฐานข้อมูลของฉันไม่สามารถปนเปื้อนด้วยแถวที่ซ้ำกันดังนั้นฉันต้องการบังคับใช้ซ้ำ ปัญหาคือว่าภาพยนตร์ที่แตกต่างกันอาจมีชื่อเดียวกันหรือแม้กระทั่งเขตเดียวกันยกเว้นและtags downloadsวิธีการบังคับใช้เอกลักษณ์? ฉันคิดถึงสองวิธี: สร้างฟิลด์ทั้งหมดยกเว้นdownloadsคีย์หลัก ฉันติดตามdownloadsเพราะมันเป็น JSON และอาจส่งผลกระทบต่อประสิทธิภาพการทำงาน เก็บidเป็นคีย์หลักเท่านั้น แต่เพิ่มข้อ จำกัด ที่ไม่ซ้ำกับคอลัมน์อื่น ๆ ทั้งหมด (ยกเว้นอีกครั้งdownloads) ฉันอ่านคำถามซึ่งคล้ายกันมาก แต่ฉันไม่เข้าใจว่าฉันควรทำอย่างไร ขณะนี้ตารางนี้ไม่เกี่ยวข้องกับตารางอื่น ๆ แต่ในอนาคตอาจเป็น ในขณะนี้ฉันมีบันทึกน้อยกว่า 20,000 รายการเล็กน้อย แต่ฉันคาดว่าจำนวนจะเพิ่มขึ้น ฉันไม่รู้ว่าสิ่งนี้เกี่ยวข้องกับปัญหาหรือไม่ แก้ไข:ฉันแก้ไขสคีมาและนี่คือวิธีที่ฉันจะสร้างตาราง: CREATE TABLE movies ( id serial PRIMARY KEY, title text NOT NULL, runtime …

1
จัดเก็บชุดคู่คีย์ - ค่าอย่างมีประสิทธิภาพด้วยคีย์ที่แตกต่างกัน
ฉันรับแอปพลิเคชันที่เชื่อมโยงกิจกรรมหลายประเภทกับไซต์ มีประเภทกิจกรรมที่แตกต่างกันประมาณ 100 ประเภทและแต่ละประเภทมีชุดของฟิลด์ 3-10 ที่แตกต่างกัน อย่างไรก็ตามกิจกรรมทั้งหมดมีฟิลด์วันที่อย่างน้อยหนึ่งวัน (อาจเป็นการรวมกันของวันที่วันที่เริ่มต้นวันที่สิ้นสุดวันที่เริ่มต้นที่กำหนด ฯลฯ ) และเขตข้อมูลบุคคลที่รับผิดชอบหนึ่งรายการ ฟิลด์อื่นทั้งหมดนั้นแตกต่างกันอย่างมากและฟิลด์วันที่เริ่มต้นไม่จำเป็นต้องเรียกว่า "วันที่เริ่มต้น" การสร้างตารางย่อยหนึ่งตารางสำหรับแต่ละประเภทกิจกรรมจะส่งผลให้สคีมามี 100 ตารางย่อยที่แตกต่างกันซึ่งจะเกินกว่าที่จะจัดการได้อย่างไม่เหมาะสม ทางออกปัจจุบันของปัญหานี้คือการเก็บค่ากิจกรรมเป็นคู่ของคีย์ - ค่า นี่เป็นสคีมาที่ง่ายขึ้นอย่างมากของระบบปัจจุบันเพื่อให้ได้คะแนน แต่ละกิจกรรมมี ActivityField หลายรายการ แต่ละไซต์มีหลายกิจกรรมและตาราง SiteActivityData จะเก็บ KVP สำหรับแต่ละ SiteActivity สิ่งนี้ทำให้แอปพลิเคชัน (บนเว็บ) ง่ายต่อการเขียนโค้ดเพราะสิ่งที่คุณต้องทำคือวนรอบเรคคอร์ดใน SiteActivityData สำหรับกิจกรรมที่กำหนดและเพิ่มเลเบลและการควบคุมเลเบลและอินพุตสำหรับแต่ละแถวในฟอร์ม แต่มีปัญหามากมาย: ความซื่อสัตย์นั้นไม่ดี เป็นไปได้ที่จะวางเขตข้อมูลใน SiteActivityData ที่ไม่ได้อยู่ในประเภทกิจกรรมและ DataValue เป็นเขตข้อมูล varchar ดังนั้นตัวเลขและวันที่จะต้องถูกโยนอย่างต่อเนื่อง การรายงานและการสอบถามแบบเฉพาะกิจของข้อมูลนี้เป็นเรื่องยากเกิดข้อผิดพลาดได้ง่ายและช้า ตัวอย่างเช่นการรับรายการกิจกรรมทั้งหมดของบางประเภทที่มีวันที่สิ้นสุดภายในช่วงที่ระบุต้องใช้ pivots และการคัดเลือก varchars จนถึงวันที่ ผู้เขียนรายงานเกลียดชังสคีมานี้และฉันไม่ตำหนิพวกเขา …

4
ไม่ทราบวิธีเปลี่ยนเอนทิตีของตัวแปรเป็นตารางสัมพันธ์
ข้อมูลเบื้องต้นและข้อมูลที่เกี่ยวข้อง: ตัวอย่างต่อไปนี้แสดงให้เห็นถึงปัญหาที่ฉันเผชิญ: สัตว์มีการแข่งขันซึ่งอาจจะเป็นแมวหรือสุนัข แมวสามารถเป็นได้ทั้งสยามหรือเปอร์เซีย สุนัขอาจจะเป็นคนเลี้ยงแกะเยอรมันหรือลาบราดอร์ retriver สัตว์เป็นหน่วยงานที่แข็งแกร่งในขณะที่การแข่งขันเป็นคุณลักษณะที่สามารถมีหนึ่งในสองค่าที่เสนอ (แมวหรือสุนัข) ค่าทั้งสองนี้ซับซ้อน (ฉันได้เพิ่มที่นี่เฉพาะประเภทของสุนัข / แมวเพื่ออธิบายปัญหา แต่อาจมีชื่อของแมว / สุนัขและสิ่งอื่น ๆ อีกมากมาย) ปัญหา: ฉันไม่ทราบวิธีสร้างตารางเชิงสัมพันธ์สำหรับตัวอย่างนี้ ความพยายามของฉันในการแก้ไขปัญหา: ฉันพยายามวาดแผนภาพ ER โดยใช้สัญลักษณ์ของเฉินซึ่งแสดงถึงปัญหา แต่เป็นมือใหม่ฉันไม่รู้ว่าทำถูกหรือไม่ นี่คือสิ่งที่ฉันได้รับ: ฉันขอโทษถ้าฉันทำอะไรผิดโปรดแก้ไขให้ฉันด้วยถ้าเป็นเช่นนั้น ฉันไม่ต้องการเพียงแค่รับ "วิธีแก้ปัญหาฟรี" แต่ยังต้องเรียนรู้วิธีจัดการกับปัญหานี้เพื่อที่ฉันจะสามารถแก้ไขได้ด้วยตัวเองในอนาคต สิ่งเดียวที่อยู่ในใจของฉันคือการสร้างสองตารางแยกต่างหากหนึ่งสำหรับแมวและหนึ่งสำหรับสุนัข นอกจากนี้แอตทริบิวต์การแข่งขันในตารางAnimalจะเก็บค่าแมวหรือค่าสุนัขเท่านั้น บางสิ่งเช่นนี้ Animal< # Animal_ID, race, other attributes > Cat < # Cat_ID, $ Animal_ID, breed > Dog < # …

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

2
ค้นหาแถวพาเรนต์ที่มีชุดของแถวลูกที่เหมือนกัน
สมมติว่าฉันมีโครงสร้างเช่นนี้: ตารางสูตรอาหาร RecipeID Name Description ตาราง RecipeIngredients RecipeID IngredientID Quantity UOM กุญแจสำคัญในการมีRecipeIngredients(RecipeID, IngredientID) วิธีที่ดีในการค้นหาสูตรอาหารที่ซ้ำกันคืออะไร สูตรที่ซ้ำกันหมายถึงการมีชุดส่วนผสมและปริมาณที่แน่นอนเหมือนกันสำหรับแต่ละส่วนผสม ฉันคิดว่าFOR XML PATHจะใช้เพื่อรวมส่วนผสมต่างๆไว้ในคอลัมน์เดียว ฉันยังไม่ได้สำรวจอย่างเต็มที่ แต่ควรจะทำงานถ้าฉันแน่ใจว่าส่วนผสม / UOMs / ปริมาณนั้นเรียงตามลำดับเดียวกันและมีตัวคั่นที่เหมาะสม มีแนวทางที่ดีกว่านี้ไหม? มีสูตร 48K และแถวส่วนผสม 200K

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

1
การออกแบบโครงสร้างอย่างง่ายสำหรับการแยกแยะการพยากรณ์อุปสงค์
ฉันกำลังทำงานออกแบบฐานข้อมูลอย่างง่ายเป็นแบบฝึกหัดการฝึกอบรมซึ่งฉันต้องออกแบบโครงสร้างพื้นฐานสำหรับกรณีต่อไปนี้: ฉันมีลำดับชั้นของผลิตภัณฑ์หลัก (ตัวอย่างเช่นวัตถุดิบ> งานระหว่างทำ> ผลิตภัณฑ์สุดท้าย) คำสั่งซื้อจะถูกวางไว้ในแต่ละระดับ จำนวนการสั่งซื้อจะสามารถดูได้ในที่เก็บข้อมูลรายสัปดาห์ในอีก 6 เดือนข้างหน้า การคาดการณ์ความต้องการสามารถทำได้สำหรับแต่ละระดับผลิตภัณฑ์ การพยากรณ์อุปสงค์สำหรับสัปดาห์ใด ๆ ภายใน 6 เดือนข้างหน้าสามารถทำได้ในวันนี้ การพยากรณ์ความต้องการใช้สำหรับถังข้อมูลรายสัปดาห์ในอีก 6 เดือนข้างหน้า การพยากรณ์ความต้องการมักจะทำในระดับที่สูงขึ้นในลำดับชั้น (วัตถุดิบหรืองานในระดับความคืบหน้า) จะต้องมีการแยกออกเป็นระดับที่ต่ำกว่า (ผลิตภัณฑ์สุดท้าย) มี 2 ​​วิธีที่การพยากรณ์ความต้องการสามารถแยกจากระดับที่สูงขึ้นไปถึงระดับที่ต่ำกว่าได้: ผู้ใช้ระบุเปอร์เซ็นต์การกระจายสำหรับผลิตภัณฑ์สุดท้าย สมมติว่ามีการคาดการณ์ 1,000 รายการสำหรับความคืบหน้าในการทำงาน .. และผู้ใช้บอกว่าฉันต้องการ 40% สำหรับผลิตภัณฑ์ขั้นสุดท้าย 1 และ 60% สำหรับผลิตภัณฑ์ขั้นตอนที่ 2 ในที่เก็บข้อมูล 10 .. จากนั้นสำหรับสัปดาห์ที่ 10 (วันอาทิตย์ถึงวันเสาร์) นับจากนี้ สำหรับผลิตภัณฑ์สุดท้าย 1 จะเป็น 400 และสำหรับผลิตภัณฑ์สุดท้าย …

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

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

4
มีเหตุผลที่ดีในการรักษาวันที่และเวลาในคอลัมน์แยกกันหรือไม่?
ฉันพยายามเข้าใจการตัดสินใจของผู้จำหน่ายซอฟต์แวร์ของเราเพื่อเก็บวันที่และเวลาในคอลัมน์แยกกัน ตัวอย่างเช่นเมื่อแถวถูกสร้างหรือปรับปรุง ทั้งเวลาและวันที่เป็นคอลัมน์ DateTime เรากำลังใช้ SQL Server 2005 ฐานข้อมูลเก็บข้อมูลระบบ ERP ของเราและฉันเชื่อว่าตารางที่ใหญ่ที่สุดมีประมาณ ~ 3 ล้านแถว ตารางส่วนใหญ่อยู่ระหว่างประมาณ 100,000 ถึง 1 000 000 แถว โดยส่วนตัวแล้วฉันจะเลือก DateTime เดียวสำหรับการประทับเวลาเดียว สิ่งนี้จะช่วยให้การคำนวณความแตกต่างของเวลาง่ายขึ้นและสามารถแยกส่วนวันที่และเวลาได้อย่างง่ายดายจากการประทับเวลา มันจะใช้พื้นที่น้อยลง การแยกวันและเวลานั้นเป็นการฝึกฝนที่ไม่ดีหรือมีบางสิ่งที่ยอดเยี่ยมมากในการออกแบบนี้ที่ฉันไม่เข้าใจ

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