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

สมมติว่าฉันมีบริการ 4 ประเภทที่ฉันเสนอให้ (พวกเขาไม่น่าจะเปลี่ยนแปลงบ่อย): การทดสอบ ออกแบบ การเขียนโปรแกรม อื่น ๆ สมมติว่าฉันมีบริการจริง 60-80 รายการที่แต่ละบริการจัดอยู่ในหมวดหมู่ข้างต้น ตัวอย่างเช่น 'บริการ' สามารถเป็น "โปรแกรมทดสอบโดยใช้เทคนิค A" และเป็นประเภท "การทดสอบ" ฉันต้องการเข้ารหัสให้เป็นฐานข้อมูล ฉันมากับตัวเลือกไม่กี่: ตัวเลือก 0: ใช้VARCHARโดยตรงเพื่อเข้ารหัสประเภทบริการโดยตรงเป็นสตริง ตัวเลือกที่ 1: enumฐานข้อมูลการใช้งาน แต่enum นั้นชั่วร้าย ตัวเลือก 2: ใช้สองตาราง: service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); ฉันยังสามารถเพลิดเพลินกับ Referential Integrity: ALTER service_line_item ADD FOREIGN KEY …

38 database-design  efficiency  enum  normalization 

การเป็นตัวแทนของตำแหน่งทางภูมิศาสตร์ภายในแอปพลิเคชันการออกแบบตัวแบบข้อมูลอ้างอิงนั้นเสนอทางเลือกที่ชัดเจนสองทาง (หรืออาจมากกว่านั้น) ตารางหนึ่งที่มีคอลัมน์ parent_id อ้างอิงตนเอง uk - london (london parent id = UK id) หรือสองตารางที่มีความสัมพันธ์แบบหนึ่งต่อหลายโดยใช้คีย์ต่างประเทศ การตั้งค่าของฉันสำหรับตารางอ้างอิงตัวเองหนึ่งตารางเนื่องจากช่วยให้ขยายขอบเขตได้ง่ายตามต้องการ โดยทั่วไปแล้วคนออกไปจากตารางอ้างอิงตนเองหรือว่าพวกเขา A-OK?

37 sql  database-design 

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

33 database  database-design  multitenancy 

ข้อโต้แย้งใดที่ควรพิจารณาเมื่อออกแบบระบบใหม่และต้องเก็บชื่อของบุคคลเป็นฟิลด์เดียวหรือแยกเป็นชื่อ / นามสกุล? ข้อดีสำหรับฟิลด์เดียว: UI ที่เรียบง่าย ไม่มีความกำกวมเมื่อพยายามป้อนชื่อของบุคคลที่มีชื่อยาวมาก (มักไม่ชัดเจนซึ่งเป็นนามสกุล / ชื่อ .. ) ความซับซ้อนน้อยลงเมื่อจัดการหัวเรื่อง (เช่นไม่จำเป็นต้องแยกฟิลด์เพื่อป้อน "MD" หรือ "Dr. ") ข้อดีสำหรับฟิลด์แยก: การสื่อสารส่วนบุคคลเป็นไปได้ "Dear Mr X" หรือ "Dear Julie" หากบริการเว็บที่ใช้งานต้องการชื่อ / นามสกุลแยกกันสามารถให้บริการได้อย่างง่ายดาย ทางเลือกที่ดีกว่าสำหรับอุตสาหกรรมใด ๆ ที่มีข้อกำหนดการระบุที่เข้มงวด (เช่นการแพทย์รัฐบาล ฯลฯ ) ตัวเลือกที่ปลอดภัยยิ่งขึ้นเนื่องจากคุณสามารถกลับไปใช้ทางเลือกเขตข้อมูลเดียวได้ตลอดเวลา คุณเห็นอาร์กิวเมนต์เพิ่มเติมที่ไม่ได้ระบุไว้ข้างต้นหรือไม่ อัปเดต: คำถามคืออะไรข้อโต้แย้งเพิ่มเติม (= ไม่ได้ระบุไว้ในคำถาม) สามารถแสดงรายการได้สำหรับแต่ละโซลูชัน ฉันคิดว่าการให้ความคิดเห็นแทนข้อดีและข้อเสียที่เป็นไปได้ผลักดันการอภิปรายในทางที่ผิด ผู้พัฒนาแต่ละคนจะต้องทำการตัดสินใจของเขา / เธอเกี่ยวกับปัญหานี้เป้าหมายของคำถามนี้คือการรวบรวมรายการของการขัดแย้งที่ไม่สำคัญที่สามารถประเมินได้หากจำเป็น

