实体联系模型是什么

首先，我们先来聊聊各类数据模型。下列相关信息参考自Emil Eifrem的博文及NoSQL数据库说明。文档类数据库传承:受Lotus Notes启发而来。数据模型:文档汇总，包括键-值汇总。实例: CouchDB, MongoDB优势: 数据建模自然、程序员易于上手、开发流程短、兼容网页模式、便于达成CRUD（即添加、查询、更新及删除的简称）。图形类数据库传承:来自 Euler 及图形理论。数据模型:节点及关系，二者结合能够保持键-值间的成对状态实例: AllegroGraph, InfoGrid, Neo4j优势:轻松玩转复杂的图形问题、处理速度快关系类数据库传承:源自 E. F. Codd在大型共享数据库中所提出的数据关系模型理论数据模型:以关系组为基础实例: VoltDB, Clustrix, MySQL优势:性能强大、联机事务处理系统扩展性好、支持SQL访问、视图直观、擅长处理交易关系、与程序员间的交互效果优异面向对象类数据库传承:源自图形数据库方面的研究成果数据模型: 对象实例: Objectivity, Gemstone优势:擅长处理复杂的对象模型、快速的键-值访问及键-功能访问并且兼具图形数据库的各类功能键-值存储传承: Amazon Dynamo中的paper概念及分布式hash表数据模型:对成对键-值的全局化汇总实例: Membase, Riak优势:尺寸掌控得当、擅长处理持续的小规模读写需求、速度快、程序员易于上手BigTable Clones传承自:谷歌BigTable中的paper概念数据模型:纵列群，即在某个表格模型中，每行在理论上至少可以有一套单独的纵列配置实例: HBase, Hypertable, Cassandra优势:尺寸掌控得当、擅长应对大规模写入负载、可用性高、支持多数据中心、支持映射简化数据结构类服务传承: 不明实例: Redis数据模型: 执行过程基于索引、列表、集合及字符串值优势:为数据库应用引入前所未有的新鲜血液网格类数据库传承:源自数据网格及元组空间研究数据模型:基于空间的构架实例: GigaSpaces, Coherence优势:优良的性能表现及上佳的交易处理扩展性我们该为自己的应用程序选择哪套方案？选择的关键在于重新思考我们的应用程序如何依据不同数据模型及不同产品进行有针对性的协同工作。即用正确的数据模型处理对应的现实任务、用正确的产品解决对应的现实问题。要探究哪类数据模型能够切实为我们的应用程序提供帮助，可以参考“到底NoSQL能在我们的工作中发挥什么作用？”一文。在这篇文章中，我试着将各种不同特性、不同功能的常用创建系统中的那些非常规的应用实例综合起来。将应用实例中的客观需求与我们的选择联系起来。这样大家就能够逆向分析出我们的基础架构中适合引入哪些产品。至于具体结论是NoSQL还是SQL，这已经不重要了。关注数据模型、产品特性以及自身需要。产品总是将各种不同的功能集中起来，因此我们很难单纯从某一类数据模型构成方式的角度直接找到最合用的那款。对功能及特性的需求存在优先级，只要对这种优先级具备较为清晰的了解，我们就能够做出最佳选择。如果我们的应用程序需要…复杂的交易：因为没人愿意承受数据丢失，或者大家更倾向于一套简单易用的交易编程模式，那么请考虑使用关系类或网格类数据库。例如:一套库存系统可能需要完整的ACID（即数据库事务执行四要素：原子性、一致性、隔离性及持久性）。顾客选中了一件产品却被告知没有库存了，这类情况显然容易引起麻烦。因为大多数时候，我们想要的并不是额外补偿、而只是选中的那件货品。若是以扩展性为优先，那么NoSQL或SQL都能应对自如。这种情况下我们需要关注那些支持向外扩展、分类处理、实时添加及移除设备、负载平衡、自动分类及整理并且容错率较高的系统。要求持续保有数据库写入功能，则需要较高的可用性。在这种情况下不妨关注BigTable类产品，其在一致性方面表现出众。如有大量的小规模持续读写要求，也就是说工作负载处于波动状态，可以关注文档类、键-值类或是那些提供快速内存访问功能的数据库。引入固态硬盘作为存储媒介也是不错的选择。以社交网络为实施重点的话，我们首先想到的就是图形类数据库；其次则是Riak这种关系类数据库。具备简单SQL功能的常驻内存式关系数据库基本上就可以满足小型数据集合的需求。Redis的集合及列表操作也能发挥作用。如果我们的应用程序需要…在访问模式及数据类型多种多样的情况下，文档类数据库比较值得考虑。这类数据库不仅灵活性好，性能表现也可圈可点。需要完备的脱机报告与大型数据集的话，首选产品是Hadoop，其次则是支持映射简化的其它产品。不过仅仅支持映射简化还不足以提供如Hadoop一样上佳的处理能力。如果业务跨越数个数据中心，Bigtable Clone及其它提供分布式选项的产品能够应对由地域距离引起的延迟现象，并具备较好的分区兼容性。要建立CRUD应用程序，首选文档类数据库。这类产品简化了从外部访问复杂数据的过程。需要内置搜索功能的话，推荐Riak。要对数据结构中的诸如列表、集合、队列及发布/订阅信息进行操作，Redis是不二之选。其具备的分布式锁定、覆盖式日志及其它各种功能都会在这类应用状态下大放异彩。将数据以便于处理的形式反馈给程序员（例如以JSON、HTTP、REST、Javascript这类形式），文档类数据库能够满足这类诉求，键-值类数据库效果次之。如果我们的应用程序需要…以直观视图的形式进行同步交易，并且具备实时数据反馈功能，VoltDB算得上一把好手。其数据汇总以及时间窗口化的表现都非常抢眼。若是需要企业级的支持及服务水平协议，我们需要着眼于特殊市场。Membase就是这样一个例子。要记录持续的数据流，却找不到必要的一致性保障？BigTable Clone交出了令人满意的答卷，因为其工作基于分布式文件系统，所以可以应对大量的写入操作。要让操作过程变得尽可能简单，答案一定在托管或平台即服务类方案之中。它们存在的目的正是处理这类要求。要向企业级客户做出推荐？不妨考虑关系类数据库，因为它们的长项就是具备解决繁杂关系问题的技术。如果需要利用动态方式建立对象之间的关系以使其具有动态特性，图形类数据库能帮上大忙。这类产品往往不需要特定的模式及模型，因此可以通过编程逐步建立。S3这类存储服务则是为支持大型媒体信息而生。相比之下NoSQL系统则往往无法处理大型二进制数据块，尽管MongoDB本身具备文件服务功能。如果我们的应用程序需要…有高效批量上传大量数据的需求？我们还是得找点有对应功能的产品。大多数产品都无法胜任，因为它们不支持批量操作。文档类数据库或是键－值类数据库能够利用流畅的模式化系统提供便捷的上传途径，因为这两类产品不仅支持可选区域、添加区域及删除区域，而且无需建立完整的模式迁移框架。要实现完整性限制，就得选择一款支持SQL DLL的产品，并在存储过程或是应用程序代码中加以运行。对于协同工作极为依赖的时候就要选择图形类数据库，因为这类产品支持在不同实体间的迅速切换。数据的移动距离较短且不必经过网络时，可以在预存程序中做出选择。预存程序在关系类、网格类、文档类甚至是键-值类数据库中都能找到。如果我们的应用程序需要…键-值存储体系擅长处理BLOB类数据的缓存及存储问题。缓存可以用于应对网页或复杂对象的存储，这种方案能够降低延迟、并且比起使用关系类数据库来说成本也较低。对于数据安全及工作状态要求较高的话可以尝试使用定制产品，并且在普遍的工作范畴（例如向上扩展、调整、分布式缓存、分区及反规范化等等）之外一定要为扩展性（或其它方面）准备解决方案。多样化的数据类型意味着我们的数据不能简单用表格来管理或是用纵列来划分，其复杂的结构及用户组成（也可能还有其它各种因素）只有文档类、键-值类以及Bigtable Clone这些数据库才能应付。上述各类数据库都具备极为灵活的数据类型处理能力。有时其它业务部门会需要进行快速关系查询，引入这种查询方式可以使我们不必为了偶尔的查看而重建一切信息。任何支持SQL的数据库都能实现这类查询。至于在云平台上运行并自动充分利用云平台的功能——这种美好的愿望目前还只能是愿望。如果我们的应用程序需要…支持辅助索引，以便通过不同的关键词查找数据，这要由关系类数据库及Cassandra推出的新辅助索引系统共同支持才能实现。创建一套处于不断增长中的数据集合（真正天文数量级的数据）然而访问量却并不大，那么Bigtable Clone是最佳选择，因为它会将数据妥善安排在分布式文件系统当中。需要整合其它类型的服务并确保数据库提供延后写入同步功能？那最好的实现方式是捕捉数据库的各种变化并将其反馈到其它系统中以保障运作的一致性。通过容错性检查了解系统对供电中断、隔离及其它故障情况的适应程度。若是当前的某项技术尚无人问津、自己却感觉大有潜力可挖，不妨在这条路上坚持走下去。这种情况有时会带来意料之外的美好前景。尝试在移动平台上工作并关注CouchDB及移动版couchbase。哪种方案更好？25%的状态改善尚不足以让我们下决心选择NoSQL。选择标准是否恰当取决于实际情况。这类标准对你的方案有指导意义吗？如果你的公司尚处于起步阶段，并且需要尽快推出自己的产品，这时不要再犹豫不决了。无论是SQL还是NoSQL都可以作为参考。

