有什么建议可以有效地将数据从一个数据库同步到其他应用程序的数据库吗?

发布于 2024-08-27 04:02:59 字数 1038 浏览 2 评论 0原文

这是我的问题。我构建了一个网络应用程序,自然地将数据保存在描述该应用程序域的数据库中。之后,我为同一组织构建了另一个 Web 应用程序,并使用单独的数据库来描述该应用程序的域并存储数据......自然地又出现了更多项目,对于每个应用程序,我将其数据隔离到单个数据库中。从开发角度来看,我认为这是可以的,因为我可以维护应用程序数据库中数据结构和数据的更改。

考虑到这些应用程序属于同一组织,它们之间往往会复制大量数据,例如部门名称、职位名称、商店名称等。这些表中的大多数都保存相同的数据,但在每个数据库中并不完全相同,并且并不总是被所有应用程序使用。然而,对这些数据的更改需要在所有应用程序上进行更改(有时以不同的方式),从而造成日益严重的管理“麻烦”。

所以我一直在想一种方法来实现数据之间的同步。我想要一种更简单的管理 - 在一个应用程序(或中央应用程序)上更新并根据每个应用程序的需要更新所有数据库 - 以及一种在应用程序之间共享数据的更好方法(例如可能将来自新应用程序中不同应用程序的数据混搭)以便具体分析)。我引用的大多数数据都用作约束,而不是核心域概念,描述组织而不是描述特定域。

我正在寻找有关完成此任务的一些方法的意见。

我的第一个想法是获取公共数据结构,例如我提到的部门名称表,并将它们保存在核心数据库中。对数据的任何更新都将通过专用的 Web 应用程序在此数据库中完成,并且我将为这些更改应用某种观察者或发布者/订阅者模式 - 在发生更改时,应用程序将通知观察应用程序(通过专用的 Web 服务)发生了更改并允许应用程序获取新数据并根据需要使用它。 GUID 可以作为用户的参考来识别整个应用程序中的相同数据。另外,我可以为读取和搜索操作构建 Web 服务,这些操作不需要位于特定应用程序的数据库中,但可能对其有用。

第二个想法是每个应用程序管理自己的数据,并且应用程序可以相互观察。其中一个更改可以通知共享发生更改的相同数据结构的其他人。我仍然可以使用一些 GUID,甚至可以在任何应用程序上构建服务。我认为这在数据重复方面也不会过度,但可能更难管理,因为每个应用程序最终都会与其他应用程序耦合,并且我会了解如何分配责任以决定哪个应用程序控制哪些信息。

我真的很好奇这种类型的数据分发和同步是否会起作用,甚至会被推荐。非常欢迎提出意见和其他想法!

Here's my problem. I built a web app, and naturally kept the data in a database which describes that app's domain. Afterwords, I built another web app for the same organization, and used a seperate database to describe that app's domain and store data... and naturally a couple more projects came up and for each app I've isolated it's data to a single database. Deveolpment wise, I think it's ok, as I can maintain changes to the data structure and data at the app's database.

Considering these apps belong to the same organization, there tends to be plenty of data replicated between them, like department names, job titles, shop names, etc. Most of these tables hold the same data, but are not exactly the same in each database, and are not always used by all of the apps. Changes to this data, though, needs to be changed at all the apps (sometimes in a diferent ways) creating a growing management "hassle".

So I've been think of a way to get some syncronization between the data. I want an easier management - update at one app (or a central app) and update all the databases as needed by each app - and also a better way to share data between apps (like maybe mash up data from differnt apps in a new app to alow specific analysis). Most of the data I'm refering to is used as contraints more than being core domain concept, describing the organization rather than describing a particular domain.

I'm looking for opinions on some ways to get this done.

My first idea was to grab comun data structures, like the department names' table i mentioned, and stick'em in a core database. Any updates to the data would be done at this database, through a dedicated web app, and I'd apply some sort of Observer or Publisher / Suscriber Pattern for these changes - on changes the app would notify observing apps (through there dedicated webservice) that the changes occured and allow for the app to grab the new data and use it as it needs. GUIDs could be user as a reference to identify the same data throughout the apps. Also, I could build web services for read and search operations that don't need to be in a specific app's database, but could be useful to it.

A second idea would be that each app manage it's own data, and the apps could observe one another. A change in one could notify others that share the same data structure that the change occurred. I could still use some GUIDs and even build services on any of the apps. I think this would also be less excessive in terms of duplication of data, but might be harder to manage as each app would eventually be coupled to other apps, and I would some how have to distribute responsabilities as to which app controls what information.

I'm really curious as to something of this genre of data distibuition and syncing would work and even be recomended. Opions and other ideas are more than welcome!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梨涡 2024-09-03 04:02:59

您在这里描述的是“主数据管理”系统的典型案例。 EAI 供应商(Oracle、TIBCO、IBM)提供此类产品。它们类似于您的第一个解决方案,是具有同步过程的集中式数据库,检测外部数据源中的更改,获取更改并将数据同步到其他外部数据库。他们还提供了一个用户界面来直接更改主数据。
MDM 软件价格昂贵,但您可以实施自定义解决方案,这比购买解决方案便宜(至少在最初是这样)。你们的两种解决方案都具有技术意义,但它们的可管理性有所不同。
第一个更好,如果您可以指定一个负责人/组织来处理它,并且您的服务的企业主可以同意通过这个新的集中式系统进行更改。
第二种解决方案在服务所有者之间分担责任。这里的艰巨任务是识别每种类型信息(业务对象)的所有者。
如果没有对您的系统和组织有更深入的了解,我无法提出解决方案,但我希望我可以提供一些想法。

What you describe here is a typical case for a "Master Data Management" system. EAI vendors (Oracle, TIBCO, IBM) offer such products. They resemble your first solution, being centralised databases with synchronization processes, detecting changes in external data sources, grabbing the changes and synchronizing data out to other external databases. They also provide a user interface to change master data directly.
MDM software are expensive, but you can implement a custom solution which will be - at least initially - cheaper than purchasing one. Both of your solutions make technical sense but there is a difference in their manageability.
The first one is better, if you can dedicate a responsible person/organization to take care of it and the business owners of your services can agree on making changes via this new centralised system.
The second solution shares the responsibility between the service owners. The hard task here is to identify the owner of each type of information (business object).
I cannot advise a solution without a deeper knowledge of your systems and organizations, but I hope I could give some ideas.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文