32 database-design  data  domain-model  data-modeling 

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

31 database  web-applications  database-design  synchronization 

ฉันมีลูกค้าตอนนี้ต้องการให้ฉันพัฒนาระบบการลงทะเบียนของโรงเรียน ตอนนี้เป็นครั้งแรกที่ฉันมีความท้าทายแบบนี้ ซอฟต์แวร์ที่ผ่านมาส่วนใหญ่ที่ฉันสร้างไม่ซับซ้อน ฉันรู้ว่าพวกคุณส่วนใหญ่ได้สร้างซอฟแวร์ที่ซับซ้อนฉันแค่ต้องการคำแนะนำของคุณเกี่ยวกับเรื่องนี้ ฉันควรออกแบบส่วนหน้าหรือส่วนหลังก่อนหรือไม่ ขอบคุณ! นี่คือข้อสรุปของบทความที่ฉันพบในอินเทอร์เน็ตเมื่อไม่นานมานี้ แค่ต้องการแบ่งปัน http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 นักพัฒนา Front-End และ Back-End (ใช้ของฉัน) ส่วนตัวของฉัน เป็นเรื่องของการฝึกอีกครั้งการสรุปทั่วไปของโรคหลอดเลือดสมองในวงกว้าง: นักพัฒนาส่วนหน้า โดยทั่วไปแล้วจะไม่มีระดับ CS หรือมีระดับ CS จากโรงเรียนชั้นที่ 3 ทำงานในภาษาที่คล้ายกับพื้นฐาน (ดู PHP เป็นพื้นฐาน) มีทักษะการมองเห็นในการแปลงเอกสาร Photoshop เป็น CSS / HTML / ฯลฯ มีความอดทนสูงสำหรับการเขียนโปรแกรมซ้ำเนื่องจากภาษาฟรี นักพัฒนาส่วนหลัง มีระดับ CS หรือมีประสบการณ์มากมาย ทำให้ฉันเป็นระบบมากขึ้นในวิธีการแก้ปัญหาของพวกเขา อย่ารังเกียจที่จะใช้เวลาหลายวันเพื่อค้นหาวัตถุชิ้นหนึ่งที่รั่ว ลองและสร้างเครื่องมือเพื่อแก้ปัญหา

30 design  database  database-development  database-design  front-end 

สำหรับวัตถุประสงค์ของการสนทนาลองพิจารณาสถานการณ์จำลองของ FourSquare สถานการณ์ หน่วยงาน: ผู้ใช้ สถานที่ ความสัมพันธ์: Checkins: ผู้ใช้ <-> สถานที่หลายแห่งไปมาก เพื่อน: ผู้ใช้ <-> ผู้ใช้หลายต่อหลายคน การออกแบบฐานข้อมูล สิ่งเหล่านี้มักจะมีข้อผิดพลาดโปรดชี้ให้พวกเขาเห็น RDBMS โต๊ะ: ผู้ใช้ สถานที่ เช็คอิน (แยก) เพื่อน (แยก) ข้อดี: CAP: ความสอดคล้องความพร้อมใช้งาน จุดด้อย: CAP: ความอดทนต่อการแบ่งพาร์ทิชัน schemes = โครงสร้างที่ไม่ยืดหยุ่น การจำลองแบบไม่ดี? กราฟ วัตถุที่: ผู้ใช้ สถานที่ ขอบ: เพื่อน: ผู้ใช้ <-> ผู้ใช้ เช็คอิน: ผู้ใช้ -> สถานที่ มีการประทับเวลา ข้อดี: …

29 database  database-design  relational-database  document-databases  graph-databases 