转自：阿里云官网 — 知乎 写好代码，阿里专家沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家，相信同样的方法论可以复制到大部分复杂业务场景。 一文教会你如何写复杂业务代码 了解我的人都知道，我一直在致力于应用架构和代码复杂度的治理。 这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景，如何在架构和代码层面进行应对，是一个新课题。针对该命题，我进行了比较细致的思考和研究。结合实际的业务场景，我沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家。 我相信，同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业务背景，零售通是给线下小店供货的B2B模式，我们希望通过数字化重构传统供应链渠道，提升供应链效率，为新零售助力。阿里在中间是一个平台角色，提供的是Bsbc中的service的功能。 在商品域，运营会操作一个“上架”动作，上架之后，商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一，因此涉及很多的数据校验和关联操作。 针对上架，一个简化的业务流程如下所示： 过程分解 像这么复杂的业务，我想应该没有人会写在一个service方法中吧。一个类解决不了，那就分治吧。 说实话，能想到分而治之的工程师，已经做的不错了，至少比没有分治思维要好很多。我也见过复杂程度相当的业务，连分解都没有，就是一堆方法和类的堆砌。 不过，这里存在一个问题：即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中，类似的分解手段至少有3套以上，有自制的流程引擎，有依赖于数据库配置的流程处理： 本质上来讲，这些辅助手段做的都是一个pipeline的处理流程，没有其它。因此，我建议此处最好保持KISS（Keep It Simple and Stupid），即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。 除非你的应用有极强的流程可视化和编排的诉求，否则我非常不推荐使用流程引擎等工具。第一，它会引入额外的复杂度，特别是那些需要持久化状态的流程引擎；第二，它会割裂代码，导致阅读代码的不顺畅。大胆断言一下，全天下估计80%对流程引擎的使用都是得不偿失的。 回到商品上架的问题，这里问题核心是工具吗？是设计模式带来的代码灵活性吗？显然不是，问题的核心应该是如何分解问题和抽象问题，知道金字塔原理的应该知道，此处，我们可以使用结构化分解将问题解构成一个有层级的金字塔结构： 按照这种分解写的代码，就像一本书，目录和内容清晰明了。以商品上架为例，程序的入口是一个上架命令（OnSaleCommand）, 它由三个阶段（Phase）组成。 @Command public class OnSaleNormalItemCmdExe { @Resource private OnSaleContextInitPhase onSaleContextInitPhase; @Resource private OnSaleDataCheckPhase onSaleDataCheckPhase; @Resource private OnSaleProcessPhase onSaleProcessPhase; @Override public Response execute(OnSaleNormalItemCmd cmd) { OnSaleContext onSaleContext = init(cmd); checkData(onSaleContext); process(onSaleContext); return Response.buildSuccess(); } private OnSaleContext init(OnSaleNormalItemCmd cmd) { return onSaleContextInitPhase.init(cmd); } private void checkData(OnSaleContext onSaleContext) { onSaleDataCheckPhase.check(onSaleContext); } private void process(OnSaleContext onSaleContext) { onSaleProcessPhase.process(onSaleContext); } } 每个Phase又可以拆解成多个步骤（Step），以OnSaleProcessPhase为例，它是由一系列Step组成的： @Phase public class OnSaleProcessPhase { @Resource private PublishOfferStep publishOfferStep; @Resource private BackOfferBindStep backOfferBindStep; //省略其它step public void process(OnSaleContext onSaleContext){ SupplierItem supplierItem = onSaleContext.getSupplierItem(); // 生成OfferGroupNo generateOfferGroupNo(supplierItem); // 发布商品 publishOffer(supplierItem); // 前后端库存绑定 backoffer域 bindBackOfferStock(supplierItem); // 同步库存路由 backoffer域 syncStockRoute(supplierItem); // 设置虚拟商品拓展字段 setVirtualProductExtension(supplierItem); // 发货保障打标 offer域 markSendProtection(supplierItem); // 记录变更内容ChangeDetail recordChangeDetail(supplierItem); // 同步供货价到BackOffer syncSupplyPriceToBackOffer(supplierItem); // 如果是组合商品打标，写扩展信息 setCombineProductExtension(supplierItem); // 去售罄标 removeSellOutTag(offerId); // 发送领域事件 fireDomainEvent(supplierItem); // 关闭关联的待办事项 closeIssues(supplierItem); } } 看到了吗，这就是商品上架这个复杂业务的业务流程。需要流程引擎吗？不需要，需要设计模式支撑吗？也不需要。对于这种业务流程的表达，简单朴素的组合方法模式（Composed Method）是再合适不过的了。 因此，在做过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的阶段（Phase）和步骤（Step）上。 过程分解后的两个问题的确，使用过程分解之后的代码，已经比以前的代码更清晰、更容易维护了。不过，还有两个问题值得我们去关注一下： 1、领域知识被割裂肢解什么叫被肢解？ 因为我们到目前为止做的都是过程化拆解，导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程，知识没有沉淀。相同的业务逻辑会在多个Use Case中被重复实现，导致代码重复度高，即使有复用，最多也就是抽取一个util，代码对业务语义的表达能力很弱，从而影响代码的可读性和可理解性。 2、代码的业务表达能力缺失 试想下，在过程式的代码中，所做的事情无外乎就是取数据--做计算--存数据，在这种情况下，要如何通过代码显性化的表达我们的业务呢？ 说实话，很难做到，因为我们缺失了模型，以及模型之间的关系。脱离模型的业务表达，是缺少韵律和灵魂的。 举个例子，在上架过程中，有一个校验是检查库存的，其中对于组合品（CombineBackOffer）其库存的处理会和普通品不一样。原来的代码是这么写的： boolean isCombineProduct = supplierItem.getSign().isCombProductQuote(); // supplier.usc warehouse needn't check if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) { // quote warehosue check if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！"); } // inventory amount check Long sellableAmount = 0L; if (!isCombineProduct) { sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList()); } else { //组套商品 OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId()); if (backOffer != null) { sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale(); } } if (sellableAmount < 1) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + supplierItem.getId() + "]"); } } 然而，如果我们在系统中引入领域模型之后，其代码会简化为如下： if(backOffer.isCloudWarehouse()){ return; } if (backOffer.isNonInWarehouse()){ throw new BizException("亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！"); } if (backOffer.getStockAmount() < 1){ throw new BizException("亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]"); } 有没有发现，使用模型的表达要清晰易懂很多，而且也不需要做关于组合品的判断了，因为我们在系统中引入了更加贴近现实的对象模型（CombineBackOffer继承BackOffer），通过对象的多态可以消除我们代码中的大部分的if-else。 过程分解+对象模型 通过上面的案例，我们可以看到有过程分解要好于没有分解，过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case，如果采用过程分解+对象模型的方式，最终我们会得到一个如下的系统结构： 写复杂业务的方法论 通过上面案例的讲解，我想说，我已经交代了复杂业务代码要怎么写：即自上而下的结构化分解+自下而上的面向对象分析。 接下来，让我们把上面的案例进行进一步的提炼，形成一个可落地的方法论，从而可以泛化到更多的复杂业务场景。 上下结合 所谓上下结合，是指我们要结合自上而下的过程分解和自下而上的对象建模，螺旋式的构建我们的应用系统。这是一个动态的过程，两个步骤可以交替进行、也可以同时进行。这两个步骤是相辅相成的，上面的分析可以帮助我们更好的理清模型之间的关系，而下面的模型表达可以提升我们代码的复用度和业务语义表达能力。其过程如下图所示： 使用这种上下结合的方式，我们就有可能在面对任何复杂的业务场景，都能写出干净整洁、易维护的代码。 能力下沉 一般来说实践DDD有两个过程： 1. 套概念阶段 了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bonded Context，Repository等等这些概念。更进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。 2. 融会贯通阶段 术语已经不再重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。 大体上而言，我大概是在1.7的阶段，因为有一个问题一直在困扰我，就是哪些能力应该放在Domain层，是不是按照传统的做法，将所有的业务都收拢到Domain上，这样做合理吗？说实话，这个问题我一直没有想清楚。 因为在现实业务中，很多的功能都是用例特有的（Use case specific）的，如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反，这种收拢会导致Domain层的膨胀过厚，不够纯粹，反而会影响复用性和表达能力。 鉴于此，我最近的思考是我们应该采用能力下沉的策略。 所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制要求把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了。 注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程 通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。 下沉的过程如下图所示，假设两个use case中，我们发现uc1的step3和uc2的step1有类似的功能，我们就可以考虑让其下沉到Domain层，从而增加代码的复用性。 指导下沉有两个关键指标：代码的复用性和内聚性。 复用性是告诉我们When（什么时候该下沉了），即有重复代码的时候。 内聚性是告诉我们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另一个是Domain的Model这个是最细粒度的复用）。 比如，在我们的商品域，经常需要判断一个商品是不是最小单位，是不是中包商品。像这种能力就非常有必要直接挂载在Model上。 public class CSPU { private String code; private String baseCode; //省略其它属性 /** * 单品是否为最小单位。 * */ public boolean isMinimumUnit(){ return StringUtils.equals(code, baseCode); } /** * 针对中包的特殊处理 * */ public boolean isMidPackage(){ return StringUtils.equals(code, midPackageCode); } } 之前，因为老系统中没有领域模型，没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的，至少我在第一眼看到这个代码的时候，是完全不知道什么意思。 业务技术要怎么做 写到这里，我想顺便回答一下很多业务技术同学的困惑，也是我之前的困惑：即业务技术到底是在做业务，还是做技术？业务技术的技术性体现在哪里？ 通过上面的案例，我们可以看到业务所面临的复杂性并不亚于底层技术，要想写好业务代码也不是一件容易的事情。 业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如，如果你需要去开发Pandora，你就要对Classloader有更加深入的了解才行。 但是，不管是业务技术还是底层技术人员，有一些思维和能力都是共通的。比如，分解问题的能力，抽象思维，结构化思维等等。 用我的话说就是：“做不好业务开发的，也做不好技术底层开发，反之亦然。业务开发一点都不简单，只是我们很多人把它做“简单”了因此，如果从变化的角度来看，业务技术的难度一点不逊色于底层技术，其面临的挑战甚至更大。 因此，我想对广大的从事业务技术开发的同学说：沉下心来，夯实自己的基础技术能力、OO能力、建模能力... 不断提升抽象思维、结构化思维、思辨思维... 持续学习精进，写好代码。我们可以在业务技术岗做的很”技术“！。

数据库课程设计 “数据库课程设计”是数据库系统及应用课程的后续实验课，是进一步巩固学生的数据库知识，加强学生的实际动手能力和提高学生综合素质。 一、 课程设计目的 课程设计为学生提供了一个既动手又动脑，独立实践的机会，将课本上的理论知识和实际有机的结合起来，锻炼学生的分析解决实际问题的能力。提高学生适应实际，实践编程的能力。课程设计的目的： 1. 加深对数据库原理、程序设计语言的理论知识的理解和应用水平； 2. 在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高； 3. 学会将知识应用于实际的方法，提高分析和解决问题的能力，增强动手能力； 4. 为毕业设计和以后工作打下必要基础。 二、课程设计要求 运用数据库原理的基本理论与应用知识，在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型，再转换为机器世界的数据模型和数据文件，并对数据文件实施检索、更新和控制等操作。 1. 用E-R图设计选定题目的信息模型； 2. 设计相应的关系模型，确定数据库结构； 3. 分析关系模式各属于第几范式，阐明理由； 4. 设计应用系统的系统结构图，确定系统功能； 5. 通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制； 6. 为参照关系设计插入、删除、修改触发器； 7. 实现应用程序设计、编程、优化功能； 8. 对系统的各个应用程序进行集成和调试，进一步优化系统功能、改善系统用户界面完成实验内容所指定的各项要求； 9. 分析遇到的问题，总结并写出课程设计报告； 10. 自我评价 三、实验环境 开发环境VC++、C#、ASP或JAVA；ODBC/JDBC；数据库SQL Server 四、上机实现内容 1. 创建数据库的结构 2. 创建各基本表的结构 3. 编制系统各功能模块，完成数据的管理（增、删、改）及统计查询。对于程序运行界面不做考核的重点。 五、课程设计考核 1.对学生到实验室的情况进行不定时统计； 2.出勤率+课程设计报告+课程设计所开发的应用系统+其他（上机抽查和提问）=综合评定成绩。 3.课程设计结束时请将下列资料上交： （1） 课程设计报告； （2） 所开发的应用系统的源程序、安装和使用说明； （3） 将（1）（2）中的资料压缩成一个压缩包，压缩包文件的命名规则：班级+学号（末2位）+姓名（例如：计科090101王鹏晓）； （4） 班长将本班每人的（3）中的压缩包刻录成光盘连同打印的课程设计报告收齐，交给任课教师。 附录﹑课程设计题目 题目1：课程设计选题管理系统（1，24） 包括三大模块：  课程设计题目维护与查询：题目的添加、修改和删除；按题目类型、名称和关键字查询以及已选与未选题目的查询；  学生信息维护与查询；  学生选题维护与管理：学生选题及查询； 具体功能细化：  前台学生选题：学生上网登录系统进行选题；  前台教师出题：  教师添加、修改和删除题目；  教师确认学生的选题；  后台管理出题和选题  添加用户及权限 题目2：书店管理系统（23） 包括四大模块：  售书（图书销售管理及销售统计，查询）  进书（通过书目，向发行商下定单订购图书）  库存（图书库存，统计）  相关查询 题目3：图书馆管理系统（11） 包括四大模块：  图书的查询  借书  还书  图书的预约 题目4：库存管理系统（8） 包括四大模块：  商品目录建立  商品入库管理  商品出库管理  商品库存查询 题目5：工资管理系统（1 人）41 包括四大模块：  系统数据初始化  员工基本信息数据的输入、修改、删除；  员工个人信息及工资表的查询；  员工工资的计算； 参考数据如下：  员工基本状况：包括员工号、员工姓名、性别、所在部门、工资级别、工资等级等。  工资级别和工资金额：包括工资等级、工资额。  企业部门及工作岗位信息：包括部门名称、工作岗位名称、工作岗位工资等。  工龄和工资金额：包括工龄及对应工资额。  公司福利表：包括福利名称、福利值。  工资信息：包括员工号、员工姓名、员工基础工资、员工岗位工资、员工工龄工资、公司福利、员工实得工资。 题目6：酒店客房管理系统 （1 人）14，26 包括四大模块：  前台操作：包括开房登记、退房结账和房状态查看  预订管理：包括预订房间、预订入住和解除预订  信息查询：包括在住客人列表、预订客人列表和历史客人列表  报表统计：包括开房记录统计、退房结账和预订房间统计  员工基本信息数据的输入、修改、删除； 参考数据如下：  住店管理：客人姓名、证件号码、房号、入住时期、预计离开日期、结账离开日期、应付金额  客人信息：姓名、性别、证件类型、证件号码、联系电话  房间信息：房号、房类型、价格、押金、房状态 预订房间  客人姓名、性别、房类型、房号、价格、证件类型、证件号码、联系电话、入住日期、预计离开日期、历史信息 题目7：旅行社管理信息系统（1 人）3 包括如下模块：  旅游团队、团队团员及旅游路线相关信息的输入  旅游团队、团队团员及旅游路线相关信息的维护（修改、浏览、删除和撤销）  旅游团队管理信息的查询（如按团队编号）  团队团员基本情况的查询（可选多种方式）  旅游路线相关信息的查询（如按线路编号）  旅游路线排行榜发布。  数据备份，更改密码。 参考数据如下：  团员信息表（路线编号，团队编号，团员编号，姓名，性别，电话，通信地址，身份证号码， 团费交否，备注）  线路信息表（路线名称，团费，简介，图形，路线编号）  团队信息表（团队编号，路线编号，团员人数，出发日期，返程日期）  旅游团队信息表（团队编号，团队负责人，团员人数，建团时间，是否出发，团费，盈亏） 密码信息（操作员，密码） 题目8：报刊订阅管理系统 （1 人）25，35 包括如下模块：  登录功能：登录统为身份验证登录。分为管理员登录和一般用户登录。分别通过不 同的用户名和密码进入报刊订阅管理界面，新的用户需要注册。  录入新信息功能：对于管理员，包括新用户信息和新报刊信息的录入功能，信息一旦 提交就存入到后台数据库中；普通用户自行注册进行可以修改个人信息。  订阅功能：用户可以订阅报刊，系统自动计算所需金额，并显示在界面上；管理员不 可订阅报刊，必须以用户身份订阅报刊。  查询功能：用户可以查询并显示自己所订阅的信息；管理员可以按人员、报刊、部门 分类查询。查询出的信息显示在界面上,并且可以预览和打印出结果。  统计功能：管理员可以按用户、部门、报刊统计报刊的销售情况，并对一些重要的订 阅信息进行统计；普通用户可以统计出自己的订阅情况，并且可以预览和打印出结果。  系统维护功能：数据的安全管理，主要是依靠管理员对数据库里的信息进行备份和恢 复，数据库备份后，如果出了什么意外可以恢复数据库到当时备份的状态，这提高了系统和 数据的安全性，有利于系统的维护 参考数据如下：  管理员表（Adminuser） ：管理员名、密码。  部门表（Department） ：部门号，部门名。  用户表（Users） ：用户账号、密码、真实姓名、身 份证号、联系电话，联系地址，部门号（和部门表有关）等。  报刊类别表（NewspaperClass） ：分类编号、 分类名称。  报刊信息表（Newspaper） ：报刊代号、报刊名称、出版 报社、出版周期、季度报价、内容介绍、分类编号（和报刊类别表有关）等。  订单表（Order） ：订单编号、用户编号、报刊代号、订阅份数、订阅月数等。 题目9：计算机等级考试教务管理系统（2 人）32 包括四大模块：  用户设置：对考点代码，考点名称进行设置，设置用户与密码；系统复位：即清除上一次考试数据（在之前存入历史）  报名管理： 报各库录入（姓名不能不空，之间不能有空格） 增加、删除、修改、浏览  准考证管理：准考证生成规则：xxx+yy+zz+kk，其中 XXX 为考点代码；YY 为语言代码，XX 为考场号，KK 为座位号 同一级别、语言应根据报名初始库信息按随机数生成准考证，同一考点最多可有 99*30=2970 名考生；如已生成准考证号，再重新生成准考证号，应该给予提示。 准考证打印  考务管理：考生信息查询、浏览、打印  成绩管理：成绩数据录入、接收 成绩合成（总成绩=笔试成绩*0.6+上机成绩*0.4）,按大于或等于 60 合格 参考数据如下：  初始报名表（准考证号（为空） ，报名号（主键） ，级别+语言种类（外键） ，姓名，性别， 出生年份，民族，身份证号，联系地址，联系电话，照片，备注，参加培训）  含准考证号的报名表（准考证号（为主键） ，报名号，级别+语言种类（外键） ，姓名，性别， 出生年份，民族，身份证号，联系地址，联系电话，照片，备注，参加培训）  成绩表（准考证号，笔试成绩，上机成绩，总成绩） 级别语言代码表（级别语言代码，级别+语言）  用户信息表（考点代码，考点名称，用户名，密码） 题目10：人事管理系统（1 人）21 包括四大模块：  登录管理：包括操作员管理，口令设置，权限管理  人员管理：包括人事数据维护、人事信息查询和人事信息统计  工资管理  部门管理：包括部门表，职称表和年份表  查询及报表打印 参考数据如下：  人事表（编号，姓名，性别，出生日期，工作日期，部门代码，职称，婚否，简历，相片）  工资表（基本工资，岗位津贴，奖励，应发工资，水电，保险，实发工资）  部门表（代码，部门名称）  职称表（职称代码，职称名称）  年份表（年份代码，年份名称）  操作员表（操作员代码，操作员姓名，口令，部门，电话） 系统日志表（操作员代号，操作员姓名，登录时间，离开时间） 题目11：商品销售管理系统（1 人）19 包括四大模块：  用户登录  基本信息管理：包括销售情况、商品信息、库存表、员工表等信息的录入、浏览、修改、撤销、删除和查询等  商品销售管理：包括商品售出、退回和入库  盘点：包括库存盘点、当日销售盘点 参考数据如下：  商品信息表（商品编号，商品名称，品牌，型号，销售单价） 商品编号=类别代码（1 位）+品名代码（1 位）+品牌代码（2 位）+型号代码（2 位）  销售情况表（成交编号，商品编号，销售数量，总金额，销售日期，员工编号）  库存表（商品编号，供货商编号，进货日期，进货价，库存数量）  员工表（员工编号，员工姓名，性别，基本工资，职务，密码）  供货商表（供货商编号，供货商名称，所在地，联系电话）  员工资料表（员工编号，员工姓名，是否党员，简历，照片） 题目12：学生成绩管理系统（1 人）29 包括四大模块：  基本数据管理：包括院系管理，专业管理（设置院系下面的专业），班级管理（设置专业下面的班级），课程管理（设置相应专业下面的课程）  学生信息管理：包括基本信息录入、基本信息修改  学生成绩管理：包括学生成绩录入、学生成绩修改  信息查询：包括基本信息查询、成绩信息查询、学校人数统计  系统管理：用户管理、数据备份和系统帮助 参考数据如下：  院系信息（院系代码，院系名称）  院系专业信息（班级、院系代码，专业）  学生基本信息（班号，学号，姓名，性别，出生年月，籍贯，政治面貌，身份证号，入学年月，家庭地址，邮政编码，图片信息，备注）  学生成绩表（学号，课号，成绩，备注）  课程表（课号，课程名称，学期，备注）  班表（班号，班级名称）  用户信息表（用户名，密码，用户标识） 题目13：火车售票管理系统（4 人）36 包括四大模块：  售票管理  订票管理  信息查询  系统维护 参考数据如下：  车次信息表（车次，始发站，终点站，发车时间，到达时间）  订票信息表（车次，座位号，发车时期，发车时间，座位等级，票价）  车次座位等级分配及座位占用表（车次，座位号，座位等级，票价，占用标志）  用户信息表（用户名，密码，用户标识） 题目14：小型物业管理系统（1 人） 包括四大模块：  房源管理：对原始资料的录入、修改、查询和刷新。一般用户可以查询与房间有关 的统计资料；物业主管可其进行增、删、改、插等操作  租房管理：对房产出租，退租以及租房面积调整。其中物业主管可对其进行房租金 额计算和收款操作，一般用户对其查询  水电处理：根据租房资料，结合当月水、电量进行分摊，完成应收水电费。其中物 业主管对其进行计算，其他查询  交款处理：提供收款和发票打印以及交款数据查询  查询处理：对租房资料、交款资料，发票资料进行查询 参考数据如下：  房源资料（名称，面积，月租，物业，仓库）  租房资料（名称，面积，单位，月租，物业，押金，仓库）  水电资料（单位，电量，水量，电费，水费）  交费资料（收费项目，应收日期，应收金额，已收金额，未收金额，本次收款）  发票资料（单位，房租，电费，水费，物业）  权限资料（用户，密码，房源管理，租房管理，水电管理，交费管理，发票管理，系统维护） 其中系统管理员，有权进行系统维护；单位内部物业主管，有权进行物业资源调配、单元出 租，退租和收款开票操作；物业管理员，有权进行水电处理和收款处理等操行；租户代表， 有权进行种类费的查询操作 题目15：机房收费管理系统（1 人）7，34 包括四大模块：  登录模块  上机管理模块 说明：上机登记时，余额不足 3 元或卡处于挂失状态，则拒绝登记 每位同学的一次上机形成一条记录，每 36S 遍历一次上机记录表，对表中所有正上机字段为 TRUE 的记录的上机用时增加 36S,同时从上机卡表的余额减少  上机卡管理模块  充值挂失模块  查找统计模块：统计某天上机的总时数、每次上机的平均时数和机房的收入；某学 生上机的次数、上机总时数、每次上机平均时间；挂失和查询余 参考数据如下：  上机卡（卡号，姓名，专业班级，余额，状态） 状态的取值有：正常（能自费上机）  挂失上机记录（卡号，上机日期，开始时间，上机用时，正上机，管理号代码），上机用时记录学生上机时间（S）；正上机是一个布尔型，为 True 表示正上机，每 36 秒刷新 其上机用时并扣除上机费用，为 False 表示上机结束。上机记录表永久保存，用于事后查询 和统计 管理员（代码，姓名，口令）  题目16：高校药房管理（1 人）31 包括四大模块：  基础数据处理：包括医生和药剂师名单的录入，修改，删除及查询  营业数据处理：包括药品进货上柜，处理划价，配药，柜存药品查询，处方综合查 询，交接班结转清。 参考数据如下：  药品信息表（货号，货名，计量单位，进货数量，进货单价，出售单价，进货日期，收货人 和供应商）  处方信息（编号，患者姓名，医生姓名，药剂师姓名，处方日期，配药日期） 处方药品信息（处方编号，药品货号，计量单位，配药数量，销售单价，已配药否）  医生名单和药剂师名单表（姓名）  题目17：考勤管理系统（2 人）40 包括四大模块：  记录每个员工每天所有进入公司的时刻和离开公司的时刻。  每天结束时自动统计当天的工作时间  每天结束时自动统计当天迟到或早退的次数。  对于弹性工作制，每天结束时自动统计当月的工时，并自动算出当月欠缺或富余的 时间  每个月末统计该月的工作时间判断是束足够  每个月末统计该月的工作天数并判断是否足够  管理人员查询并修改工作时间（特殊情况下修改）  管理人员账户管理（如设置密码等）  管理人员设定早退及迟到的条件，每个月的工作时间  管理人员设定每个月的工作日期及放假日期 参考数据如下：  员工信息(工号，姓名，年龄，入职时间，职位，性别，密码)  配置信息（上班时间小时，上班时间分钟，下班时间小时，下班时间分钟，每天工作时间）  每月统计数据表（工号，姓名，剩余的时间，迟到的次数，早退的次数，工作天数）  每天统计信息表（工号，姓名，小时，分钟，动作，时间） 其中动作指的时入或离开公司  题目18：单位房产管理系统（2 人）33，10 包括四大模块：  系统模块：完成数据库维护、系统关闭功能  物业费用模块：完成本月物业的计费、历史资料查询和财务部门接口传送数据、物 业相关费用单价设置  房屋资源模块：对房屋资源进行添加、列表显示、查询  职工信息模块：对职工进行添加、列表显示、查询以及相应部门、职务进行维护  帮助模块：对用户使用本系统提供在线帮助 参考数据如下：  职工（编号，姓名，性别，参加工作时间，行政职务，专业技术职务，评上最高行政职务时 间，评上最高专业技术职务时间，双职工姓名，现居住房号，档案号，房产证号，所在部门 编号，是否为户主）  部门（编号，部门名称） 住房级别表（编号，级别，住房标准，控制标准，级别分类）  房产情况（编号，房号，使用面积，现居住人 id，上一个居住人 id,最早居住人 ID,阳台面积）  物业费用（编号，房号，水基数，水现在值，电基数，电现在值，燃气基数，燃气现在值， 当前年份，当前月份）  价格标准（编号，水单价，电单价，燃气单价） 题目19：标准化考试系统 （2 人）15，39 功能要求： 设计一个简单的标准化考试系统，仅有单项选择题、多项选择题和判断题功能即可。 包括四大模块：  题库管理：实现试题的录入、修改、删除功能；  考试子系统：能够实现考生做题、结果自动存入到数据库中，有时间提示；  选择身份(登录)功能：系统能够记录考生输入的登录信息及交卷信息；  自动评分功能：考生交卷后能自动评分；  查看成绩功能：能够查询考生相关信息(包含成绩等)。 参考数据如下： 其它可供选择的题目： 网上教务评教系统130，127，133 16 学生日常行为评分管理系统232，110，230 网上鲜花店 38 基于BS结构的工艺品销售系统12 基于BS结构的校园二手物品交易网站 37 大学生就业管理系统201，208，234 题库及试卷管理系统 数据库原理及应用 课程设计报告 题目： 课程设计选题管理系统 所在学院： 班 级： 学 号： 姓 名： 李四 指导教师： 2011年12月 日 目录 一、 概述 二、需求分析 三、概念设计 四、逻辑设计 五、系统实现 六、小结 一、概述

既然dojo有,何不把dojo的借鉴一下.######对dojo不是很熟悉，没时间仔细研究。。。######不错，我一直希望有人能够做这个事情，在客户端解析fastjson的应用。######回复 @gohsy : 谢谢的你支持。使用好了并参与其中，才是更好的使用开源方式。也就是所谓的社区能读能改。我打算开一个项目用javascript实现fastjson的引用解析，希望你能够参与其中。######很早就在项目中引入了温少侠的fastjson druid，绝对达到商业软件的水准了，屡用不爽，越用越爽。###### fastjson循环引用的文档： https://github.com/alibaba/fastjson/wiki/%E5%BE%AA%E7%8E%AF%E5%BC%95%E7%94%A8 ######很高端。只是想知道，大部分语言的JSON API应该都不支持循环引用吧，那么循环引用是什么样的需求产生的？可以避免不？ ######文章里面已经描述了，由hibernate生成的实体，包含着大量的关联引用，在稍大的一点的项目中，实体对象之间的关联关系会比较复杂，要么就手动处理有选择性的输出关联关系，要么就用fastjson这样能够处理循环引用的库，在数据使用方的底层，在做引用还原。######可以对每个域模型继承一个接口，接口提供一个将模型转为map的方法，map里可以包含引用，但也是对方转成map的，同时自己在转map那个方法里防止递归引用。######Ext.define('overrides.JSON', {     override : 'Ext.JSON',     decode : function(json, safe) {         me = this;         if (typeof me.JSON.retrocycle !== 'function') {             me.JSON.retrocycle = (function() {                 'use strict';                 var t_obj = typeof {}, t_arr = Object.prototype.toString                         .apply([]), t_str = typeof "";                 var walk = function(path, _xpath, array) {                     if (path.startsWith('$')) // 基于xpath直接定位                         return path;                     else { // 相对回溯定位                         var x, j = path.split('..'), k = -j.length                                 + (array ? 2 : 1), last = j.slice(-1)[0]                                 .replace('/', '.');                         x = k < 0 ? _xpath.slice(0, k) : _xpath.slice(0);                         if (last && !last.startsWith('.')                                 && !last.startsWith('['))                             last = '.' + last;                         path = x.join('.') + last;                     }                     return path; // 最终得到绝对xpath地址                 };                 return function($) {                     var xpath = ['$'];                     (function rez(value) {                         var i, item, name, path, _x;                         if (value && typeof value === t_obj) {                             if (Object.prototype.toString.apply(value) === t_arr) {                                 for (i = 0; i < value.length; i += 1) {                                     item = value[i];                                     if (item && typeof item === t_obj) {                                         xpath.push(xpath.pop() + '[' + i + ']'); // 下标引用要合并分级                                         path = item.$ref;                                         if (typeof path === t_str)                                             value[i] = eval(walk(path, xpath,                                                     true));                                         else                                             rez(item);                                         if (_x = xpath.pop())                                             xpath.push(_x.slice(0, _x                                                             .indexOf('['))); // 下标引用还原分级                                     }                                 }                             } else {                                 for (name in value) {                                     if (value.hasOwnProperty(name)                                             && typeof value[name] === t_obj) {                                         xpath.push(name);                                         item = value[name];                                         if (item) {                                             path = item.$ref;                                             if (typeof path === t_str)                                                 value[name] = eval(walk(path,                                                         xpath));                                             else                                                 rez(item);                                         }                                         xpath.pop();                                     }                                 }                             }                         }                     })($);                     return $;                 }             })();         }         var isNative = function() {             var useNative = null;             return function() {                 if (useNative === null) {                     useNative = Ext.USE_NATIVE_JSON && window.JSON                             && JSON.toString() == '[object JSON]';                 }                 return useNative;             };         }();         var decodingFunction;         doDecode = function(json) {             return json ? eval("(" + json + ")") : "";         };         if (!decodingFunction) {             // setup decoding function on first access             decodingFunction = isNative() ? JSON.parse : doDecode;         }         try {             return this.JSON.retrocycle(decodingFunction(json));         } catch (e) {             if (safe === true) {                 return null;             }             Ext.Error.raise({                         sourceClass : "Ext.JSON",                         sourceMethod : "decode",                         msg : "我尝试解析 an invalid JSON String: " + json                     });         }     } }); Ext.decode = Ext.JSON.decode; 在Extjs 4.2　里的写法。放在与app目录平齐的overrides里面。 然后在APP.js里面加入下面的东西。 Ext.application({     name: 'admin',     extend: 'admin.Application',     requires: [ //               'overrides.grid.RowEditor'     'overrides.JSON'            ],     autoCreateViewport: true }); ###### 这个解析的算法还有BUG。就是当A引用B一个集合，A在引用B单个的时候解析出来可能B指向的A就会错误。 举个例子：客户与客户联系人。客户有一个客户联系人的集合的属性，客户还有一个主联系人的属性。同时客户联系人也指向客户有一个属性，当这种对应关系的时候解析就会出错！ 我尝试着想要去解决，但是智商有限搞不了。求作者在查看一下。 ###### 引用来自“刘思作”的评论 这个解析的算法还有BUG。就是当A引用B一个集合，A在引用B单个的时候解析出来可能B指向的A就会错误。 举个例子：客户与客户联系人。客户有一个客户联系人的集合的属性，客户还有一个主联系人的属性。同时客户联系人也指向客户有一个属性，当这种对应关系的时候解析就会出错！ 我尝试着想要去解决，但是智商有限搞不了。求作者在查看一下。 看来这个问题还是有人关注的哈。  你可以给点数据，我有空的时候的看看。

既然dojo有,何不把dojo的借鉴一下.######对dojo不是很熟悉，没时间仔细研究。。。######不错，我一直希望有人能够做这个事情，在客户端解析fastjson的应用。######回复<aclass="referer"target="_blank">@gohsy:谢谢的你支持。使用好了并参与其中，才是更好的使用开源方式。也就是所谓的社区能读能改。我打算开一个项目用javascript实现fastjson的引用解析，希望你能够参与其中。######很早就在项目中引入了温少侠的fastjsondruid，绝对达到商业软件的水准了，屡用不爽，越用越爽。###### fastjson循环引用的文档： <arel="nofollow">https://github.com/alibaba/fastjson/wiki/%E5%BE%AA%E7%8E%AF%E5%BC%95%E7%94%A8######很高端。只是想知道，大部分语言的JSONAPI应该都不支持循环引用吧，那么循环引用是什么样的需求产生的？可以避免不？ ######文章里面已经描述了，由hibernate生成的实体，包含着大量的关联引用，在稍大的一点的项目中，实体对象之间的关联关系会比较复杂，要么就手动处理有选择性的输出关联关系，要么就用fastjson这样能够处理循环引用的库，在数据使用方的底层，在做引用还原。######可以对每个域模型继承一个接口，接口提供一个将模型转为map的方法，map里可以包含引用，但也是对方转成map的，同时自己在转map那个方法里防止递归引用。######Ext.define('overrides.JSON',{    override:'Ext.JSON',    decode:function(json,safe){       me=this;       if(typeofme.JSON.retrocycle!=='function'){          me.JSON.retrocycle=(function(){             'usestrict';             vart_obj=typeof{},t_arr=Object.prototype.toString                   .apply([]),t_str=typeof"";             varwalk=function(path,_xpath,array){                if(path.startsWith('$'))//基于xpath直接定位                   returnpath;                else{//相对回溯定位                   varx,j=path.split('..'),k=-j.length                         +(array?2:1),last=j.slice(-1)[0]                         .replace('/','.');                   x=k<0?_xpath.slice(0,k):_xpath.slice(0);                   if(last&&!last.startsWith('.')                         &&!last.startsWith('['))                      last='.'+last;                   path=x.join('.')+last;                }                returnpath;//最终得到绝对xpath地址             };             returnfunction($){                varxpath=['$'];                (functionrez(value){                   vari,item,name,path,_x;                   if(value&&typeofvalue===t_obj){                      if(Object.prototype.toString.apply(value)===t_arr){                         for(i=0;i<value.length;i+=1){                            item=value[i];                            if(item&&typeofitem===t_obj){                               xpath.push(xpath.pop()+'['+i+']');//下标引用要合并分级                               path=item.$ref;                               if(typeofpath===t_str)                                  value[i]=eval(walk(path,xpath,                                        true));                               else                                  rez(item);                               if(_x=xpath.pop())                                  xpath.push(_x.slice(0,_x                                              .indexOf('[')));//下标引用还原分级                            }                         }                      }else{                         for(nameinvalue){                            if(value.hasOwnProperty(name)                                  &&typeofvalue[name]===t_obj){                               xpath.push(name);                               item=value[name];                               if(item){                                  path=item.$ref;                                  if(typeofpath===t_str)                                     value[name]=eval(walk(path,                                           xpath));                                  else                                     rez(item);                               }                               xpath.pop();                            }                         }                      }                   }                })($);                return$;             }          })();       }       varisNative=function(){          varuseNative=null;          returnfunction(){             if(useNative===null){                useNative=Ext.USE_NATIVE_JSON&&window.JSON                      &&JSON.toString()=='[objectJSON]';             }             returnuseNative;          };       }();       vardecodingFunction;       doDecode=function(json){          returnjson?eval("("+json+")"):"";       };       if(!decodingFunction){          //setupdecodingfunctiononfirstaccess          decodingFunction=isNative()?JSON.parse:doDecode;       }       try{          returnthis.JSON.retrocycle(decodingFunction(json));       }catch(e){          if(safe===true){             returnnull;          }          Ext.Error.raise({                   sourceClass:"Ext.JSON",                   sourceMethod:"decode",                   msg:"我尝试解析aninvalidJSONString:"+json                });       }    } }); Ext.decode=Ext.JSON.decode; 在Extjs4.2　里的写法。放在与app目录平齐的overrides里面。 然后在APP.js里面加入下面的东西。 Ext.application({   name:'admin',   extend:'admin.Application',   requires:[//              'overrides.grid.RowEditor'   'overrides.JSON'          ],   autoCreateViewport:true}); ###### 这个解析的算法还有BUG。就是当A引用B一个集合，A在引用B单个的时候解析出来可能B指向的A就会错误。 举个例子：客户与客户联系人。客户有一个客户联系人的集合的属性，客户还有一个主联系人的属性。同时客户联系人也指向客户有一个属性，当这种对应关系的时候解析就会出错！ 我尝试着想要去解决，但是智商有限搞不了。求作者在查看一下。 <imgsrc="http://static.oschina.net/uploads/space/2014/0603/125031_qDeH_90398.png"alt=""/> ######<divclass="ref"> 引用来自“刘思作”的评论 这个解析的算法还有BUG。就是当A引用B一个集合，A在引用B单个的时候解析出来可能B指向的A就会错误。 举个例子：客户与客户联系人。客户有一个客户联系人的集合的属性，客户还有一个主联系人的属性。同时客户联系人也指向客户有一个属性，当这种对应关系的时候解析就会出错！ 我尝试着想要去解决，但是智商有限搞不了。求作者在查看一下。 <imgsrc="http://static.oschina.net/uploads/space/2014/0603/125031_qDeH_90398.png"alt=""/> 看来这个问题还是有人关注的哈。  你可以给点数据，我有空的时候的看看。