MongoDB数据库结构和最佳实践帮助

时间:2011-06-11 19:48:06

标签: mongodb database-design database

我正在为我的垃圾收集公司开发路线追踪/优化软件,并希望对我目前的数据结构/情况提供一些反馈。

以下是我的MongoDB结构的简化版本:

数据库:数据

类别:

“customers” - 包含所有客户数据的数据收集。

  [
    {
        "cust_id": "1001",
        "name": "Customer 1",
        "address": "123 Fake St",
        "city": "Boston"
    },
    {
        "cust_id": "1002",
        "name": "Customer 2",
        "address": "123 Real St",
        "city": "Boston"
        },
    {
        "cust_id": "1003",
        "name": "Customer 3",
        "address": "12 Elm St",
        "city": "Boston"
    },
    {
        "cust_id": "1004",
        "name": "Customer 4",
        "address": "16 Union St",
        "city": "Boston"
        },
    {
        "cust_id": "1005",
        "name": "Customer 5",
        "address": "13 Massachusetts Ave",
        "city": "Boston"
    }, { ... }, { ... }, ...
]

“卡车” - 包含所有卡车数据的数据收集。

[
    {
        "truckid": "21",
        "type": "Refuse",
        "year": "2011",
        "make": "Mack",
        "model": "TerraPro Cabover",
        "body": "Mcneilus Rear Loader XC",
        "capacity": "25 cubic yards"
    },
    {
        "truckid": "22",
        "type": "Refuse",
        "year": "2009",
        "make": "Mack",
        "model": "TerraPro Cabover",
        "body": "Mcneilus Rear Loader XC",
        "capacity": "25 cubic yards"
    },
    {
        "truckid": "12",
        "type": "Dump",
        "year": "2006",
        "make": "Chevrolet",
        "model": "C3500 HD",
        "body": "Rugby Hydraulic Dump",
        "capacity": "15 cubic yards"
    }
]

“drivers” - 包含所有驱动程序数据的数据收集。

  [
    {
        "driverid": "1234",
        "name": "John Doe"
    },
    {
        "driverid": "4321",
        "name": "Jack Smith"
    },
    {
        "driverid": "3421",
        "name": "Don Johnson"
    }
]

“route-lists” - 包含所有预定路线列表的数据收集。

   [
    {
        "route_name": "monday_1",
        "day": "monday",
        "truck": "21",
        "stops": [
            {
                "cust_id": "1001"
            },
            {
                "cust_id": "1010"
            },
            {
                "cust_id": "1002"
            }
        ]
    },
    {
        "route_name": "friday_1",
        "day": "friday",
        "truck": "12",
        "stops": [
            {
                "cust_id": "1003"
            },
            {
                "cust_id": "1004"
            },
            {
                "cust_id": "1012"
            }
        ]
    }
]

“routes” - 包含所有有效和已完成路线数据的数据集合。

[
    {
        "routeid": "1",
        "route_name": "monday1",
        "start_time": "04:31 AM",
        "status": "active",
        "stops": [
            {
                "customerid": "1001",
                "status": "complete",
                "start_time": "04:45 AM",
                "finish_time": "04:48 AM",
                "elapsed_time": "3"
            },
            {
                "customerid": "1010",
                "status": "complete",
                "start_time": "04:50 AM",
                "finish_time": "04:52 AM",
                "elapsed_time": "2"
            },
            {
                "customerid": "1002",
                "status": "incomplete",
                "start_time": "",
                "finish_time": "",
                "elapsed_time": ""
            },
            {
                "customerid": "1005",
                "status": "incomplete",
                "start_time": "",
                "finish_time": "",
                "elapsed_time": ""
            }
        ]
    }
]

到目前为止,这是一个过程:

每天司机都从开始新路线开始。在开始新路由之前,驱动程序必须首先输入数据:

  1. driverid
  2. 日期
  3. 卡车
  4. 正确输入所有数据后,将开始启动新路线:

    1. 在集合“路线”
    2. 中创建新对象
    3. “day” + “truck”匹配并返回“停止”查询集合“路线列表
    4. “路线列表”数据插入“路线”集合
    5. 当司机继续他的每日停止/任务时,“路线”集合将相应更新。

      完成所有任务后,驱动程序将能够通过简单地将“状态”字段从“路径”集合中的“完成”更改为“活动”来完成路径处理。

      总结一下。任何反馈,意见,评论,链接,优化策略都非常感谢。

      提前感谢您的时间。

1 个答案:

答案 0 :(得分:15)

您的数据库架构对我来说就像是“经典”关系数据库架构。 Mongodb非常适合数据非规范化。我想当你显示路线时,你装载所有相关的客户,司机,卡车。

如果你想让你的系统非常快,你可以将所有东西都嵌入到路线收集中。

所以我建议您对架构进行以下修改:

  1. 客户 - 原样
  2. 卡车 - 原样
  3. drivers - as-is
  4. 路由列表:

    在停靠点内嵌入有关客户的数据而不是引用。还嵌入卡车。在这种情况下,架构将是:

     {
         "route_name": "monday_1",
         "day": "monday",
         "truck": {
             _id = 1,
             // here will be all truck data
         },
         "stops": [{
             "customer": {
                 _id = 1,
                 //here will be all customer data
             }
         }, {
             "customer": {
                 _id = 2,
                 //here will be all customer data
             }
         }]
     }
    
  5. 路线:

    当驾驶员从路线列表开始新的路线复制路线时,另外还有嵌入的驾驶员信息:

     {
         //copy all route-list data (just make new id for the current route and leave reference to routes-list. In this case you will able to sync route with route-list.)
         "_id": "1",
         route_list_id: 1,
         "start_time": "04:31 AM",
         "status": "active",
         driver: {
             //embedd all driver data here
         },
         "stops": [{
             "customer": {
                 //all customer data
             },
             "status": "complete",
             "start_time": "04:45 AM",
             "finish_time": "04:48 AM",
             "elapsed_time": "3"
         }]
     }
    
  6. 我想你问自己,如果主要集合中的驱动程序,客户或其他非规范化数据发生了变化。是的,您需要更新其他集合中的所有非规范化数据。您可能需要更新数十亿个文档(取决于您的系统大小),这没关系。如果花费很多时间,你可以做异步。

    上述数据结构有什么好处?

    1. 每个文档都包含您可能需要在应用程序中显示的所有数据。因此,例如,当您需要显示路线时,您不需要加载相关的客户,司机,卡车。
    2. 您可以对数据库进行任何疑难查询。例如,在您的模式中,您可以构建查询,该查询将返回包含名称=“Bill”的客户停止时停止的所有路由(您需要先按名称加载客户,获取ID,并在当前模式中按客户ID查找)。
    3. 您可能会问自己,在某些情况下您的数据可能会不同步,但要解决此问题,您只需构建一些单元测试,以确保正确更新您的denormolized数据。

      从文档数据库的角度来看,希望以上将帮助您从非关系方面看世界。