ฉันได้ทำการสืบค้น SQL ทิ้งของ CMS ที่มีชื่อเสียงบางตัวรวมถึง Drupal 7, Wordpress (บางรุ่นที่ค่อนข้างเก่า) และแอปพลิเคชันที่กำหนดเองบางตัวที่ใช้ Python ดัมพ์เหล่านี้ทั้งหมดมีข้อมูลที่มีแฟล็กสตริงแทนค่าจำนวนเต็ม ยกตัวอย่างเช่นสถานะการโพสต์ได้แสดงเป็นpublished, closedหรือinheritมากกว่า1, หรือ23 ฉันมีประสบการณ์ค่อนข้าง จำกัด ในการออกแบบฐานข้อมูลและฉันไม่เคยผ่าน SQL แบบง่าย ๆ มาก่อน แต่ฉันได้รับการสอนเสมอว่าฉันควรใช้ตัวเลข / จำนวนเต็มสำหรับข้อมูลเช่นนี้ ก็ชัดเจนว่าพื้นที่กินมากน้อยในฐานข้อมูลกว่ายกตัวอย่างเช่นtinyintvarchar(9) แล้วฉันจะพลาดอะไรไป? นี่ไม่ใช่การจัดเก็บข้อมูลและการสำรองข้อมูลซ้ำซ้อนหรือไม่ การเรียกดูการค้นหาและการจัดทำดัชนีจะไม่เร็วกว่านี้ไหมถ้าคอลัมน์เหล่านี้ใช้จำนวนเต็มแทนที่จะเป็นสตริง

29 database  database-design  sql  strings 

ฉันกำลังทำงานในโครงการซอฟต์แวร์ขนาดใหญ่ซึ่งได้รับการปรับแต่งอย่างดีสำหรับลูกค้าที่หลากหลายทั่วโลก ซึ่งหมายความว่าเราอาจมีรหัส 80% ซึ่งเป็นเรื่องปกติระหว่างลูกค้าหลายราย แต่ยังมีรหัสจำนวนมากที่ต้องเปลี่ยนจากลูกค้ารายหนึ่งเป็นลูกค้ารายอื่น ในอดีตที่ผ่านมาเราทำการพัฒนาของเราในที่เก็บแยกต่างหาก (SVN) และเมื่อโครงการใหม่เริ่มต้น (เรามีน้อย แต่ลูกค้าขนาดใหญ่) สร้างพื้นที่เก็บข้อมูลอื่นตามโครงการที่ผ่านมามีพื้นฐานรหัสที่ดีที่สุดสำหรับความต้องการของเรา สิ่งนี้ได้ผลในอดีต แต่เราพบปัญหาหลายประการ: ข้อบกพร่องที่ได้รับการแก้ไขในที่เก็บหนึ่งจะไม่ได้รับการแก้ไขในที่เก็บอื่น ๆ นี่อาจเป็นปัญหาขององค์กร แต่ฉันพบว่ามันยากที่จะแก้ไขและแก้ไขข้อบกพร่องในที่เก็บ 5 แห่งที่แตกต่างกันโดยคำนึงว่าทีมที่ดูแลพื้นที่เก็บข้อมูลนี้อาจอยู่ในอีกส่วนหนึ่งของโลกและเราไม่มีสภาพแวดล้อมการทดสอบ ไม่ทราบกำหนดการหรือข้อกำหนดที่ต้องมี ("ข้อบกพร่อง" ในประเทศหนึ่งอาจเป็น "คุณสมบัติ" ในอีกประเทศหนึ่ง) คุณสมบัติและการปรับปรุงที่ทำไว้สำหรับโครงการหนึ่งซึ่งอาจเป็นประโยชน์สำหรับโครงการอื่นหายไปหรือหากใช้ในโครงการอื่นมักทำให้เกิดอาการปวดหัวขนาดใหญ่รวมจากรหัสฐานหนึ่งไปยังอีกโครงการหนึ่ง (เนื่องจากทั้งสองสาขาอาจได้รับการพัฒนาอย่างอิสระเป็นเวลาหนึ่งปี ) Refactorings และการปรับปรุงรหัสที่ทำในสาขาการพัฒนาหนึ่งอาจสูญหายหรือก่อให้เกิดอันตรายมากกว่าดีถ้าคุณต้องรวมการเปลี่ยนแปลงทั้งหมดเหล่านี้ระหว่างสาขา ขณะนี้เรากำลังพูดถึงวิธีการแก้ปัญหาเหล่านี้และในขณะนี้ได้มีแนวคิดต่อไปนี้เกี่ยวกับวิธีการแก้ไขปัญหาดังกล่าว: ทำการพัฒนาในสาขาที่แยกกันแต่จัดระเบียบได้ดีขึ้นด้วยการมีที่เก็บส่วนกลางที่มีการแก้ไขข้อบกพร่องทั่วไปและรวมโครงการทั้งหมดเข้าด้วยกันการเปลี่ยนแปลงจากที่เก็บส่วนกลางนี้เป็นของตัวเองเป็นประจำ (เช่นทุกวัน) เรื่องนี้ต้องมีวินัยอย่างมากและมีความพยายามอย่างมากในการผสานระหว่างสาขา ดังนั้นฉันไม่มั่นใจว่ามันจะทำงานได้และเราสามารถรักษาวินัยนี้โดยเฉพาะอย่างยิ่งเมื่อเวลากดดัน ละทิ้งการพัฒนาแยกสาขาและมีที่เก็บรหัสกลางที่รหัสของเราทั้งหมดอยู่และทำการปรับแต่งของเราโดยมีโมดูลที่เสียบได้และตัวเลือกการกำหนดค่า เรากำลังใช้คอนเทนเนอร์การพึ่งพาการพึ่งพาเพื่อแก้ไขการพึ่งพาในรหัสของเราและเรากำลังติดตามรูปแบบ MVVM ในรหัสส่วนใหญ่ของเราเพื่อแยกตรรกะทางธุรกิจออกจาก UI ของเราอย่างหมดจด วิธีที่สองดูเหมือนจะสง่างามกว่า แต่เรามีปัญหาที่ยังไม่คลี่คลายในแนวทางนี้ ตัวอย่างเช่นวิธีจัดการกับการเปลี่ยนแปลง / การเพิ่มเติมในแบบจำลอง / ฐานข้อมูลของคุณ เราใช้. NET กับ …

