วิธีการลดการเชื่อมต่อแน่นระหว่างแหล่งข้อมูลสองแห่ง

10

ฉันมีปัญหาในการหาวิธีแก้ไขปัญหาสถาปัตยกรรมที่เหมาะสมต่อไปนี้

ในการตั้งค่าของเรา (ร่างด้านล่าง)เรามี 2 แหล่งข้อมูลโดยที่แหล่งข้อมูล A เป็นแหล่งข้อมูลหลักสำหรับรายการประเภท Foo แหล่งข้อมูลรองมีอยู่ซึ่งสามารถใช้เพื่อดึงข้อมูลเพิ่มเติมใน Foo; อย่างไรก็ตามข้อมูลนี้ไม่ได้มีอยู่เสมอ

นอกจากนี้แหล่งข้อมูล A สามารถใช้เพื่อดึงรายการประเภทบาร์ อย่างไรก็ตามแต่ละบาร์อ้างถึง Foo ความยากของที่นี่คือแต่ละแถบควรอ้างถึง Foo ซึ่งถ้ามีจะมีข้อมูลที่เพิ่มขึ้นโดยแหล่งข้อมูล B

คำถามของฉันคือวิธีลบข้อต่อแน่นระหว่าง SubsystemA.1 และ DataSourceB

architecture

— fstuijt
แหล่งที่มา

11

นั่นเป็นภาพร่างที่สวยงาม คุณใช้โปรแกรมอะไรในการวาด

— Marcelo MD

ฉันต้องการทราบว่าคุณใช้โปรแกรมใดในการวาด โปรด.

— Tulains Córdova

2

yuml.meเป็นเว็บไซต์ที่เขาใช้บ่อยกว่าจะสร้างไดอะแกรม

— Jason Turner

1

ไม่ได้DataSourceAและDataSourceBแยกชิ้นส่วนแล้ว? DataSourceAมีการพึ่งพาทั้งSubSystemA.1และแต่ไม่ได้อยู่ในSubSystemA.2 DataSourceB

— Tulains Córdova

1

@fstuijt ไม่มันไม่ใช่ หากคุณปรับเปลี่ยนSubsystemA.1เพื่อใช้อย่างอื่นที่นอกเหนือDataSourceBไปDataSourceAก็ไม่รู้ด้วยซ้ำ DataSourceAใส่ใจเฉพาะที่SubsystemA.1มีgetFoo(id)วิธีการ มีความเป็นนามธรรมระหว่างและDataSourceA DataSourceB

— Tulains Córdova

3

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

ความยาวและระยะสั้นคือแหล่งข้อมูลหนึ่งจำเป็นต้องมีการอ้างอิงไปยังระเบียนของอีกแหล่งหนึ่ง ในกรณีของเราข้อมูลคลาวด์ของบุคคลที่สามมีการอ้างอิงไปยังข้อมูลนอกสถานที่เพราะนั่นเป็นข้อตกลงที่เราควบคุมได้มากที่สุด ตอนนี้ด้วย ID สำหรับบันทึกจากแหล่งข้อมูลใดเราสามารถรับข้อมูลจากทั้งสอง ด้วย cloud ID เราจะดึงข้อมูลจากคลาวด์รับ ID ในสถานที่และดึงข้อมูลในสถานที่ ด้วย ID ในสถานที่เราทำการสำรวจแหล่งข้อมูลทั้งสองตามรหัสนั้น

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

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

การจัดเรียงแบบนี้จะต้องมีการเชื่อมโยงกันในบางระดับ คุณสามารถมี DAL ที่สามารถเชื่อมต่อกับที่เก็บข้อมูลทั้งสองหรือคุณสามารถแบ่งส่วน DAL หนึ่งอันต่อที่เก็บข้อมูลและมีเลเยอร์ที่สูงกว่าเช่นตัวควบคุมรับข้อมูลจากแต่ละแห่งและเก็บเข้าด้วยกัน แต่ในบางระดับโปรแกรมของคุณจะต้องมีสมาร์ทที่จะรวมข้อมูลสองอย่างนี้เข้าด้วยกัน

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

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

— Keiths
แหล่งที่มา

