【问题标题】:Software-design & architecture: How to sync data from a directory-tree with a database软件设计与架构:如何将目录树中的数据与数据库同步
【发布时间】:2018-02-13 00:55:25
【问题描述】:

我现在有点头疼,还没有找到最终的解决方案。所以我希望我能找到一些关于如何在架构层面解决这个问题的交流或帮助。

我目前面临以下情况: 我想编写一个 Web 应用程序(我用 Java 做,但这与解决方案并不真正相关,因为这目前是一个更高级别的问题),其中存在这种关系:

Event --1:n--> Team --1:n--> Participant

含义:我有一个活动,其中将有多个团队,有多个参与者。到目前为止一切顺利 - 这将是 SQL 数据库中的一个简单关系。

但是还有一个目录树,表示文件结构中的相同关系:

+--event1
|  +--team1
|  |  +--participant1
|  |  +--participant2
|  |  +--participant3
|  +--team2
|  |  +--participant4
|  +--team3
+--event2
|  +--team4
...

(我想,你明白了) 因此,在每个参与者的目录中都有许多文件,这些文件通过文件系统复制到该目录中。每当文件系统上有一个目录时,它应该连接到数据库中的相应条目,其中有一些附加数据,应该与 web-GUI 中的文件一起显示。没有定义,首先会有什么(数据库入口或目录),因为这是由不同的用户操作的。

现在有几件事要记住,这对我来说有点道理:

  • 当目录名称更改(事件、团队或参与者)时,它仍应与数据库中的同一条目相关(因为可能存在其他实体,例如仍与参与者相关)
  • 可能会删除任何事件/团队/参与者的目录 - 数据库中的数据应该保留。但是 - 如果稍后再次创建具有相同名称的新目录并且事件被“关闭”,则该目录将指向新的数据库条目(例如新事件)。如果事件仍处于活动状态,则创建同名目录应映射到数据库中先前分配的条目。
  • 理想情况下,目录的创建已经导致相应数据库条目的创建。
  • 还应该可以在 web-GUI 中创建事件/团队/参与者,然后自动在文件系统上创建相应的目录。

我希望我的描述足以理解这个场景。我已经想到了一些事情,但他们并没有真正说服自己成为一个强大的解决方案。所以希望你们中的一个人已经对此有所了解。我对任何可能有助于解决这个问题的技术或框架持开放态度。

我期待您的想法和愉快的讨论!

感谢您的帮助!

【问题讨论】:

    标签: architecture modeling software-design data-synchronization


    【解决方案1】:

    首先必须设计目录的唯一性。 您是否考虑在每个监视目录中使用包含唯一键的隐藏文件? 如果没有高负载系统,可能会使用创建时间。

    在文件系统中拥有唯一键,在数据库中反映现有的唯一键并组织两个存储之间的同步并不难。

    【讨论】:

      【解决方案2】:

      我要考虑的第一个原则是拥有“单一来源”。事件/团队/参与者的名称(人类可读的名称)在哪里?进入数据库还是进入文件系统?

      第二个原则:您写了关于“数据库条目”和“文件”的文章,但这些只是您域信息的代表。首先设计数据模型,然后可以组织您的数据源以反映该模型

      总而言之,您可以为域模型中的实体分配唯一的不可变 ID。将名称命名为实体的普通属性,然后按照所列实施您的业务规则。您将模型实现为 DS 和文件结构,您将通过存储库访问它们,该存储库对数据应用相同的突变,保持同步最小共享知识,如 ids

      但我仍然怀疑您使用的资源太多。您确定仅使用 DB 或仅使用 filsystem 不合适吗?

      【讨论】:

        【解决方案3】:

        使用名称如.meta 的隐藏文件来包含一些数据库信息,至少是文件夹的 ID,并有一个后台进程(守护进程)每 X 秒扫描一次目录层次结构,比较其中的内容数据库中的内容,并进行必要的调整。在文件系统上被删除的东西会在数据库中获得一个“已删除”标志,被重命名的东西在数据库中的名称会发生​​变化,需要添加的任何东西都会被插入,此外,如果曾经删除过的文件夹被重新创建,删除“已删除”标志并在目录中重新创建子文件。

        或者,如果这将是一个 NFS 驱动器或类似的东西,请考虑使用轻量级后端来模拟文件系统,该后端将删除、重命名和文件创建操作转换为数据库命令。然后,您只需要担心一组数据的完整性,并且网络应用程序和文件布局会自动保持同步(不需要守护程序)。

        【讨论】:

        • 软删除是一种有趣的方法:它符合要求,因为事件数据在删除后并未完全“忘记”。不过,我看到了一种设计味道,并且应用程序可以直接改变文件结构这一事实,同时会有一个数据源抽象(简而言之,一个存储库)将强制每个突变都应与数据库数据保持一致.文件系统访问 API 将只是 HTTP/REST api,用于摄取“eventId”聚合下的文件
        猜你喜欢
        • 2012-08-27
        • 2014-08-28
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-08-05
        • 1970-01-01
        • 2023-04-01
        • 1970-01-01
        相关资源
        最近更新 更多