28 design  architecture  development-process  database-design  code-organization 

ฉันกำลังสร้างแบบจำลองฐานข้อมูลที่ควรใช้เป็นสิ่งจำเป็นที่ไม่มีการใช้งานทั่วไปสำหรับบริการทั้งหมดของ บริษัท เริ่มต้นเช่นบุคคลผู้ใช้บริการและข้อมูลเชิงพาณิชย์เช่นคูปองแพคเกจลายเซ็น ฯลฯ ฉันกำลังคิดเกี่ยวกับแบบจำลองเพศ ในยุคปัจจุบันนี้และด้วยกฎหมายที่แตกต่างกันในหลายประเทศเกี่ยวกับอัตลักษณ์อัตนัยฉันควรคำนึงถึงเรื่องนี้และพิจารณารูปแบบสิ่งที่บุคคลของฉันมีมากกว่าแค่ตัวเลือกชายและหญิง ? ตัวเลือกคือ: ไม่ได้กำหนดไม่ตอบรับอื่น ๆ เพศ ... หรือมาตรฐานอุตสาหกรรมอื่น ๆที่ฉันไม่รู้ ... หรือสิ่งนี้ทำให้คน LGBT ขุ่นเคืองด้วยการบอกว่าพวกเขาไม่ใช่ผู้ชายหรือผู้หญิงอย่างแท้จริง?

27 database-design  domain-model  data-modeling 

หนึ่งในรายการในจาวาที่มีประสิทธิภาพของ Joshua Bloch คือความคิดที่ว่าคลาสควรยอมให้มีการเปลี่ยนแปลงอินสแตนซ์น้อยที่สุดเท่าที่จะเป็นไปได้ บ่อยครั้งที่ข้อมูลของวัตถุนั้นยังคงอยู่ในฐานข้อมูลของบางรูปแบบ สิ่งนี้ทำให้ฉันคิดถึงความคิดที่ไม่สามารถเปลี่ยนแปลงได้ภายในฐานข้อมูลโดยเฉพาะอย่างยิ่งสำหรับตารางที่แสดงถึงเอนทิตีเดียวภายในระบบที่ใหญ่กว่า บางสิ่งที่ฉันได้ทำการทดลองเมื่อเร็ว ๆ นี้คือแนวคิดของการพยายามลดการอัปเดตที่ฉันทำกับแถวของตารางที่เป็นตัวแทนวัตถุเหล่านี้และพยายามที่จะทำการแทรกให้มากที่สุดเท่าที่จะทำได้ ตัวอย่างที่ชัดเจนของสิ่งที่ฉันกำลังทดลองใช้เมื่อไม่นานมานี้ หากฉันรู้ว่าฉันอาจต่อท้ายระเบียนด้วยข้อมูลเพิ่มเติมในภายหลังฉันจะสร้างตารางอื่นเพื่อแสดงว่าเรียงลำดับเช่นสองคำจำกัดความของตารางต่อไปนี้: create table myObj (id integer, ...other_data... not null); create table myObjSuppliment (id integer, myObjId integer, ...more_data... not null); หวังว่าจะเห็นได้ชัดว่าชื่อเหล่านี้ไม่ใช่คำต่อคำ แต่เป็นเพียงการสาธิตความคิด นี่เป็นวิธีการที่เหมาะสมในการสร้างแบบจำลองการคงอยู่ของข้อมูลหรือไม่ มันคุ้มค่าหรือไม่ที่จะพยายาม จำกัด การอัปเดตที่ดำเนินการบนโต๊ะโดยเฉพาะอย่างยิ่งสำหรับการกรอกข้อมูลที่เป็นโมฆะสำหรับข้อมูลที่อาจไม่มีอยู่เมื่อสร้างเรกคอร์ด? มีบางครั้งที่วิธีการเช่นนี้อาจทำให้เกิดอาการปวดอย่างรุนแรงในภายหลังหรือไม่?