คำตอบนี้ครอบคลุมถึงปัญหาที่ฉันพบมากที่สุดและในความเห็นของฉันยังเสนอคำตอบที่ดีที่สุด อย่างไรก็ตามฉันคิดว่าการรวมข้อมูลจากหลาย ๆ แหล่งเป็นปัญหาที่พบบ่อย รูปแบบการออกแบบใด ๆ ที่อาจช่วยได้?

— fstuijt

1

รูปแบบบางอย่างในรูปแบบจากโรงงานอาจมีประโยชน์ หากคุณมีวัตถุ CloudInvoice และ SqlInvoice (จากแหล่งข้อมูลที่เกี่ยวข้อง) และคุณต้องการสร้างใบแจ้งหนี้แบบรวมศูนย์เดียวให้สร้างโรงงานที่มีความรู้เพียงพอเกี่ยวกับแหล่งข้อมูลทั้งสองเพื่อดึงข้อมูลครึ่งหนึ่งของระเบียนที่กำลังจะสร้าง ผสานข้อมูลเข้ากับคลาสโดเมนของคุณ

— KeithS

4

วิธีหนึ่งในการจัดการกับสิ่งนี้คือการสร้างแหล่งข้อมูลรวมที่มีข้อมูลจากแหล่งข้อมูลทั้งสองในที่เดียว งานจะทำงานเป็นระยะเพื่อตรวจสอบการเปลี่ยนแปลงในแหล่งที่มาAและBและเขียน "deltas" ลงในแหล่งข้อมูลรวมของคุณ สิ่งนี้จะแปลงแหล่งข้อมูลสองแหล่งที่เชื่อมโยงกันอย่างแน่นหนาเป็นแหล่งข้อมูลที่เชื่อมโยงกันเดียว

มีหลายสิ่งที่ทำให้คุณไม่สามารถใช้แนวทางนี้ได้:

จำนวนข้อมูลอาจถูกห้ามใช้ - สำเนาเต็มรูปแบบAและBจำเป็นต้องทำเพิ่มความต้องการพื้นที่เป็นสองเท่า
Data mus be live - จะมีช่วงเวลาระหว่างข้อมูลในแหล่งที่มีการเปลี่ยนแปลงและงานรวมได้แพร่กระจายไปยังแหล่งรวม
คุณต้องปรับข้อมูลให้ตรงกับแหล่งที่มาดั้งเดิม - งานในการย้ายการเปลี่ยนแปลงกลับสู่สถานที่เดิมจะมีความซับซ้อนมากขึ้นถ้าคุณใช้วิธีการนี้

— dasblinkenlight
แหล่งที่มา

ฉันเห็นด้วยการแนะนำเลเยอร์สิ่งที่เป็นนามธรรมเป็นวิธีที่ต้องการ

— neontapir

2

คุณสามารถมีเลเยอร์นามธรรมโดยไม่ต้องคัดลอกข้อมูล

— smp7d

@ smp7d นี่จะซ่อนคัปปลิ้งไว้ข้างหลังด้านหน้าที่ดี ฉันคิดว่าคุณได้ทำอะไรแบบนั้นในระบบของคุณอยู่แล้วเพราะมิฉะนั้นความซับซ้อนจะกระจายไปทั่วการออกแบบทั้งหมดของคุณ

— dasblinkenlight

ทั้งนี้ขึ้นอยู่กับสภาพแวดล้อมของฐานข้อมูลสิ่งนี้สามารถจัดการได้ด้วยมุมมองอย่างน้อยหนึ่งครั้งจึงไม่จำเป็นต้องคัดลอกข้อมูล

— วอลเตอร์

ไม่ได้DataSourceAและDataSourceBแยกชิ้นส่วนแล้ว? DataSourceAมีการพึ่งพาทั้งSubSystemA.1และแต่ไม่ได้อยู่ในSubSystemA.2 DataSourceB

— Tulains Córdova

1

ดูเหมือนว่าในระดับบนสุดมีสองประเภท: Foo และบาร์, และคุณมีเพียงสองการกระทำระดับบนสุด: และfindFoo(...) findBar(...)นั่นคืออินเทอร์เฟซสำหรับเลเยอร์ I / O

