คำถามติดแท็ก schema

ฉันทำงานกับฐานข้อมูลเชิงสัมพันธ์และคิดว่าฉันเข้าใจแนวคิดพื้นฐานของการออกแบบสคีมาที่ดีพอสมควร ฉันเพิ่งได้รับมอบหมายให้ทำโครงการที่ DB ออกแบบโดยที่ปรึกษาที่ได้รับค่าตอบแทนสูง โปรดแจ้งให้เราทราบว่าลำไส้ของฉัน - "WTF ??!?" - ได้รับการรับประกันหรือเป็นชายผู้นี้ที่เป็นอัจฉริยะที่เขาใช้งานนอกโลกของฉันหรือไม่? DB ในคำถามคือแอปที่ใช้ในการป้อนคำขอจากพนักงาน เพียงดูที่ส่วนเล็ก ๆ ของมันคุณมีข้อมูลเกี่ยวกับผู้ใช้และข้อมูลเกี่ยวกับการร้องขอ ฉันจะออกแบบเช่นนี้เพื่อ: ตารางผู้ใช้: UserID (primary Key, indexed, no dupes) FirstName LastName Department ขอโต๊ะ RequestID (primary Key, indexed, no dupes) <...> various data fields containing request details UserID -- foreign key associated with User table ง่ายใช่มั้ย ที่ปรึกษาออกแบบแบบนี้ …

61 database  sql  schema 

จากประสบการณ์ของฉันหลายโครงการที่ฉันเคยอ่านในอดีตไม่ได้มีคำจำกัดความความสัมพันธ์ในฐานข้อมูล แต่พวกเขาเพียงกำหนดไว้ในซอร์สโค้ด ดังนั้นฉันสงสัยว่าอะไรคือข้อดี / ข้อเสียของการกำหนดความสัมพันธ์ระหว่างตารางในฐานข้อมูลและในซอร์สโค้ด? และคำถามที่กว้างขึ้นเกี่ยวกับคุณสมบัติขั้นสูงอื่น ๆ ในฐานข้อมูลที่ทันสมัยเช่นน้ำตก, ทริกเกอร์, ขั้นตอน ... มีบางจุดในความคิดของฉัน: ในฐานข้อมูล: แก้ไขข้อมูลจากการออกแบบ ป้องกันข้อผิดพลาดของแอปพลิเคชันซึ่งอาจทำให้ข้อมูลไม่ถูกต้อง ลดเครือข่ายไปกลับแอปพลิเคชันเมื่อทำการแทรก / อัปเดตข้อมูลเนื่องจากแอปพลิเคชันต้องทำแบบสอบถามเพิ่มเติมเพื่อตรวจสอบความถูกต้องของข้อมูล ในรหัสที่มา: ยืดหยุ่นมากขึ้น ดีกว่าเมื่อขยายไปยังหลายฐานข้อมูลเนื่องจากบางครั้งความสัมพันธ์สามารถข้ามฐานข้อมูลได้ ควบคุมความสมบูรณ์ของข้อมูลได้มากขึ้น ฐานข้อมูลไม่จำเป็นต้องตรวจสอบทุกครั้งที่แอปพลิเคชันแก้ไขข้อมูล (ความซับซ้อนสามารถเป็น O (n) หรือ O (n log n) (?)) แต่จะมอบให้กับแอปพลิเคชันแทน และฉันคิดว่าการจัดการความสมบูรณ์ของข้อมูลในแอปพลิเคชันจะทำให้เกิดข้อความแสดงข้อผิดพลาดมากกว่าการใช้ฐานข้อมูล เช่น: เมื่อคุณสร้างเซิร์ฟเวอร์ API หากคุณกำหนดความสัมพันธ์ในฐานข้อมูลและมีบางอย่างผิดปกติ (เช่นไม่มีเอนทิตีที่อ้างอิง) คุณจะได้รับ SQL Exception พร้อมข้อความ วิธีที่ง่ายคือการคืน 500 ให้กับลูกค้าว่ามีข้อผิดพลาด "เซิร์ฟเวอร์ภายใน" และลูกค้าจะไม่ทราบว่าเกิดอะไรขึ้น หรือเซิร์ฟเวอร์สามารถแยกวิเคราะห์ข้อความเพื่อหาว่ามีอะไรผิดปกติซึ่งเป็นวิธีที่น่าเกลียดและผิดพลาดในความคิดของฉัน หากคุณปล่อยให้แอปพลิเคชันจัดการกับสิ่งนี้ …