26 database-design  immutability 

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

26 database  database-design 

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

26 sql  database-design  optimization  ssd 

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

25 design  database  database-design  database-development 

ฉันตระหนักถึงแนวปฏิบัติที่ดีที่สุดทั่วไปบางอย่างเมื่อออกแบบฐานข้อมูลสำหรับแอปพลิเคชัน แต่สิ่งที่เกี่ยวกับการออกแบบใหม่? ฉันอยู่ในทีมที่มอบหมายการออกแบบแอปพลิเคชันธุรกิจภายในใหม่ถึงแม้ว่าฉันจะพูดว่า "ภายใน" แต่ฉันก็ยังโชคร้ายที่มีคนจำนวนมากที่ไม่ได้ติดต่อกับผู้ใช้จริงของระบบ โปรแกรมปัจจุบันอยู่ใน Oracle Forms ซึ่งกระจายอยู่ในตารางที่ไม่ได้ถูกทำให้เป็นมาตรฐานซึ่งบางครั้งมีตารางที่ใกล้เคียงกันหลายชุดซึ่งมีข้อมูลที่แตกต่างกันเล็กน้อย ข้อ จำกัด มักจะอยู่ในรูปแบบของขั้นตอนการจัดเก็บที่มีการบังคับใช้ไม่ดี แม้แต่ประเภทก็ดูเหมือนจะไม่ถูกจัดเก็บไว้อย่างถูกต้อง ฉันพบข้อมูลที่ไม่ดีทุกประเภทที่ Oracle ดูเหมือนว่าจะเพิกเฉย แต่ได้ให้ตัวช่วยสร้างการนำเข้าและส่งออกของ SQL Server (และถูกต้องแล้ว) (ตัวอย่างเช่นจำนวนเต็มสองหลักไม่ได้เป็นการ datetime ที่สมบูรณ์!) โปรแกรมดั้งเดิมอาจย้อนกลับไปเมื่อยี่สิบปีที่แล้วและนักพัฒนาดั้งเดิมทั้งหมดได้เลิกใช้งานไปนานแล้วแม้แต่ผู้สูงอายุที่นี่ก็ยังไม่รู้เลยว่าพวกเขาเป็นใคร ด้วยเหตุนี้จึงไม่มีข้อกำหนดที่ชัดเจนใด ๆ ที่จะต้องกำจัด - เราเพียง แต่ควรทำซ้ำฟังก์ชันการทำงานของแอปพลิเคชันที่มีอยู่และเก็บข้อมูลที่มีอยู่ ผลลัพธ์สุดท้ายของการเขียนซ้ำจะเป็นเวอร์ชั่นที่ทำงานบนเว็บที่ทำงานบน ASP.NET พร้อมกับ MS SQL Server สำหรับด้านหลัง เพื่อนร่วมทีมนักพัฒนาซอฟต์แวร์อีกสองคนของฉันอายุมากกว่าฉันมากทั้งสองมีภูมิหลังทางธุรกิจ / MIS ในขณะที่ฉันเป็น CS ประสบการณ์ของสมาชิกอาวุโสนั้นเกือบจะเป็นรูปแบบของออราเคิลเท่านั้นและสมาชิกคนอื่น ๆ ส่วนใหญ่ได้ทำแอปพลิเคชันทางธุรกิจใน Visual Basic แม้ว่าพื้นหลังฐานข้อมูลของฉันจะถูก จำกัด ให้ออกแบบฐานข้อมูลใหม่สำหรับโครงการใน …

24 database-design  design