คำอธิบายของคุณของแหล่งข้อมูลแสดงให้เห็นว่ามีสองวิธีที่ A: findFooและfindBarและวิธีการหนึ่งใน findFooAuxiliaryInformationB: ในfindFooคุณจะต้องรวมข้อมูลจาก A และ B

ฉันไม่แน่ใจว่าคุณกำลังอ้างถึง มีสามประเภทข้อมูลที่มีอยู่ในทั้งสองชุดข้อมูลคือBar, และFoo FooAuxDataการเชื่อมต่อระหว่างFooและFooAuxDataมีอยู่ในข้อมูลอินพุตและไม่สามารถลดลงได้ แต่การมีเพศสัมพันธ์นั้นควรปรากฏในfindFooวิธีการเท่านั้น นั่นคือสิ่งที่ดีที่สุดที่คุณสามารถทำได้ ความต้องการจะดำเนินการในที่เดียว หากมีการเปลี่ยนแปลงคุณจะต้องเปลี่ยนรหัสนั้น

— เควินไคลน์
แหล่งที่มา

0

คุณทำไม่ได้

ถ้าผมเข้าใจอย่างถูกต้องFooและมาจาก Bar s เป็นของ โดยเฉพาะอย่างยิ่งคุณไม่ต้องการที่ได้รับมอบหมายให้s เว้นแต่ได้รับการเสริมด้วยที่มาจากdsABarFoo
BarFooFooFoo.enhancedInfodsB

การตั้งค่าของคุณสำหรับการกำหนดให้BarกับFoos คือสิ่งที่สร้างการมีเพศสัมพันธ์ของคุณแน่น ฉันจะผ่านการรับรองว่าเป็น "ความท้าทายด้านข้อกำหนด" ซึ่งบังคับให้คุณไปสู่เส้นทางที่เฉพาะเจาะจง

ดังนั้นความท้าทายทางเทคนิคคือdsBอาจมีหรือไม่มีข้อมูลเกี่ยวกับสิ่งที่ได้รับFooและdsBอาจไม่สามารถใช้ได้

คุณต้องตัดสินใจว่าการตั้งค่านั้นยากและรวดเร็วFoo.enhancedInfoเพียงใด ขึ้นอยู่กับข้อกำหนดนั้นคุณสามารถตัดสินใจว่าจะให้Foo+ Barวัตถุหรือไม่ การอนุญาตให้ผู้ที่ไม่ได้รับการปรับปรุงFooเพื่อให้ซับซ้อนเท่านั้นตรรกะและบอกฉันว่าการตั้งค่าไม่เข้มงวดเท่าที่อาจปรากฏ ตรวจสอบสิ่งที่แตกต่างของFoo, Foo.enhancedและBarโปรแกรมประยุกต์ของคุณ (s) สามารถรองรับและคุณจะได้คำตอบที่ดีที่สุดของคุณ

มีสิ่งอื่น ๆ ที่คุณสามารถทำได้เพื่อย้ายFooข้อมูลที่เกี่ยวข้องเข้าด้วยกันและอาจแก้ไขปัญหาเหล่านี้ได้ คำถามของคุณจะเป็นคำพูดดูเหมือนว่าคุณกำลังเผชิญปัญหาที่ระดับวัตถุข้อมูลและคุณอาจไม่สามารถพิจารณาการเปลี่ยนแปลงประเภทโครงสร้างพื้นฐานได้

อีกวิธีหนึ่ง 'รอบ: Foo s เป็นของ Bar s

— fstuijt

@fstuijt ฉันจะอัปเดตคำตอบของฉันในอีกสักครู่ พื้นฐานมันจะยังคงเหมือนเดิม คุณต้องตัดสินใจว่าคุณต้องการเซิร์ฟเวอร์ของ Bar + Foo อย่างไร

0

หากข้อมูลในแหล่งข้อมูล B ไม่สามารถยืนได้ด้วยตัวเองคุณอาจต้องการย้ายไปยังแหล่งข้อมูล A ถ้าเป็นไปได้

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

— smp7d
แหล่งที่มา