60 mysql  relational-database  schema  rdbms 

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

19 html  data  search  schema 

การใช้ Zero Downtime Deploymentประสบปัญหาเดียวกัน แต่ฉันต้องการคำแนะนำเกี่ยวกับกลยุทธ์ที่ฉันกำลังพิจารณา บริบท แอปพลิเคชันบนเว็บพร้อม Apache / PHP สำหรับการประมวลผลฝั่งเซิร์ฟเวอร์และฐานข้อมูล MySQL / ระบบไฟล์เพื่อการคงอยู่ ขณะนี้เรากำลังสร้างโครงสร้างพื้นฐาน ฮาร์ดแวร์ระบบเครือข่ายทั้งหมดจะมีความซ้ำซ้อนและสายเคเบิลเครือข่ายหลักทั้งหมดจะถูกใช้ในคู่ที่ถูกผูกมัดสำหรับการป้องกันความผิดพลาด เซิร์ฟเวอร์กำลังได้รับการกำหนดค่าให้เป็นคู่ที่มีความพร้อมใช้งานสูงสำหรับความทนทานต่อข้อผิดพลาดของฮาร์ดแวร์และจะมีความสมดุลของโหลดสำหรับทั้งการยอมรับข้อบกพร่องของเครื่องเสมือนและประสิทธิภาพทั่วไป มันเป็นความตั้งใจของฉันที่เราสามารถใช้การปรับปรุงกับแอปพลิเคชันโดยไม่ต้องหยุดทำงาน ฉันใช้ความเจ็บปวดอย่างมากเมื่อออกแบบโครงสร้างพื้นฐานเพื่อให้แน่ใจว่าฉันสามารถให้เวลาได้ 100% มันน่าผิดหวังอย่างยิ่งที่มีเวลาหยุดทำงาน 10-15 นาทีทุกครั้งที่มีการอัปเดต สิ่งนี้มีความสำคัญอย่างยิ่งเนื่องจากเราตั้งใจที่จะมีวงจรการเผยแพร่ที่รวดเร็วมาก (บางครั้งอาจถึงหนึ่งหรือมากกว่านั้นต่อวัน โครงสร้างเครือข่าย นี่เป็นบทสรุปของเครือข่าย: Load Balancer |----------------------------| / / \ \ / / \ \ | Web Server | DB Server | Web Server | DB Server …

14 deployment  schema  strategy  downtime 

ในการอภิปรายเกี่ยวกับฐานข้อมูล NoSQL vs SQL บางครั้งฉันได้ยินว่า บริษัท ต้องการใช้ฐานข้อมูลแบบไม่มี schema ของ schemaless เนื่องจากเป็นปัญหาในการโยกย้ายสคีมาเป็นเวอร์ชันใหม่ แต่นั่นเป็นปัญหาใหญ่จริง ๆ เมื่อทำการอัพเกรด ฐานข้อมูลเชิงสัมพันธ์นั้นแย่สำหรับการดำเนินการดังกล่าวหรือไม่? ฉันอ่านโพสต์บล็อกนี้ในบล็อก MongoDB: ทำไมต้อง Schemaless

13 database  nosql  relational-database  schema 

ฉันกำลังทำงานในจุดขายใหม่สำหรับ บริษัท ที่ผลิตภัณฑ์ในราคาที่แตกต่างกันขึ้นอยู่กับส่วนผสมของผลิตภัณฑ์ ผลิตภัณฑ์ทั้งหมดมีราคาฐาน เพื่ออธิบายปัญหาของฉันฉันจะใช้ข้อมูลต่อไปนี้: Product Category Price A 1 45 B 1 70 Q 2 20 R 2 27 S 2 15 X 3 17 Y 3 22 Z 3 16 บริษัท มีแพ็คเกจเช่นแพ็คเกจ "Combo": สำหรับผลิตภัณฑ์ A หรือ B หากคุณเลือก 1 จาก Q หรือ R และ 1 จาก X, Y …

11 web-development  database  database-design  schema  relationships 

ฉันสงสัยว่าข้อได้เปรียบอะไรบ้างที่ภาษา ontology ของ RDFS / OWL มีมากกว่าการใช้ระบบการติดแท็ก / มาร์กอัป (เช่นhttp://www.schema.org/ ) สำหรับการจัดการและการสร้างข้อมูลเมตา

10 schema  tagging  semantic-web 

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

9 design  database  refactoring  schema 

ฉันจัดการโปรแกรมประยุกต์ PHP / MySQL เว็บแบบโอเพนซอร์ซที่ใช้โดยโรงเรียน K-12 และวิทยาลัยบางแห่ง ฉันยังเป็นผู้พัฒนาโครงการเท่านั้น ในขณะที่มันเคยเป็นมากกว่าการดาวน์โหลดต้นฉบับของแอปพลิเคชันที่นายจ้างของฉันโฮสต์ฉันได้ทำงานในช่วงปีที่ผ่านมาเพื่อให้เป็นโครงการโอเพ่นซอร์ส "ของจริง" พร้อมเอกสารประกอบการเผยแพร่หมายเลขการเปลี่ยนแปลงสาธารณะ ฯลฯ ฉันกำลังมองหาเพื่อปรับปรุงกระบวนการอัพเกรดและหนึ่งในพื้นที่ที่อาจเจ็บปวด (โดยเฉพาะอย่างยิ่งสำหรับโรงเรียนที่มีความเชี่ยวชาญด้านไอที) คือการเปลี่ยนแปลงโครงสร้างฐานข้อมูลระหว่างรุ่นต่างๆ พวกเขามักจะไม่เกิดขึ้นบ่อยหรือมีการเปลี่ยนแปลงที่รุนแรง แต่ฉันขอขอบคุณข้อเสนอแนะเกี่ยวกับกระบวนการ ขณะนี้ฉันยังคงสคริปต์ฐานติดตั้ง SQL ไว้เพื่อติดตั้งฐานข้อมูลในการติดตั้งใหม่ ซึ่งรวมถึงสคีมาที่สมบูรณ์สำหรับรุ่นปัจจุบัน ไม่จำเป็นต้องดำเนินการใด ๆ สำหรับการติดตั้งใหม่ การเปลี่ยนแปลงที่เกิดขึ้นระหว่างการเผยแพร่จะถูกเก็บไว้ในupgrade-$releasever.sqlสคริปต์และจำเป็นต้องเรียกใช้สคริปต์การอัปเกรดทั้งหมดสำหรับการเผยแพร่ที่ถูกข้ามไป เชลล์สคริปไม่ค่อยเหมาะสมนักเนื่องจากผู้ใช้ของเราจำนวนมากทำงานบนโฮสต์ที่ไม่มีการเข้าถึงเชลล์ เนื่องจากลำดับความสำคัญอื่น ๆ สคริปต์ติดตั้ง / อัพเกรดที่ใช้เบราว์เซอร์ PHP ที่ซับซ้อนจึงไม่น่าจะเกิดขึ้นได้ อย่างไรก็ตามฉันต้องการทำบางสิ่งกับสคริปต์ PHP ที่ใช้เบราว์เซอร์เพื่อทำให้การอัพเกรดง่ายขึ้น คำแนะนำเกี่ยวกับวิธีการเข้าถึง

9 database  release  upgrade  schema